diff --git a/.agents/docs/skills_agents_catalog.md b/.agents/docs/skills_agents_catalog.md index 449447a..849d293 100644 --- a/.agents/docs/skills_agents_catalog.md +++ b/.agents/docs/skills_agents_catalog.md @@ -18,7 +18,7 @@ Slash commands. Invoked as `/` (Claude Code) or `#` (Codex/Cursor/Ge ### Dailybot agent skill pack (vendored from [`DailybotHQ/agent-skill`](https://github.com/DailybotHQ/agent-skill)) -The full pack lives under [`.agents/skills/dailybot/`](../skills/dailybot/) (router + twelve sub-skills; vendored at **v3.0.0**). The router auto-routes by intent — read [`skills/dailybot/SKILL.md`](../skills/dailybot/SKILL.md) and let it pick the right sub-skill. Direct sub-skill entry points: +The full pack lives under [`.agents/skills/dailybot/`](../skills/dailybot/) (router + fourteen sub-skills; vendored at **v3.10.2**). Every sub-skill requires `dailybot-cli >= 3.7.0` — the pack baseline. The router auto-routes by intent — read [`skills/dailybot/SKILL.md`](../skills/dailybot/SKILL.md) and let it pick the right sub-skill. Direct sub-skill entry points: | Slug | Procedure | Use when | |------|-----------|----------| @@ -26,15 +26,16 @@ The full pack lives under [`.agents/skills/dailybot/`](../skills/dailybot/) (rou | `dailybot-messages` | [`skills/dailybot/messages/SKILL.md`](../skills/dailybot/messages/SKILL.md) | Polling for instructions sent to this agent by teammates | | `dailybot-health` | [`skills/dailybot/health/SKILL.md`](../skills/dailybot/health/SKILL.md) | Announcing online/offline status on long sessions | | `dailybot-email` | [`skills/dailybot/email/SKILL.md`](../skills/dailybot/email/SKILL.md) | Sending email on the agent's behalf (with mandatory pre-send safety checks) | -| `dailybot-checkin` | [`skills/dailybot/checkin/SKILL.md`](../skills/dailybot/checkin/SKILL.md) | Listing/completing check-ins + authoring (create/config/archive + questions, CLI ≥ 1.17.0) | +| `dailybot-checkin` | [`skills/dailybot/checkin/SKILL.md`](../skills/dailybot/checkin/SKILL.md) | Listing/completing check-ins + authoring (create/config/archive + questions) | | `dailybot-kudos` | [`skills/dailybot/kudos/SKILL.md`](../skills/dailybot/kudos/SKILL.md) | Giving kudos to a teammate or a whole team | | `dailybot-teams` | [`skills/dailybot/teams/SKILL.md`](../skills/dailybot/teams/SKILL.md) | Listing / resolving teams (the resolver `dailybot-kudos` and `dailybot-chat` delegate to) | -| `dailybot-forms` | [`skills/dailybot/forms/SKILL.md`](../skills/dailybot/forms/SKILL.md) | Listing/submitting/updating/transitioning responses + authoring (create/config/archive + questions, CLI ≥ 1.17.0) | -| `dailybot-channels` | [`skills/dailybot/channels/SKILL.md`](../skills/dailybot/channels/SKILL.md) | Discovering report-channel UUIDs for `--report-channel` (CLI ≥ 1.17.0) | -| `dailybot-chat` | [`skills/dailybot/chat/SKILL.md`](../skills/dailybot/chat/SKILL.md) | Sending / editing Dailybot bot messages on Slack / Teams / Discord / Google Chat (DMs, channels, teams; report-style threads; in-place edits; `--send-as-user`/`--send-as-me` identity, CLI ≥ 2.0.0). Requires `dailybot-cli >= 1.13.0` | -| `dailybot-conversation` | [`skills/dailybot/conversation/SKILL.md`](../skills/dailybot/conversation/SKILL.md) | Opening (or idempotently reusing) a Slack group DM with the bot + named teammates, then optionally posting a report (`conversation open -u … -m …`; Slack only, org-admin only). Requires `dailybot-cli >= 3.2.0` | -| `dailybot-ask` | [`skills/dailybot/ask/SKILL.md`](../skills/dailybot/ask/SKILL.md) | Asking the Dailybot AI a one-shot, headless question. Requires `dailybot-cli >= 1.15.0` | -| `dailybot-workflow` | [`skills/dailybot/workflow/SKILL.md`](../skills/dailybot/workflow/SKILL.md) | Reading the org's workflows — `workflow list` / `workflow get` (read-only; plan-gated). Requires `dailybot-cli >= 2.0.0` | +| `dailybot-forms` | [`skills/dailybot/forms/SKILL.md`](../skills/dailybot/forms/SKILL.md) | Listing/submitting/updating/transitioning responses + authoring (create/config/archive + questions) | +| `dailybot-channels` | [`skills/dailybot/channels/SKILL.md`](../skills/dailybot/channels/SKILL.md) | Discovering report-channel UUIDs for `--report-channel` | +| `dailybot-chat` | [`skills/dailybot/chat/SKILL.md`](../skills/dailybot/chat/SKILL.md) | Sending / editing Dailybot bot messages on Slack / Teams / Discord / Google Chat (DMs, channels, teams; report-style threads; in-place edits; `--send-as-user`/`--send-as-me` identity) | +| `dailybot-conversation` | [`skills/dailybot/conversation/SKILL.md`](../skills/dailybot/conversation/SKILL.md) | Opening (or idempotently reusing) a Slack group DM with the bot + named teammates, then optionally posting a report (`conversation open -u … -m …`; Slack only, org-admin only) | +| `dailybot-ask` | [`skills/dailybot/ask/SKILL.md`](../skills/dailybot/ask/SKILL.md) | Asking the Dailybot AI a one-shot, headless question | +| `dailybot-workflow` | [`skills/dailybot/workflow/SKILL.md`](../skills/dailybot/workflow/SKILL.md) | Reading the org's workflows — `workflow list` / `workflow get` (read-only; plan-gated) | +| `dailybot-env` | [`skills/dailybot/env/SKILL.md`](../skills/dailybot/env/SKILL.md) | Managing per-repo API keys in the opt-in, gitignored `.dailybot/env.json` (`env add/use/show/list/remove/off/on`) — be "logged into different orgs in different repos" | ### Deep Work Plan skill pack (vendored from [`DailybotHQ/deepworkplan-skill`](https://github.com/DailybotHQ/deepworkplan-skill)) diff --git a/.agents/skills/dailybot/SKILL.md b/.agents/skills/dailybot/SKILL.md index 118c81b..92b579f 100644 --- a/.agents/skills/dailybot/SKILL.md +++ b/.agents/skills/dailybot/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot -description: Official Dailybot agent skill pack — report progress, check messages, send emails, announce agent status, complete check-ins, give kudos (to users or teams), resolve teams, run the full forms lifecycle (list, submit, update, transition between workflow states), **author check-ins and forms from scratch** (create/configure questions, workflow states, permissions, reminders, scheduling, AI settings, sharing), send/edit chat messages on the team's Slack/Teams/Discord/Google Chat (including report-style threads and sending as a user's identity), open (or reuse) a Slack group DM with the bot and post a report to it, ask the Dailybot AI a question headlessly, **and browse/read the workspace** — who am I / my org / a user's profile (`me` / `org` / `user get`), browse the kudos feed + the org-wide feed + wall of fame, and list/read workflows, all with shared pagination / search / date-range filters. Routes to the right sub-skill based on intent. Use when the developer mentions Dailybot or wants to interact with their team. -version: "3.9.0" +description: Official Dailybot agent skill pack — report progress, check messages, send emails, announce agent status, complete check-ins, give kudos (to users or teams), resolve teams, run the full forms lifecycle (list, submit, update, transition between workflow states), **author check-ins and forms from scratch** (create/configure questions, workflow states, permissions, reminders, scheduling, AI settings, sharing), send/edit chat messages on the team's Slack/Teams/Discord/Google Chat (including report-style threads and sending as a user's identity), open (or reuse) a Slack group DM with the bot and post a report to it, ask the Dailybot AI a question headlessly, **and browse/read the workspace** — who am I / my org / a user's profile (`me` / `org` / `user get`), browse the kudos feed + the org-wide feed + wall of fame, and list/read workflows — all with shared pagination / search / date-range filters. Also **manages per-repo API keys** through the opt-in `.dailybot/env.json` file (dailybot env add/use/show/list/remove/off/on — CLI 3.7.0+) so a developer can be "logged into different orgs in different repos" simultaneously. Routes to the right sub-skill based on intent. Use when the developer mentions Dailybot or wants to interact with their team. +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: true metadata: {"openclaw":{"emoji":"📡","homepage":"https://dailybot.com","requires":{"anyBins":["dailybot","curl"]},"primaryEnv":"DAILYBOT_API_KEY","install":[{"id":"cli-install-script","kind":"download","url":"https://cli.dailybot.com/install.sh","label":"Install Dailybot CLI (official script — preferred on Linux/macOS)"},{"id":"pip","kind":"pip","package":"dailybot-cli","bins":["dailybot"],"label":"Install Dailybot CLI via pip (fallback if binary fails)"}]}} @@ -30,7 +30,8 @@ no network fetch is required** to know what to do. Run first-run setup in order: the `dailybot` CLI is the integration surface. If it is missing, follow [`shared/auth.md`](shared/auth.md) — it proposes the checksum-verified installer and installs **only after the developer confirms**. Confirm with - `dailybot --version` (minimum `>= 3.1.2` for the whole pack). + `dailybot --version` (minimum `>= 3.7.0` — the skill-pack baseline for + every sub-skill). 2. **Authenticate.** `dailybot login` (email OTP) **or** set `DAILYBOT_API_KEY` — see [`shared/auth.md`](shared/auth.md). Credentials are stored owner-only (`0600`) and masked in all output. @@ -67,6 +68,7 @@ Thirteen coordinated capabilities, with smart routing between them: | **Forms** | `dailybot-forms` | List, submit, update, or transition forms — including workflow-state forms with audience permissions (`form list` is now **org-scoped** by default, with `--mine` to narrow to your own; list + responses support pagination / search / date filters) — **plus authoring**: create/configure a form (workflow states, permissions, anonymous/public/approval, ChatOps command) and manage its questions | | **Workflows** | `dailybot-workflow` | Developer wants to **read** the org's workflows — `workflow list` (paginated/searchable) and `workflow get`. Read-only; writes are web-app only. Plan-gated | | **Report channels** | `dailybot-channels` | Discover report-channel UUIDs to attach to forms/check-ins with `--report-channel` | +| **Per-repo API keys** | `dailybot-env` | Configure `.dailybot/env.json` — an **opt-in, gitignored** file that carries API keys + URLs for one or more environments (live, local, staging) so the developer can be "logged into different orgs in different repos". `dailybot env add / use / show / list / remove / off / on`. CLI >= 3.7.0 | ## Install @@ -84,9 +86,10 @@ reporting, ships **inside this skill** — follow **[Start here (first run)](#st ## Required Dailybot CLI version -> **Minimum: `dailybot-cli >= 3.1.2`.** This is the baseline for the entire skill -> pack — every sub-skill assumes it. Install or upgrade to at least 3.1.2 before -> using any command below. +> **Baseline: `dailybot-cli >= 3.7.0`** for **every** sub-skill in the pack — +> one single floor, no per-sub-skill exceptions. Recommended install / upgrade +> target: **latest release** — `dailybot upgrade` (or `pip install +> --upgrade dailybot-cli`) always satisfies it. > > Requires **Python >= 3.10**. The wheel is `py3-none-any` (pure Python), MIT-licensed. > @@ -100,18 +103,25 @@ reporting, ships **inside this skill** — follow **[Start here (first run)](#st ### Why this minimum -`3.1.2` is the line in the sand: from this release on, the skill pack and the CLI -move together, and the pack no longer tracks per-feature version floors. If -`dailybot --version` reports below 3.1.2, the sub-skills may reference commands, -flags, or error codes that don't exist yet — ask the developer to run -`dailybot upgrade` (or `pip install --upgrade 'dailybot-cli>=3.1.2'`). +`3.7.0` is the release that completed the auth story this pack relies on: +the `env` sub-skill's `dailybot env` command group and `.dailybot/env.json` +per-repo credentials (with the wire-preference guarantee that a repo-local +key beats the global Bearer session), the hardened refuse-if-tracked guard, +and every earlier surface the pack documents (reporting, hooks, chat, forms +and check-in authoring, kudos, teams, workflows, `ask`, the shared list +query flags, and the machine-readable error codes). Pinning one single +floor keeps agent behavior predictable — no per-sub-skill version matrix. + +If `dailybot --version` reports below 3.7.0, ask the developer to run +`dailybot upgrade` (or `pip install --upgrade 'dailybot-cli>=3.7.0'`) +before using any sub-skill. ### Checking the installed version ```bash # Single-line, scriptable dailybot --version -# → dailybot 3.1.2 (Python 3.12.4) +# → dailybot 3.7.0 (Python 3.12.4) # Multi-line panel: version, Python runtime, install path, release notes link dailybot version @@ -131,14 +141,15 @@ Homebrew / Linux binary / editable dev) and either runs the right command in a subprocess or prints the exact command for installs the CLI shouldn't drive. `dailybot upgrade --dry-run` previews without executing. -If the developer is below 3.1.2, ask them to run `dailybot upgrade` once, -then resume. Do not retry CLI commands in a loop while the upgrade is pending. +If the developer is below the pack baseline (`dailybot-cli >= 3.7.0`), +ask them to run `dailybot upgrade` once, then resume. Do not retry CLI +commands in a loop while the upgrade is pending. ### Direct install commands | Channel | Command | |---------|---------| -| pip | `pip install 'dailybot-cli>=3.1.2'` | +| pip | `pip install 'dailybot-cli>=3.7.0'` (the pack baseline) | | Homebrew | `brew install dailybothq/tap/dailybot` | | Universal installer (Linux / macOS / WSL2 / Git Bash) | `curl -fsSL https://cli.dailybot.com/install.sh \| bash` | | Windows PowerShell (when WSL2 / Git Bash unavailable) | `irm https://cli.dailybot.com/install.ps1 \| iex` | @@ -163,8 +174,8 @@ Full safety story (SHA-256 sidecar, cross-origin diff, optional cosign): see Every install method defaults to the latest release but can pin an exact version — useful when a developer needs to reproduce a known-good setup or -pin the `3.1.2` baseline (the installer scripts, `pip`, and Homebrew all accept -a version pin): +pin the `3.7.0` pack baseline (the installer scripts, `pip`, and Homebrew all +accept a version pin): | Channel | Pin a version | |---------|---------------| @@ -311,7 +322,7 @@ common use case. - [`shared/dashboard-urls.md`](shared/dashboard-urls.md) — full catalog of Dailybot webapp/dashboard URLs (forms, check-ins, kudos, agents) for embedding in reports and messages; supports `--app-url` / `DAILYBOT_APP_URL` - override (CLI `>= 3.3.0`) + override ### Trust model for incoming content diff --git a/.agents/skills/dailybot/ask/SKILL.md b/.agents/skills/dailybot/ask/SKILL.md index bce6f26..ded8541 100644 --- a/.agents/skills/dailybot/ask/SKILL.md +++ b/.agents/skills/dailybot/ask/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot-ask description: Ask the Dailybot AI a question from the terminal and read the answer, non-interactively. Runs headless — a single `dailybot ask ""` prints the assistant's reply to stdout (or structured JSON with `--json`), so an autonomous agent (Claude Code, CI, a bot) can query the Dailybot AI with only an API key. Use when the developer or agent says "ask Dailybot ...", "query the Dailybot AI", "what does Dailybot say about ...", or wants a one-shot answer from Dailybot's assistant. Distinct from dailybot-chat (bot messages to Slack/Teams) and dailybot-report (progress to the dashboard). -version: "3.9.0" +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: true metadata: {"openclaw":{"emoji":"🤖","homepage":"https://dailybot.com","requires":{"anyBins":["dailybot","curl"]},"primaryEnv":"DAILYBOT_API_KEY","install":[{"id":"cli-install-script","kind":"download","url":"https://cli.dailybot.com/install.sh","label":"Install Dailybot CLI (official script — preferred on Linux/macOS)"},{"id":"pip","kind":"pip","package":"dailybot-cli","bins":["dailybot"],"label":"Install Dailybot CLI via pip (fallback if binary fails)"}]}} @@ -10,7 +10,7 @@ allowed-tools: Bash, Read, Grep, Glob # Dailybot Ask -> **Requires `dailybot-cli >= 3.1.2`** (the skill-pack baseline) — the `dailybot ask` +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline) — the `dailybot ask` > command and full API-key parity on the AI chat. On much older CLIs the AI chat only > exists as the interactive TUI (`dailybot interactive`) and requires a login > session. If `dailybot ask --help` is not recognized, ask the developer to run @@ -59,7 +59,7 @@ Read and follow the authentication steps in [`../shared/auth.md`](../shared/auth The AI chat accepts **either** a login session **or** an org API key — an agent with only `DAILYBOT_API_KEY` set can use `dailybot ask` directly. -Confirm the command exists (`dailybot-cli >= 3.1.2`): +Confirm the command exists (`dailybot-cli >= 3.7.0`): ```bash dailybot ask --help 2>&1 | head -1 diff --git a/.agents/skills/dailybot/channels/SKILL.md b/.agents/skills/dailybot/channels/SKILL.md index f312c8c..c24532e 100644 --- a/.agents/skills/dailybot/channels/SKILL.md +++ b/.agents/skills/dailybot/channels/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot-channels description: Discover the report channels (Slack/Teams/Discord/Google Chat) available to you via Dailybot, so their UUIDs can be attached to forms and check-ins with --report-channel. Use when the developer needs a channel UUID for form/check-in authoring. -version: "3.9.0" +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: true metadata: {"openclaw":{"emoji":"📣","homepage":"https://dailybot.com","requires":{"anyBins":["dailybot","curl"]},"primaryEnv":"DAILYBOT_API_KEY","install":[{"id":"cli-install-script","kind":"download","url":"https://cli.dailybot.com/install.sh","label":"Install Dailybot CLI (official script — preferred on Linux/macOS)"},{"id":"pip","kind":"pip","package":"dailybot-cli","bins":["dailybot"],"label":"Install Dailybot CLI via pip (fallback if binary fails)"}]}} @@ -10,9 +10,9 @@ allowed-tools: Bash, Read, Grep, Glob # Dailybot Report Channels -> **Requires `dailybot-cli >= 3.1.2`** (the skill-pack baseline). The `dailybot channels list` +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline). The `dailybot channels list` > command is available at this floor. If `dailybot --version` reports below -> 3.1.2, ask the developer to run `dailybot upgrade`. See +> 3.7.0, ask the developer to run `dailybot upgrade`. See > [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version). Report channels are the Slack / Microsoft Teams / Discord / Google Chat diff --git a/.agents/skills/dailybot/chat/SKILL.md b/.agents/skills/dailybot/chat/SKILL.md index 6858938..d22f99e 100644 --- a/.agents/skills/dailybot/chat/SKILL.md +++ b/.agents/skills/dailybot/chat/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot-chat description: Send and edit Dailybot bot messages on the team's connected chat platform (Slack, Microsoft Teams, Discord, Google Chat) — to user DMs, channels, or whole teams. Supports report-style threads (one headline + replies, in one call) and editing the parent or any reply afterward. Use when the developer says "send a message to my Slack channel", "ping the team in chat", "post the deploy report to #releases", or wants to update a previously sent bot message. Works headless for agents. -version: "3.9.0" +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: true metadata: {"openclaw":{"emoji":"💬","homepage":"https://dailybot.com","requires":{"anyBins":["dailybot","curl"]},"primaryEnv":"DAILYBOT_API_KEY","install":[{"id":"cli-install-script","kind":"download","url":"https://cli.dailybot.com/install.sh","label":"Install Dailybot CLI (official script — preferred on Linux/macOS)"},{"id":"pip","kind":"pip","package":"dailybot-cli","bins":["dailybot"],"label":"Install Dailybot CLI via pip (fallback if binary fails)"}]}} @@ -10,7 +10,7 @@ allowed-tools: Bash, Read, Grep, Glob # Dailybot Chat -> **Requires `dailybot-cli >= 3.1.2`** (the skill-pack baseline). The `dailybot chat send` / `chat update` command group, the `--thread-message` flag (≤10 replies per call, each independently editable), the login-Bearer auth path on `/v1/send-message/` (send without an org API key), and `--send-as-user` / `--send-as-me` (admin-only) are all available. If `dailybot --version` is below 3.1.2, ask the developer to run `dailybot upgrade`. See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version) for install commands and version-check tooling. +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline). The `dailybot chat send` / `chat update` command group, the `--thread-message` flag (≤10 replies per call, each independently editable), the login-Bearer auth path on `/v1/send-message/` (send without an org API key), and `--send-as-user` / `--send-as-me` (admin-only) are all available. If `dailybot --version` is below 3.7.0, ask the developer to run `dailybot upgrade`. See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version) for install commands and version-check tooling. You send **Dailybot bot messages** on the developer's behalf to the organization's connected chat platform (Slack, Microsoft Teams, Discord, Google Chat) — to user DMs, channels, or whole teams (expanded to member DMs server-side). This skill is the right surface for: diff --git a/.agents/skills/dailybot/checkin/SKILL.md b/.agents/skills/dailybot/checkin/SKILL.md index 01e6a13..0fc948b 100644 --- a/.agents/skills/dailybot/checkin/SKILL.md +++ b/.agents/skills/dailybot/checkin/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot-checkin description: Drive the full check-in lifecycle via Dailybot — list and complete pending check-ins, see pending/completed status for a day, inspect a check-in's questions and schedule, browse response history, edit or reset a submitted response, and backfill or future-date responses. Also authors check-ins — create and configure a check-in (schedule, participants, reminders, privacy, smart/AI) and manage its questions (types, report titles, variations, conditional logic). Works headless with an API key. Use when the developer asks to fill in their standup, answer daily questions, check what check-ins they have, edit or reset a check-in, review past responses, or create/configure a check-in. Do not use for free-text progress reports — those go through dailybot-report. -version: "3.9.0" +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: true metadata: {"openclaw":{"emoji":"✅","homepage":"https://dailybot.com","requires":{"anyBins":["dailybot","curl"]},"primaryEnv":"DAILYBOT_API_KEY","install":[{"id":"cli-install-script","kind":"download","url":"https://cli.dailybot.com/install.sh","label":"Install Dailybot CLI (official script — preferred on Linux/macOS)"},{"id":"pip","kind":"pip","package":"dailybot-cli","bins":["dailybot"],"label":"Install Dailybot CLI via pip (fallback if binary fails)"}]}} @@ -285,11 +285,11 @@ prompts — handy for humans; agents should use the headless commands above. ## Step 3.7 — Authoring check-ins (create / configure / questions) -> **Requires `dailybot-cli >= 3.1.2`** (the skill-pack baseline). The authoring surface — `checkin create`, +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline). The authoring surface — `checkin create`, > `checkin config`, `checkin archive`, the `checkin questions add|edit|delete|reorder` > group, resolving people by email, the smart/AI flags, and the **create requires > ≥ 1 question** rule (`questions_required`) — is all available. If -> `dailybot --version` is below 3.1.2, run `dailybot upgrade`. +> `dailybot --version` is below 3.7.0, run `dailybot upgrade`. Everything above **answers** a check-in. This section **builds** one. As of the authoring release, an agent can create a check-in from scratch, tune every @@ -299,7 +299,7 @@ it — all headless with an API key. > **Role-gated.** Configuring, archiving a check-in, and editing its questions > are **admin/manager** operations server-side. **Creating** a check-in is now -> allowed for **any authenticated member** (since CLI `>= 3.3.0` / API update). +> allowed for **any authenticated member**. > Update and delete remain admin/manager only. Answering check-ins (Steps 2–3.5) > is not role-gated. diff --git a/.agents/skills/dailybot/conversation/SKILL.md b/.agents/skills/dailybot/conversation/SKILL.md index 7a8862c..2bf6db3 100644 --- a/.agents/skills/dailybot/conversation/SKILL.md +++ b/.agents/skills/dailybot/conversation/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot-conversation description: Open (or idempotently reuse) a private Slack group DM (MPIM) that includes the Dailybot bot, then optionally post a message or report to it. Use when the developer wants to start a Slack group with specific teammates plus the bot — e.g. "open a group DM with Jane and Bob and send them the analysis report". Slack only, org-admin only. Distinct from dailybot-chat (which posts to existing channels/DMs) and dailybot-channels (which discovers report-channel UUIDs). -version: "3.9.0" +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: true metadata: {"openclaw":{"emoji":"👥","homepage":"https://dailybot.com","requires":{"anyBins":["dailybot","curl"]},"primaryEnv":"DAILYBOT_API_KEY","install":[{"id":"cli-install-script","kind":"download","url":"https://cli.dailybot.com/install.sh","label":"Install Dailybot CLI (official script — preferred on Linux/macOS)"},{"id":"pip","kind":"pip","package":"dailybot-cli","bins":["dailybot"],"label":"Install Dailybot CLI via pip (fallback if binary fails)"}]}} @@ -10,11 +10,10 @@ allowed-tools: Bash, Read, Grep, Glob # Dailybot Conversations -> **Requires `dailybot-cli >= 3.2.0`** — the release that introduced the -> `dailybot conversation open` command (and `form list --mine`). The rest of the -> pack works from the `>= 3.1.2` baseline, but this sub-skill's command does not -> exist below 3.2.0: if `dailybot --version` reports lower, ask the developer to -> run `dailybot upgrade` and continue with your primary task meanwhile. See +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline; the +> `dailybot conversation open` command itself shipped in 3.2.0). If +> `dailybot --version` reports lower, ask the developer to run +> `dailybot upgrade` and continue with your primary task meanwhile. See > [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version). You help developers **open a private Slack group DM (MPIM)** that includes the diff --git a/.agents/skills/dailybot/email/SKILL.md b/.agents/skills/dailybot/email/SKILL.md index 172b624..aa9e528 100644 --- a/.agents/skills/dailybot/email/SKILL.md +++ b/.agents/skills/dailybot/email/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot-email description: Send emails to a confirmed recipient via Dailybot on behalf of the agent. Use for notifications, summaries, follow-ups, or any communication the developer asks you to send. Always confirm recipients with the developer before sending — never guess addresses. -version: "3.9.0" +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: false metadata: {"openclaw":{"emoji":"📧","homepage":"https://dailybot.com","requires":{"anyBins":["dailybot","curl"]},"primaryEnv":"DAILYBOT_API_KEY","install":[{"id":"cli-install-script","kind":"download","url":"https://cli.dailybot.com/install.sh","label":"Install Dailybot CLI (official script — preferred on Linux/macOS)"},{"id":"pip","kind":"pip","package":"dailybot-cli","bins":["dailybot"],"label":"Install Dailybot CLI via pip (fallback if binary fails)"}]}} @@ -12,7 +12,7 @@ allowed-tools: Bash, Read, Grep, Glob You send emails on behalf of the developer's agent through Dailybot. Useful for notifications, summaries, follow-ups, weekly reports, or any communication that should be delivered as email. -> **Requires `dailybot-cli >= 3.1.2`** (the skill-pack baseline). See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version). +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline). See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version). --- diff --git a/.agents/skills/dailybot/forms/SKILL.md b/.agents/skills/dailybot/forms/SKILL.md index f0a645b..5e55e53 100644 --- a/.agents/skills/dailybot/forms/SKILL.md +++ b/.agents/skills/dailybot/forms/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot-forms description: List, inspect, submit, update, and transition form responses via Dailybot — including forms with workflow states and audience-scoped permissions. Also authors forms — create and configure a form (workflow states, permissions, anonymous/public/approval, ChatOps command) and manage its questions (types, report titles, variations, conditional logic). Use when the developer wants to see available forms, fill out a survey, continue an in-progress response, move a response between states, read prior responses, or create/configure a form. Do not use for daily check-ins — those go through dailybot-checkin. -version: "3.9.0" +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: true metadata: {"openclaw":{"emoji":"📋","homepage":"https://dailybot.com","requires":{"anyBins":["dailybot","curl"]},"primaryEnv":"DAILYBOT_API_KEY","install":[{"id":"cli-install-script","kind":"download","url":"https://cli.dailybot.com/install.sh","label":"Install Dailybot CLI (official script — preferred on Linux/macOS)"},{"id":"pip","kind":"pip","package":"dailybot-cli","bins":["dailybot"],"label":"Install Dailybot CLI via pip (fallback if binary fails)"}]}} @@ -10,7 +10,7 @@ allowed-tools: Bash, Read, Grep, Glob # Dailybot Forms -> **Requires `dailybot-cli >= 3.1.2`** (the skill-pack baseline). The full forms lifecycle — `form list` / `submit` / `get` / `responses` / `response get` / `update` / `transition` / `delete` — plus the structured `--json` 4xx error shape are all available. If `dailybot --version` is below 3.1.2, ask the developer to run `dailybot upgrade`. See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version) for install commands and version-check tooling. +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline). The full forms lifecycle — `form list` / `submit` / `get` / `responses` / `response get` / `update` / `transition` / `delete` — plus the structured `--json` 4xx error shape are all available. If `dailybot --version` is below 3.7.0, ask the developer to run `dailybot upgrade`. See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version) for install commands and version-check tooling. You help developers work with the full Dailybot forms lifecycle: list, inspect, submit, update, transition between workflow states, and read prior responses. Forms are custom questionnaires created by team leads — feedback surveys, retrospectives, release checklists, approval flows, or any structured data collection. Some forms are simple "fill once and done"; others have **workflow states** (e.g. `draft → review → released`) with audience-scoped permissions on who can edit and who can transition. @@ -140,7 +140,7 @@ Returns all forms in the caller's organization. Every org member sees every org ### Pagination, search, and date filters -> **Note:** the shared list query flags below are part of the `dailybot-cli >= 3.1.2` baseline. Older CLIs +> **Note:** the shared list query flags below are part of the `dailybot-cli >= 3.7.0` baseline. Older CLIs > return the full list with no filtering. `form list` accepts the **full shared list query flag set** — pagination @@ -161,7 +161,7 @@ dailybot form list --all --json dailybot form list --page 2 --page-size 20 --json ``` -### Filter by owner — `--mine` and `--owner` (CLI >= 3.6.0) +### Filter by owner — `--mine` and `--owner` Pass **`--mine`** to narrow the result to only the forms **you own**, or **`--owner`** (repeatable) to filter by specific owners. `--owner` accepts @@ -183,7 +183,7 @@ dailybot form list --owner --owner --json > `--mine` or `--owner` instead — `--filter me` still works but maps to > the legacy `filter=me` parameter. -### Form owners picker — `form owners` (CLI >= 3.6.0) +### Form owners picker — `form owners` A lightweight endpoint to discover which org members own at least one form, without pulling the full member directory. @@ -197,12 +197,12 @@ dailybot form owners --json # machine-readable Each result has `uuid`, `full_name`, `image`, `role`, and optionally `email` (email is only visible to admins/managers — the CLI must not assume it exists). -### Server-side filtering, sorting, and archived forms (CLI >= 3.5.0) +### Server-side filtering, sorting, and archived forms | Flag | Values | Description | |------|--------|-------------| | `--filter` | `all`, `public`, `approval`, `workflow`, `archived` | Scope filter (server-side). `me` still works but is deprecated. | -| `--owner` | UUID, email, or name (repeatable) | Filter by form owner(s). Max 50. (`CLI >= 3.6.0`) | +| `--owner` | UUID, email, or name (repeatable) | Filter by form owner(s). Max 50. | | `--order` | `alphabetical`, `recent`, `total` | Sort field (`total` = total response count). | | `--ascending` / `--asc` | flag | Sort ascending (default: descending). | | `--include-questions` | flag | Include question definitions in each form. | @@ -314,7 +314,7 @@ When the form has a workflow (`workflow.enabled: true`), the agent must understa ## Step 5.5 — Authoring forms (create / configure / questions) -> **Requires `dailybot-cli >= 3.1.2`** (the skill-pack baseline). The full authoring surface — `form create`, `form config` (workflow states, the three permission audiences, anonymous/public/brand/require-identity with `public_url`, approval + approvers, the ChatOps command), `form archive`, the `form questions add|edit|delete|reorder` group, resolving people by email, `--no-approvers`, the 3 report-channel cap, and the **create requires ≥ 1 question** rule (`questions_required`) — is all available. If `dailybot --version` is below 3.1.2, ask the developer to run `dailybot upgrade`. +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline). The full authoring surface — `form create`, `form config` (workflow states, the three permission audiences, anonymous/public/brand/require-identity with `public_url`, approval + approvers, the ChatOps command), `form archive`, the `form questions add|edit|delete|reorder` group, resolving people by email, `--no-approvers`, the 3 report-channel cap, and the **create requires ≥ 1 question** rule (`questions_required`) — is all available. If `dailybot --version` is below 3.7.0, ask the developer to run `dailybot upgrade`. Everything above this point *reads* and *responds to* forms. This section *builds and reshapes* them. An agent with the right permissions can now create a form, wire up its workflow states, permission audiences, approval flow, and ChatOps command, and manage its questions — all end-to-end from the CLI, without opening the Dailybot webapp. @@ -824,7 +824,7 @@ Useful flags: > responses (admin/owner only), not every page. > See [`../shared/list-query-and-errors.md`](../shared/list-query-and-errors.md). -### Advanced response filters (CLI >= 3.5.0) +### Advanced response filters | Flag | Values | Description | |------|--------|-------------| @@ -1067,15 +1067,15 @@ Always show the complete answer set before sending: | `--state` | `-s` | Optional initial state (workflow forms only). Defaults to the form's initial state. | | `--yes` | `-y` | Skip confirmation. | | `--json` | | Machine-readable JSON output. | -| `--automation` | | Submit as an automation — channel notifications show no submitter name. (`CLI >= 3.4.0`) | -| `--anonymous` | | Submit anonymously — channel notifications show a random generated name. (`CLI >= 3.4.0`) | -| `--guest-name` | | Guest submitter full name (used with `--automation` for third-party submissions). (`CLI >= 3.5.0`) | -| `--guest-email` | | Guest submitter email (validated client-side). (`CLI >= 3.5.0`) | -| `--source` | | Provenance label, max 512 chars (e.g. `workflow:release-pipeline`). Works with any mode. (`CLI >= 3.5.0`) | +| `--automation` | | Submit as an automation — channel notifications show no submitter name. | +| `--anonymous` | | Submit anonymously — channel notifications show a random generated name. | +| `--guest-name` | | Guest submitter full name (used with `--automation` for third-party submissions). | +| `--guest-email` | | Guest submitter email (validated client-side). | +| `--source` | | Provenance label, max 512 chars (e.g. `workflow:release-pipeline`). Works with any mode. | > **`--automation` vs `--anonymous`:** Both are independent booleans. `--automation` hides the submitter entirely; `--anonymous` replaces them with a random name. When combined, `automation` takes precedence for the channel display. Neither flag affects who owns the response in the dashboard — it only controls the notification appearance. -### Submission modes (CLI >= 3.5.0) +### Submission modes | Mode | Flags | Channel notification | |------|-------|---------------------| @@ -1139,7 +1139,7 @@ dailybot form transition --yes ``` > **You can pass either `to_state` (machine key) or `label` (display text).** -> Since CLI `>= 3.3.0`, the CLI resolves labels to keys automatically — e.g. +> The CLI resolves labels to keys automatically — e.g. > `"Mark released"` → `released`. In `allowed_transitions`, `to_state` is the > machine key (`released`) and `label` is display text (`Mark released`). Both > are accepted; the CLI performs a case-insensitive lookup and translates labels diff --git a/.agents/skills/dailybot/forms/_custom-template/SKILL.md b/.agents/skills/dailybot/forms/_custom-template/SKILL.md index 4bd8aa7..cfd3fe1 100644 --- a/.agents/skills/dailybot/forms/_custom-template/SKILL.md +++ b/.agents/skills/dailybot/forms/_custom-template/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot-custom-form-template description: STARTER TEMPLATE — do not consume this file in place. Copy it to .agents/skills/dailybot-custom//SKILL.md in your own repo, then customize. This is the bootstrap skeleton for authoring a per-form custom skill that the universal dailybot-forms resolver will load from .dailybot/profile.json. -version: "3.9.0" +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: false allowed-tools: Bash, Read, Grep, Glob diff --git a/.agents/skills/dailybot/health/SKILL.md b/.agents/skills/dailybot/health/SKILL.md index 07e2623..0ba280f 100644 --- a/.agents/skills/dailybot/health/SKILL.md +++ b/.agents/skills/dailybot/health/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot-health description: Announce agent online/offline status to Dailybot and receive pending messages from the team. Use for long-running or scheduled agents to stay visible and pick up instructions. -version: "3.9.0" +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: false metadata: {"openclaw":{"emoji":"💚","homepage":"https://dailybot.com","requires":{"anyBins":["dailybot","curl"]},"primaryEnv":"DAILYBOT_API_KEY","install":[{"id":"cli-install-script","kind":"download","url":"https://cli.dailybot.com/install.sh","label":"Install Dailybot CLI (official script — preferred on Linux/macOS)"},{"id":"pip","kind":"pip","package":"dailybot-cli","bins":["dailybot"],"label":"Install Dailybot CLI via pip (fallback if binary fails)"}]}} @@ -12,7 +12,7 @@ allowed-tools: Bash, Read, Grep, Glob You announce the agent's status (online, working, offline, degraded) to Dailybot so the team knows whether the agent is alive and what it's doing. Health check responses also deliver pending messages from the team. -> **Requires `dailybot-cli >= 3.1.2`** (the skill-pack baseline). See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version). +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline). See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version). --- diff --git a/.agents/skills/dailybot/kudos/SKILL.md b/.agents/skills/dailybot/kudos/SKILL.md index bc96f5c..f862019 100644 --- a/.agents/skills/dailybot/kudos/SKILL.md +++ b/.agents/skills/dailybot/kudos/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot-kudos description: Give kudos to a teammate or to an entire team via Dailybot to recognize their contributions. Use when the developer wants to thank or recognize one person, or recognize a whole team (e.g. "kudos al equipo Engineering"). Do not use for general progress reports — those go through dailybot-report. -version: "3.9.0" +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: true metadata: {"openclaw":{"emoji":"🏆","homepage":"https://dailybot.com","requires":{"anyBins":["dailybot","curl"]},"primaryEnv":"DAILYBOT_API_KEY","install":[{"id":"cli-install-script","kind":"download","url":"https://cli.dailybot.com/install.sh","label":"Install Dailybot CLI (official script — preferred on Linux/macOS)"},{"id":"pip","kind":"pip","package":"dailybot-cli","bins":["dailybot"],"label":"Install Dailybot CLI via pip (fallback if binary fails)"}]}} @@ -10,7 +10,7 @@ allowed-tools: Bash, Read, Grep, Glob # Dailybot Kudos -> **Requires `dailybot-cli >= 3.1.2`** (the skill-pack baseline). Giving kudos to a user (`--to`) or a team (`--team`), and browsing kudos (`list` / `org` / `wall-of-fame`), are all available. If `dailybot --version` is below 3.1.2, ask the developer to run `dailybot upgrade`. See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version) for install commands and version-check tooling. +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline). Giving kudos to a user (`--to`) or a team (`--team`), and browsing kudos (`list` / `org` / `wall-of-fame`), are all available. If `dailybot --version` is below 3.7.0, ask the developer to run `dailybot upgrade`. See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version) for install commands and version-check tooling. You help developers recognize teammates by sending kudos through Dailybot. Kudos are team-visible appreciation messages — the whole team sees them in Dailybot's recognition feed and in connected chat platforms (Slack, Teams, Discord). @@ -32,7 +32,7 @@ If the developer has only an API key, kudos still work — the CLI falls back to ## Browsing kudos (read) > **Baseline:** the three read commands below (`kudos list`, `kudos org`, -> `kudos wall-of-fame`) are part of the `dailybot-cli >= 3.1.2` baseline. +> `kudos wall-of-fame`) are part of the `dailybot-cli >= 3.7.0` baseline. Beyond *giving* kudos, an agent can **browse** the recognition feed and read org-wide stats. All three return the standard pagination envelope where diff --git a/.agents/skills/dailybot/messages/SKILL.md b/.agents/skills/dailybot/messages/SKILL.md index f9a94e0..64c6a3f 100644 --- a/.agents/skills/dailybot/messages/SKILL.md +++ b/.agents/skills/dailybot/messages/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot-messages description: Check for pending messages and instructions from your team via Dailybot. Use when starting a work session, when idle, or when asked what to work on next. Messages are instructions that should influence your work. -version: "3.9.0" +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: false metadata: {"openclaw":{"emoji":"📬","homepage":"https://dailybot.com","requires":{"anyBins":["dailybot","curl"]},"primaryEnv":"DAILYBOT_API_KEY","install":[{"id":"cli-install-script","kind":"download","url":"https://cli.dailybot.com/install.sh","label":"Install Dailybot CLI (official script — preferred on Linux/macOS)"},{"id":"pip","kind":"pip","package":"dailybot-cli","bins":["dailybot"],"label":"Install Dailybot CLI via pip (fallback if binary fails)"}]}} @@ -14,7 +14,7 @@ You check for pending messages and instructions from the developer's team. Messa This is the "what should I work on next?" skill. -> **Requires `dailybot-cli >= 3.1.2`** (the skill-pack baseline). See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version). +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline). See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version). --- diff --git a/.agents/skills/dailybot/report/SKILL.md b/.agents/skills/dailybot/report/SKILL.md index 54928c9..c9afaa9 100644 --- a/.agents/skills/dailybot/report/SKILL.md +++ b/.agents/skills/dailybot/report/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot-report description: Report work progress to Dailybot. Activate after completing a discrete task or subtask, or after any batch of edits that modifies 3 or more files. Compose a standup-style update describing what changed and why. -version: "3.9.0" +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: true metadata: {"openclaw":{"emoji":"📡","homepage":"https://dailybot.com","requires":{"anyBins":["dailybot","curl"]},"primaryEnv":"DAILYBOT_API_KEY","install":[{"id":"cli-install-script","kind":"download","url":"https://cli.dailybot.com/install.sh","label":"Install Dailybot CLI (official script — preferred on Linux/macOS)"},{"id":"pip","kind":"pip","package":"dailybot-cli","bins":["dailybot"],"label":"Install Dailybot CLI via pip (fallback if binary fails)"}]}} @@ -123,7 +123,7 @@ trigger in a previous session. #### Check whether hooks apply, and whether they are already installed -1. **CLI version.** Run `dailybot --version`. If it reports below `3.1.2` +1. **CLI version.** Run `dailybot --version`. If it reports below `3.7.0` (or the CLI is absent), the `dailybot hook` group does not exist — skip Step 0b silently and continue to Step 1. The Step 0a trigger alone still works. diff --git a/.agents/skills/dailybot/report/hooks.md b/.agents/skills/dailybot/report/hooks.md index faa4df3..5c76e12 100644 --- a/.agents/skills/dailybot/report/hooks.md +++ b/.agents/skills/dailybot/report/hooks.md @@ -12,7 +12,7 @@ in once, and from then on the harness re-arms the reminders in every future session, container, and repo. No human reminders, no reliance on the model's memory. -> **Requires `dailybot-cli >= 3.1.2`** (the skill-pack baseline). The `dailybot hook` command group +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline). The `dailybot hook` command group > is available at this floor. > Check with `dailybot --version`; if older, ask the developer to run > `dailybot upgrade` once. Hooks installed against an older CLI fail @@ -163,7 +163,7 @@ the only remaining per-person step is `dailybot login`, and the | `soft_turn_threshold` | `8` (`5` in `continuous` mode when omitted) | Agent turns without a report before a soft nudge is eligible | Invalid `mode` values fall back to `"balanced"`; invalid `soft_turn_threshold` - values fall back to the mode default. (Part of the `dailybot-cli >= 3.1.2` + values fall back to the mode default. (Part of the `dailybot-cli >= 3.7.0` baseline; much older CLIs ignore `mode`/`soft_turn_threshold` and stay on the balanced defaults. @@ -182,7 +182,7 @@ the only remaining per-person step is `dailybot login`, and the | Symptom | Check | |---------|-------| -| Reminders never fire | Run `dailybot hook stop` manually after a commit — any output? Then check `dailybot --version` (>= 3.1.2), `.dailybot/disabled`, and the harness config actually contains the `dailybot hook` entries | +| Reminders never fire | Run `dailybot hook stop` manually after a commit — any output? Then check `dailybot --version` (>= 3.7.0), `.dailybot/disabled`, and the harness config actually contains the `dailybot hook` entries | | Reminder fires but mentions old history | Delete the repo's file under `~/.config/dailybot/ledger/` — the baseline re-anchors silently | | Too noisy | Raise `min_interval_minutes` in `.dailybot/profile.json`, or use `dailybot hook dismiss --minutes ` | | Not reminded often enough (research-heavy repo) | Set `"mode": "continuous"` (or lower `soft_turn_threshold` / `min_interval_minutes`) in `.dailybot/profile.json` | diff --git a/.agents/skills/dailybot/shared/auth.md b/.agents/skills/dailybot/shared/auth.md index f003b58..0a43e62 100644 --- a/.agents/skills/dailybot/shared/auth.md +++ b/.agents/skills/dailybot/shared/auth.md @@ -45,7 +45,7 @@ treat that as session-wide consent. > [!NOTE] > **Installing a specific version.** Both installers default to the latest -> release but accept a version pin (the skill-pack baseline is **`dailybot-cli >= 3.1.2`**): +> release but accept a version pin (the skill-pack baseline is **`dailybot-cli >= 3.7.0`**): > - `install.sh` — set `DAILYBOT_VERSION=` in the environment, or > pass `bash -s -- --version `. Example (drop it into the verified > snippet below, right before `bash /tmp/install.sh`): @@ -357,32 +357,82 @@ Dailybot → Settings → API Keys. ## 4. Auth model — unified Bearer-first priority everywhere -As of `dailybot-cli >= 3.5.1`, **all endpoints use the same auth priority: -Bearer token first, API key second.** There is no longer a split where agent +**All endpoints use the same auth priority: Bearer token first, API key +second** (unified in CLI 3.5.1). There is no longer a split where agent endpoints preferred API key and user endpoints preferred Bearer — the CLI now behaves consistently everywhere. The server accepts both credentials on every `/v1/` endpoint, so the two paths are functionally identical. -| Scope | Auth priority (since CLI 3.5.1) | Used by | +One deliberate exception (CLI >= 3.7.0): when the API key resolves from a +repo's `.dailybot/env.json` active profile, the client sends `X-API-KEY` +**first** — the per-repo key must beat the global Bearer session even against +a server that would accept the Bearer, and the session token must never be +transmitted to the env.json server. The 401/403 alt-credential retry covers +the reverse direction. See [`env-json.md`](env-json.md). + +| Scope | Auth priority | Used by | |-------|--------------------------------|---------| | **All endpoints** | Bearer preferred → API key fallback | Every command: `agent update`, `form submit`, `kudos`, `chat send`, `ask`, etc. | | **Login lifecycle** | OTP / Bearer only | `dailybot login`, `dailybot logout` (revokes the session token) | +### Per-repo API key override (`.dailybot/env.json`) — CLI >= 3.7.0 + +Since `dailybot-cli >= 3.7.0`, the CLI also honours an **opt-in, gitignored** +per-repo file at `/.dailybot/env.json` that carries API keys + optional +URL overrides for one or more environments. When present with an *active* +profile, it sits **just below** explicit `--profile` / `--api-url` flags in +the auth-resolution order — above `agents.json`, above `DAILYBOT_API_KEY`, +above `config.json`, above the login Bearer. + +If the developer asks about "per-repo API keys", "staging vs prod", +"different orgs per project", or wants to override auth without touching +env vars, route them to [`shared/env-json.md`](env-json.md) — it has the +full schema, CLI commands (`dailybot env add / use / show / list / remove / +off / on`), security posture, and worked examples. + +`env.json` is orthogonal to `profile.json`: + +- `profile.json` = identity (tracked in git, team-shared). +- `env.json` = auth context (gitignored, per-developer). + +Neither field overlaps. Both can be present. + Both credentials can coexist — the CLI stores them separately, and a developer can hold an API key and a Bearer session at the same time. -### Automatic fallback on 401 (CLI >= 3.5.1) +### Automatic fallback on 401 or 403 -When the primary credential is rejected (HTTP 401), the CLI automatically -retries once with the alternative credential if available. This is -bidirectional: +When the primary credential is rejected (HTTP **401 or 403**), the CLI +automatically retries once with the alternative credential if available. +This is bidirectional: - **Bearer expired** → retries with API key - **API key stale/revoked** → retries with Bearer session -This prevents users from being blocked when one credential goes stale while -the other is still valid (e.g., a revoked API key in `agents.json` while a -valid login session exists). +Both `_agent_request()` (agent-scoped endpoints) and `_request()` (all +user-scoped endpoints — `auth_status`, `checkin`, `form`, `kudos`, `chat`, +`ask`, `user`, `team`, ...) implement identical retry semantics. Login- +lifecycle endpoints (`request_code`, `verify_code`, `logout`, agent +registration) never retry because the credential IS the thing being +negotiated or invalidated. + +The retry covers three real-world cases at zero UX cost: + +1. **`env.json` active + stale Bearer.** Prod OTP session on disk, `cd` into + a repo whose `env.json` points at `http://localhost:8000` — the local + API rejects the Bearer (403), the retry uses the `env.json` API key, + the command succeeds. `dailybot status --auth` then reports + `Authenticated via API key` (not `login (OTP)`) — the report reflects + what actually worked, not what was tried first. +2. **Bearer expired** in normal single-org use → falls back to a locally + configured API key without a login prompt. +3. **API key revoked** while a valid login session exists → falls back to + the Bearer. + +Retrying on **403** in addition to 401 is required because Django/DRF +frequently returns 403 for rejected credentials (see +[DRF authentication docs](https://www.django-rest-framework.org/api-guide/authentication/#unauthorized-and-forbidden-responses)). +Relying on 401 alone leaves the local-Django + `env.json` case broken. > **Parity.** All commands — user-scoped (`checkin`, `form`, `kudos`, `user`), > agent-scoped (`agent update`, `agent health`), and the AI chat (`ask`) — diff --git a/.agents/skills/dailybot/shared/dashboard-urls.md b/.agents/skills/dailybot/shared/dashboard-urls.md index 1eb00f5..7a9e4b4 100644 --- a/.agents/skills/dailybot/shared/dashboard-urls.md +++ b/.agents/skills/dailybot/shared/dashboard-urls.md @@ -1,8 +1,9 @@ # Shared reference — Dailybot dashboard URLs -> **Requires `dailybot-cli >= 3.3.0`** — the release that introduced the +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline). The > `--app-url` flag and `DAILYBOT_APP_URL` env var for configuring the dashboard -> base URL. Earlier versions hardcode the production URL. +> base URL are available at this floor, as is the per-profile `app_url` in +> [`env-json.md`](env-json.md). This is the **single source of truth** for all dashboard (webapp) URLs that agents can embed in reports, messages, or surface to the developer. Sub-skills diff --git a/.agents/skills/dailybot/shared/env-json.md b/.agents/skills/dailybot/shared/env-json.md new file mode 100644 index 0000000..c679e64 --- /dev/null +++ b/.agents/skills/dailybot/shared/env-json.md @@ -0,0 +1,453 @@ +# Per-repo API key override (`.dailybot/env.json`) + +> **Read this if the developer asks about "switching between orgs per repo", "local dev keys", "logging into a staging org just for this project", or setting up "different Dailybot environments" for testing.** This is a single source of truth for the `env.json` workflow — sub-skills link here instead of duplicating the rules. + +The Dailybot CLI (>= **3.7.0**) supports a per-repository file at `/.dailybot/env.json` that carries API keys + optional URL overrides for one or more environments (`live`, `local`, `staging`, ...). When a profile is *active*, it overrides `DAILYBOT_API_KEY`, `config.json`, and the login Bearer session **for the enclosing repo only** — enabling the developer to be "logged into different orgs in different repos" without touching global state or env vars. + +`env.json` is **opt-in, gitignored, and never required**. The CLI works exactly as before when the file is absent. + +--- + +## STOP — the one thing you MUST enforce as an agent + +**`.dailybot/env.json` must NEVER be committed to git. Ever. Under any circumstance.** + +If the developer's request involves creating, editing, sharing, moving, or explaining `env.json`, you must treat "keep it gitignored" as a non-negotiable invariant. Concretely, that means: + +- **NEVER** run or suggest `git add .dailybot/env.json` (or `git add -A` / `git add .` from a place that would sweep it in). The CLI's `add` command writes the file to disk — that is the *only* place it should ever exist. +- **NEVER** `cat`, `head`, `tail`, or otherwise print the raw file contents into the chat, into a report, into a PR body, or into any other artifact — API keys live inside. Use `dailybot env show` / `dailybot env list` which mask them. +- **NEVER** copy the file into `tmp/`, into a docs example, into a test fixture, or into any other tracked location. If you need to reference structure, use the placeholder schema shown in this doc (with `sk_local_xxxx`-style dummy keys). +- **NEVER** try to work around the CLI's fatal refuse-if-tracked guard (see § "Security — non-negotiable rules" below). If the CLI is blocking a command because `env.json` is tracked, the *only* correct answer is `git rm --cached .dailybot/env.json` + rotate the exposed keys — not `--no-verify`, not "temporarily untrack", not editing the guard away. +- **ALWAYS** verify the repo's `.gitignore` contains `.dailybot/*` before the developer's first `dailybot env add`. If it doesn't, add it (and commit that change) *first*. +- **ALWAYS** treat "the file was committed at some point in history" as a compromise: rotate every key in it via the Dailybot dashboard immediately, then follow the recovery recipe below. + +The rule is absolute because git history is forever. On a public repo the keys are burned the instant the push lands; on a private repo they still leak to every collaborator, every past fork, every CI cache, and every backup. `git revert` does not undo the exposure. **Rotate, don't revert.** + +The CLI enforces this same rule with four independent protections (gitignore convention, `0o600` permissions, a fatal load-time guard in the root `cli()` callback, and an advisory write-time `git check-ignore` warning). All of them must be in place. If any of them looks broken on the developer's machine, treat it as a bug worth reporting — do NOT paper over it. + +--- + +## When to reach for `env.json` + +Suggest it when the developer says any of: + +- *"I want a local key just for this project."* +- *"How do I test against staging without messing up my prod login?"* +- *"I need to be in org A in this repo and org B in another repo."* +- *"Can I have per-project Dailybot credentials?"* + +Do **not** suggest it when: + +- The developer is in CI. Recommend `DAILYBOT_API_KEY` as an env var instead — leaves no on-disk secret to clean up. +- The developer wants team-shared identity for the repo — that's [`profile.json`](repo-profile.md), not `env.json`. +- The developer has a single Dailybot org and a working login session. `dailybot login` + global config is simpler. + +--- + +## Distinction from `profile.json` (critical, do not confuse them) + +The two files live side-by-side in `.dailybot/` but serve **opposite roles**: + +| File | Committed? | Contains | Role | +|---|---|---|---| +| `.dailybot/profile.json` | **Yes** (tracked) | `name`, `default_metadata`, `report`, `vars` | **Identity** — how the agent signs reports (team-shared) | +| `.dailybot/env.json` | **No** (gitignored) | `api_key`, `api_url`, `app_url` per profile | **Auth context** — which org the CLI talks to (per-developer, per-machine) | + +Neither file overlaps on any field. Both can be present, and typically will be: `profile.json` pins the report signature ("this repo's reports come from `Core Hub Bot`"), while `env.json` picks which Dailybot org those reports get sent to on your machine right now. + +**Under NO circumstances** should you write API keys to `profile.json` — the CLI hard-errors with `RepoProfileError` when it detects a `key` field there. `env.json` is the ONLY sanctioned place inside `.dailybot/` for credentials. + +--- + +## Schema + +```json +{ + "disabled": false, + "active": "local org 1", + "profiles": [ + { + "name": "live", + "api_key": "sk_live_xxxxxxxx" + }, + { + "name": "local org 1", + "api_key": "sk_local_xxxxxxxx", + "api_url": "http://localhost:8000", + "app_url": "http://localhost:8090" + }, + { + "name": "staging", + "api_key": "sk_staging_xxxxxxxx", + "api_url": "https://staging-api.example.com", + "app_url": "https://staging-app.example.com" + } + ] +} +``` + +| Field | Type | Required? | Purpose | +|---|---|---|---| +| `disabled` | boolean | optional (default `false`) | Kill-switch. `true` ignores the whole file even if `active` points to a valid profile. Preserves `active` for one-command re-enable. Must be a **JSON boolean** — a hand-edited string like `"true"` is NOT honored: the CLI warns loudly and the file **stays active** (use `dailybot env off` instead). | +| `active` | string \| null | optional | Name of the profile to use. `null` / `""` / missing / unknown-name → file is *inert* and resolution falls through. Only one active at a time. | +| `profiles` | list of objects | **required** | Every configured environment. | +| `profiles[].name` | string | **required** | Unique per file. Human-friendly, may contain spaces. | +| `profiles[].api_key` | string | **required** | The API key for this environment. Plain-text on disk — gitignore is mandatory. | +| `profiles[].api_url` | string | optional | Overrides `DAILYBOT_API_URL` / `credentials.json` when this profile is active. Falls through to `https://api.dailybot.com` when absent. | +| `profiles[].app_url` | string | optional | Overrides `DAILYBOT_APP_URL` when this profile is active. Falls through to `https://app.dailybot.com` when absent. | + +Unknown keys are logged as a warning and ignored (forward-compatibility). snake_case only — camelCase is a schema violation. + +--- + +## CLI workflow (always prefer these commands over hand-editing) + +```bash +# First profile — creates the file at /.dailybot/env.json with 0o600 +# perms and auto-marks itself active. +dailybot env add \ + --name "local org 1" \ + --key sk_local_xxxxxxxx \ + --api-url http://localhost:8000 \ + --app-url http://localhost:8090 + +# Additional profiles — appended, active pointer unchanged. +dailybot env add --name live --key sk_live_yyyyyyyy +dailybot env add --name staging --key sk_staging_zzzzzzzz \ + --api-url https://staging-api.example.com + +# Switch which profile is active. +dailybot env use staging +dailybot env use "" # clear active → fall through to global auth + +# Inspect. +dailybot env show # resolved profile (API key masked) +dailybot env list # all profiles, active marked +# `env show` also prints an explicit "Disabled: no" row (since `disabled: +# false` is normalized away on write) and resolves defaulted API/Webapp URLs +# so the developer sees the concrete server the context points at. + +# Kill-switch — preserves `active` so `on` restores instantly. +dailybot env off +dailybot env on + +# Delete a profile. If it was the active one, active is cleared. +dailybot env remove staging --yes +``` + +The CLI ALWAYS masks API keys in output (`sk_l****` — first 4 chars + `****`). It never echoes the full key back. + +--- + +## Auth resolution order (updated in CLI 3.7.0) + +The full precedence for `api_key` / `api_url` / `app_url` when a repo has `env.json`: + +| # | Layer | Notes | +|---|---|---| +| 1 | `--profile` / `--api-url` / `--app-url` CLI flags | Per-invocation escape hatch — always wins | +| **2** | **`.dailybot/env.json` active profile** | **New in 3.7.0** — the whole innovation | +| 3 | `.dailybot/profile.json::profile` → `agents.json` | Existing repo profile → global agent profile chain | +| 4 | `agents.json` default profile | Global default | +| 5 | `DAILYBOT_API_KEY` env var | Session-level | +| 6 | `config.json::api_key` (from `dailybot config key=...`) | Persistent global | +| 7 | Login session Bearer token (`credentials.json::token`) | From `dailybot login` | + +When `env.json::disabled` is `true`, or `active` is empty/null/unknown, the file is transparently skipped and every resolver behaves as if the file didn't exist. + +Two precision notes (CLI >= 3.7.0): + +- **Layer 2 holds on the wire, not just in resolution.** When the key comes from `env.json`, the HTTP client sends `X-API-KEY` on the **first** attempt even if a Bearer login session exists — the per-repo key wins even against a server that would have accepted the Bearer, and the global session token is never transmitted to the env.json server. Keys from layers 5–6 keep the historical Bearer-first wire order. +- **Layer 1 vs layer 2 for `agent *` commands:** a keyed `agents.json` profile beats `env.json` only when selected with an explicit `--profile` flag. The same profile resolved implicitly (via `profile.json::profile` or as the `agents.json` default) yields to `env.json`. `dailybot agent profiles --resolve` always shows exactly what will be sent. + +--- + +## Security — non-negotiable rules + +`env.json` is one of two files (the other being `credentials.json` in the global config dir) where the CLI stores API keys in plain text. Inside a repo, extra care is required — four independent layers of protection back the "never commit" rule. + +### 1. Gitignore is mandatory (and automatic in most setups) + +Every Dailybot-aware repo should have this in its root `.gitignore`: + +```gitignore +.dailybot/* +!.dailybot/profile.json +``` + +The broad ignore covers `env.json` automatically. **`env.json` is NEVER excepted** — only `profile.json` is. The Dailybot CLI's own `.gitignore` uses this exact pattern. There is no legitimate reason to un-ignore `env.json` — not with `!.dailybot/env.json`, not with a per-machine dot-file trick, not with `git update-index --assume-unchanged` (that only defers the leak). + +### 2. Owner-only permissions (`0o600`) + +Every write via `dailybot env` creates the file with mode `0o600` **from the first byte** (`os.open(..., 0o600)` — there is no umask window where the keys sit world-readable), and every load re-chmods it defensively — even if the file was created by an editor or `cp` with a lax umask. + +### 3. Fatal refuse-if-tracked guard — fires at the ROOT of every CLI invocation + +The root `cli()` callback in `dailybot_cli/main.py` calls `load_repo_env()` on **every command invocation**. That function runs: + +```bash +git ls-files --error-unmatch .dailybot/env.json +``` + +If the file is tracked, `RepoEnvError` fires, `print_error()` writes to stderr, and `SystemExit(1)` aborts the process **before any subcommand runs**. "Tracked" includes **staged-but-uncommitted** — `git ls-files` reads the index, so a stray `git add -f` trips the guard before a commit ever happens. Sample stderr: + +``` +Error: /path/.dailybot/env.json is tracked by git. This file contains API keys and +must never be committed. Fix with: + git rm --cached .dailybot/env.json + # ensure your .gitignore ignores .dailybot/env.json + git commit -m 'chore: untrack .dailybot/env.json' +The CLI refuses to load env.json while it is tracked. +``` + +**No auth-consuming command bypasses this** — `dailybot status`, `dailybot user list`, `dailybot form list`, `dailybot agent update`, `dailybot env show`, `dailybot login`, `dailybot upgrade`, `dailybot uninstall`, everything is blocked. There is no silent fallback to global auth — the CLI refuses to operate until `env.json` is untracked. Exactly two carve-outs: + +- `dailybot --help` / `dailybot --version` — Click short-circuits them before the callback runs, so the developer can always read instructions. +- The `dailybot hook *` group — it prints the same error to stderr but **still runs and exits 0**, honoring its always-exit-0 harness contract (a tracked env.json must not break every agent session in the repo). Hook commands are local-only and never consume env.json auth, so nothing leaks through this path. + +Edge case: if the `git` binary is not on PATH but a `.git` directory exists in an ancestor, the guard cannot verify tracking — it degrades to a **loud warning** instead of a silent pass. Treat that warning as a prompt to check `.gitignore` manually. + +### 4. Write-time gitignore warning + +`dailybot env add` also runs `git check-ignore` after writing. If `env.json` is **not** covered by any ignore rule, a warning fires on stderr — non-fatal (a brand-new repo might not have a `.gitignore` yet) but very visible: + +``` +Warning: /path/.dailybot/env.json is NOT gitignored. This file contains API keys +and must never be committed. Add `.dailybot/*` (except `!.dailybot/profile.json`) +to your .gitignore before committing. +``` + +### If the developer accidentally committed `env.json` + +Treat it as a compromise — the world has seen the keys the instant the push landed. Recovery: + +1. **Rotate every key in the file immediately** at Dailybot → Settings → API Keys. The old keys must be considered burned. +2. `git rm --cached .dailybot/env.json && git commit -m 'chore: untrack .dailybot/env.json'` +3. Verify `.gitignore` covers `.dailybot/*` (add it if missing) — otherwise the very next `dailybot env add` will re-stage the file. +4. Rewrite `env.json` locally with the freshly rotated keys via `dailybot env add ...`. +5. If the repo has been pushed anywhere (public or private), follow [GitHub's guide to removing sensitive data](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository) — but do NOT skip step 1. Rotation is what actually contains the exposure; history rewrite is cosmetic and does not undo the leak. + +Do NOT try to `git filter-repo` the leaked file out and call it done — assume compromise and rotate first, rewrite history second. + +### Quick full audit an agent can run on demand + +If the developer asks "is my env.json really safe?", run this end-to-end check: + +```bash +ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)" +ENV_FILE="$ROOT/.dailybot/env.json" + +echo "--- 1) Does the file exist? ---" +[ -f "$ENV_FILE" ] && echo "yes: $ENV_FILE" || echo "no (nothing to audit)" + +echo "--- 2) Is it gitignored? ---" +(cd "$ROOT" && git check-ignore -v .dailybot/env.json) || echo "NOT IGNORED (fix .gitignore)" + +echo "--- 3) Is it accidentally tracked? ---" +(cd "$ROOT" && git ls-files --error-unmatch .dailybot/env.json 2>/dev/null) \ + && echo "TRACKED (SECURITY VIOLATION — rotate keys + git rm --cached)" \ + || echo "not tracked (good)" + +echo "--- 4) File permissions ---" +[ -f "$ENV_FILE" ] && stat -c '%a %n' "$ENV_FILE" 2>/dev/null || stat -f '%A %N' "$ENV_FILE" +# Expect 600. + +echo "--- 5) CLI resolution ---" +dailybot env show # masks API keys; confirms the CLI is reading the file +``` + +Any of 2/3/4 tripping = actionable finding. + +--- + +## Detection pre-flight (when an agent is helping a developer manage keys) + +Only run this if the developer's request explicitly touches per-repo auth. Do not preemptively read env.json for every session — it contains secrets and there's no benefit to loading it if you're not being asked about it. + +```bash +ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)" +ENV_FILE="$ROOT/.dailybot/env.json" + +if [ -f "$ENV_FILE" ]; then + echo "REPO_ENV_EXISTS=1" + # NEVER cat this file — it contains API keys. Use the CLI's show/list + # subcommands which mask keys automatically: + dailybot env show 2>&1 +else + echo "REPO_ENV_EXISTS=" +fi +``` + +Rules: + +- **Never `cat`, `head`, or otherwise print the raw file** — API keys are inside. Use `dailybot env show` / `dailybot env list` which mask them. +- **Never suggest committing `env.json`** — the CLI will refuse to load it once it's tracked. +- **Never write API keys into `profile.json`** — that's a hard error. +- If the developer asks "what env am I in?", use `dailybot env show` (masked) — do not read the file directly. + +--- + +## Worked examples + +### Example 1 — First-time setup for a local dev org + +Developer: *"I need to test against my local Dailybot instance for this project without breaking my prod login."* + +```bash +# 1. Confirm CLI >= 3.7.0 (env command exists). +dailybot env --help >/dev/null 2>&1 || { + echo "This feature requires dailybot-cli >= 3.7.0. Run: dailybot upgrade" >&2 +} + +# 2. Ensure the gitignore covers .dailybot/* (create if needed). +grep -q '^\.dailybot/\*' .gitignore 2>/dev/null || { + cat >> .gitignore <<'EOF' + +# Dailybot per-repo state (env.json contains API keys — never commit it) +.dailybot/* +!.dailybot/profile.json +EOF +} + +# 3. Add the local profile. It becomes active automatically because it's the first. +dailybot env add \ + --name local \ + --key sk_local_xxxxxxxx \ + --api-url http://localhost:8000 \ + --app-url http://localhost:8090 + +# 4. Verify. +dailybot env show +``` + +Every subsequent `dailybot` command in this repo now talks to `http://localhost:8000` with the local key. In every other repo, the prod login remains untouched. + +### Example 2 — Toggling between staging and prod for QA + +Developer: *"I want to reproduce a staging bug, then switch back to prod."* + +```bash +dailybot env add --name prod --key sk_prod_xxxx # first → auto-active +dailybot env add --name staging --key sk_staging_yyyy \ + --api-url https://staging-api.example.com + +# Switch to staging for the bug repro session. +dailybot env use staging + +# ... reproduce the bug ... + +# Switch back. +dailybot env use prod +``` + +### Example 3 — Temporarily disabling env.json to test global auth + +Developer: *"I want to see what would happen with my global config for a minute, but don't lose my env.json setup."* + +```bash +dailybot env off # env.json ignored, CLI falls through to global auth +# ... test something ... +dailybot env on # restores the previously active profile +``` + +`env off` sets `disabled: true` at the top level — the `active` selection is preserved so `env on` restores it instantly. + +Verification pattern the developer can run to prove the toggle actually works: + +```bash +dailybot env show # Active env.json Profile: local +dailybot status --auth # → Authenticated via API key (local org) + +dailybot env off +dailybot env show # env.json is disabled (active would be: local) +dailybot status --auth # → Authenticated via login (OTP) (falls back to Bearer) + +dailybot env on +dailybot env show # Active env.json Profile: local (restored) +dailybot status --auth # → Authenticated via API key (local org again) +``` + +If step 2 does not fall back — i.e., the CLI keeps using the env.json profile after `env off` — that's a bug; report it. + +### Example 4 — Removing an environment cleanly + +```bash +dailybot env remove staging --yes +# If 'staging' was the active profile, active is cleared and the CLI +# falls back to global auth until you run `dailybot env use ` again. +``` + +--- + +## Interaction with existing auth flows + +- **`dailybot login` still works.** It writes to `~/.config/dailybot/credentials.json` (Bearer session). If `env.json` is active for a repo, that key wins over the Bearer for that repo. In other repos (or when `env.json` is disabled/inert), the Bearer takes over normally. +- **`dailybot logout` is unaffected.** It only clears the Bearer session. Your `env.json` remains intact. +- **`dailybot config key=...` still works.** It writes to `~/.config/dailybot/config.json`. `env.json` sits above it in the precedence order. +- **`DAILYBOT_API_KEY` still works.** For CI or one-off overrides. `env.json` beats it inside a repo; outside a repo (or when disabled), the env var wins. +- **Repo `profile.json` is orthogonal.** It still governs the *display name* and `default_metadata` for reports. `env.json` provides *credentials + URLs*. Both can be present. + +### env.json key first + transparent alt-credential retry (auto) + +When the resolved API key comes from `env.json`, the CLI's HTTP client sends it on the **first** attempt — the global Bearer session never reaches the env.json server. This is what makes the "logged into prod, `cd` into a local-dev repo" case Just Work in one round-trip: + +``` + + client.auth_status() + | + | Attempt 1: X-API-KEY -> http://localhost:8000 + | 200 OK (prod Bearer never leaves the machine) + | + + returns local org data (silently) +``` + +Backing that up, the client automatically retries every user-scoped and agent-scoped call **once** with the alternative credential when the server answers 401 or 403 — in either direction (stale env.json key → Bearer, stale Bearer → API key). + +Retry semantics: + +- Triggers on **HTTP 401 or 403** (Django/DRF answers 403 for rejected credentials just as often as 401; both are treated as "credential problem, try the other one"). +- Fires **at most once per call** with the alternative credential — a double rejection surfaces as a normal auth error. +- **Login-lifecycle endpoints do NOT retry** — `dailybot login`, `dailybot logout`, and the agent-registration challenge always report the truth of what happened (the credential IS what's being negotiated there, or invalidated). +- **`dailybot status --auth` inspects the auth mode after the call** and reports which credential actually succeeded on the wire (`Authenticated via API key` vs `Authenticated via login (OTP)`), so the developer always sees the truth. +- **`dailybot login` inside a repo with an active env.json profile warns first** — login persists the resolved `api_url` into the GLOBAL `~/.config/dailybot/credentials.json`, so the CLI names the profile and the server and suggests `dailybot env off` before proceeding. + +Ships with the same CLI floor as `env.json` itself. + +--- + +## Troubleshooting + +**"The CLI is not using my env.json."** +1. `dailybot env show` — is it reporting the profile you expect? +2. Look at `disabled`, `active`, and the walk-up path. `env show` prints the resolved file path — is it the one you edited? +3. Are you running with `--profile` / `--api-url` / `--app-url`? Flags win. +4. Did you edit the file directly? Check the JSON — the CLI's `env` commands validate on write, but hand-edits can produce invalid JSON that the loader rejects with a parse warning (printed to stdout, once per process) before falling back to global auth. + +**"The CLI refuses to run and complains about tracked env.json."** +Run the fix printed in the error. This is the fatal refuse-if-tracked guard doing its job. (Exception: `dailybot hook *` commands print the error but still run and exit 0 — that is by design, not a hole; see § Security above.) + +**"I set `disabled` to `"true"` by hand and the file is still active."** +`disabled` must be a JSON boolean (`true`, no quotes). The CLI warns about the string and treats it as `false` so a typo never silently changes which org you talk to. Run `dailybot env off` instead of hand-editing. + +**"I edited env.json by hand and now nothing works."** +`dailybot env show` will surface schema warnings. If unrecoverable, delete the file and re-add profiles via `dailybot env add`. + +**"I want the same profile across many repos without duplicating it."** +That's what `~/.config/dailybot/agents.json` (global profiles) is for — see `dailybot agent configure`. `env.json` is intentionally per-repo. + +--- + +## Version compatibility + +- Requires **`dailybot-cli >= 3.7.0`**. Older CLIs never look at `.dailybot/env.json` and treat it as harmless clutter. +- The Dailybot agent skill pack targeting this doc requires the same floor. +- If a developer is on an older CLI, offer to upgrade first: `dailybot upgrade` (auto-detects install method). + +--- + +## See also + +- [`shared/auth.md`](auth.md) — the general authentication flow (OTP login, API key alternatives, CLI installation). +- [`shared/repo-profile.md`](repo-profile.md) — the sibling file `profile.json` (agent identity, committed). +- [CLI configuration reference](https://github.com/DailybotHQ/cli/blob/main/docs/CONFIGURATION.md#repo-level-env-override-dailybotenvjson) — canonical schema + precedence + security posture. +- [CLI auth-resolution order](https://github.com/DailybotHQ/cli/blob/main/AGENTS.md#14-auth-resolution-order-do-not-break) — the per-field precedence the CLI implements. +- [CLI security posture](https://github.com/DailybotHQ/cli/blob/main/docs/SECURITY.md) — the four-layer protection for `env.json`. diff --git a/.agents/skills/dailybot/shared/list-query-and-errors.md b/.agents/skills/dailybot/shared/list-query-and-errors.md index 1c15fa2..c48cec8 100644 --- a/.agents/skills/dailybot/shared/list-query-and-errors.md +++ b/.agents/skills/dailybot/shared/list-query-and-errors.md @@ -1,10 +1,10 @@ # Shared reference — list query flags, pagination, and machine-readable errors -> **Requires `dailybot-cli >= 3.1.2`** (the skill-pack baseline). Everything on this page — the shared +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline). Everything on this page — the shared > list query flags, the `{count, next, previous, results}` pagination envelope, > the `Showing X of N` footer, the machine-readable error `code` dispatch, and > the API-key / Bearer parity + free-plan gating rules — is available at this -> floor. If `dailybot --version` is below 3.1.2, ask the developer to run +> floor. If `dailybot --version` is below 3.7.0, ask the developer to run > `dailybot upgrade`. This is the **single source of truth** for behavior shared across every @@ -27,7 +27,7 @@ that flag already means "every author's responses", not "every page"). | `--page-size N` | | Items per page. **Max 100** — larger values are clamped client-side. Passing it alone returns that one page, not the whole list. | | `--all` | | Fetch **every** page and concatenate the results. Mutually exclusive with `--limit`. | | `--limit N` | | Stop after the first `N` items (across pages). Mutually exclusive with `--all`. | -| `--search TEXT` | `--grep TEXT` | Case-insensitive substring filter. **Max 256 chars** — longer queries are rejected client-side with an error before the request is made (`CLI >= 3.3.0`; earlier versions truncated silently). | +| `--search TEXT` | `--grep TEXT` | Case-insensitive substring filter. **Max 256 chars** — longer queries are rejected client-side with an error before the request is made. | | `--since YYYY-MM-DD` | | Start of a date range (inclusive). | | `--until YYYY-MM-DD` | | End of a date range (inclusive). | | `--date YYYY-MM-DD` | | A single day (shorthand for `--since D --until D`). | @@ -151,7 +151,7 @@ In `--json` mode the error surfaces as `{ error, status, code, detail }`. | `code` | Meaning | What to do | |--------|---------|------------| | `target_user_inactive` | The targeted user is deactivated. | Pick an active user. | -| `search_query_too_long` | `--search` exceeded the 256-char limit. | Since CLI `>= 3.3.0` the query is rejected client-side before the request. If you hit this server-side, shorten the query. | +| `search_query_too_long` | `--search` exceeded the 256-char limit. | The query is rejected client-side before the request. If you hit this server-side, shorten the query. | | `invalid_date_range` | `--since`/`--until` are malformed or reversed. | Fix the dates (`YYYY-MM-DD`, since ≤ until). | | `invalid_user_identifier` | `--user` was given an email or a name. | `--user` takes **only a UUID**. Get it from `dailybot user list --json`. (Caught client-side before the request.) | | `invalid_workflow_state` | On `form responses --state`: the form has no workflow. On `form create` / `form config --state`: the `"Label:#color"` spec is malformed. | Two meanings, one code — read which command you ran. For the filter, drop `--state` (or pick a workflow form). | @@ -160,8 +160,8 @@ In `--json` mode the error surfaces as `{ error, status, code, detail }`. | `send_as_user_not_found` | The `--send-as-user` UUID doesn't resolve to a user. | Confirm the user exists (`dailybot user list`). | | `invalid_kudos_filter` | `kudos list --filter` got an unrecognized value. | Use `received` or `given` (the CLI also accepts `KUDOS_RECEIVED` / `KUDOS_GIVEN`). | | `send_message_validation_error` | `chat send` payload is missing content or otherwise invalid. | Read the `detail` — it names the problem (e.g. no message/buttons/image). | -| `invalid_owner_user_id` | `--owner` value isn't a valid UUID (after resolution). | Fix the UUID or name. (`CLI >= 3.6.0`) | -| `too_many_owner_user_ids` | More than 50 `--owner` values. | Narrow the filter — max 50 owners per request. (`CLI >= 3.6.0`) | +| `invalid_owner_user_id` | `--owner` value isn't a valid UUID (after resolution). | Fix the UUID or name. | +| `too_many_owner_user_ids` | More than 50 `--owner` values. | Narrow the filter — max 50 owners per request. | ### 429 — rate limit diff --git a/.agents/skills/dailybot/shared/repo-profile.md b/.agents/skills/dailybot/shared/repo-profile.md index 4c4abc1..9dc0ff4 100644 --- a/.agents/skills/dailybot/shared/repo-profile.md +++ b/.agents/skills/dailybot/shared/repo-profile.md @@ -10,7 +10,7 @@ This pre-flight closes that gap. Run it once per turn (or once per work session ## The rule (one line) -> Before constructing any `dailybot ` command line, walk up from `$PWD` looking for a `.dailybot/` directory. If `.dailybot/profile.json` exists in the closest ancestor, **omit from your command every flag the profile already provides**. +> Before constructing any `dailybot ` command line, walk up from `$PWD` looking for a `.dailybot/` directory. If `.dailybot/profile.json` exists in the closest ancestor, **omit from your command every flag the profile already provides**. (If `.dailybot/env.json` also exists, the CLI reads it automatically for credentials + URL overrides — see [`shared/env-json.md`](env-json.md); do not attempt to override its keys from the command line.) What "already provides" means concretely: @@ -147,12 +147,24 @@ This applies to: `dailybot-report`, `dailybot-chat`, `dailybot-kudos`, `dailybot ## What about `.dailybot/` files other than `profile.json`? -The schema may grow. Today the only file the CLI reads from `.dailybot/` is `profile.json`. If you find other files in `.dailybot/`, do not act on them — just leave them alone. A future skill-pack release will add specific guidance for any new file. +Since CLI **3.7.0**, `.dailybot/` also supports an **opt-in, gitignored** file called `env.json` that carries per-repo API keys + URLs for one or more environments. It is orthogonal to `profile.json` — different purpose, different lifecycle, different security posture: + +| File | Committed? | Purpose | +|---|---|---| +| `.dailybot/profile.json` | **Yes** (tracked) | *Identity* — how reports get signed (team-shared) | +| `.dailybot/env.json` | **No** (gitignored) | *Auth context* — which org the CLI talks to (per-developer) | + +If the developer asks about per-repo API keys, staging/local dev orgs, or "logging into different orgs in different repos", route them to [`shared/env-json.md`](env-json.md) instead — that file has the full workflow, security rules, and CLI commands. + +Do **not** attempt to read `env.json` directly (`cat` etc.) from an agent context — it contains API keys. Use `dailybot env show` / `dailybot env list`, which mask them automatically. + +Any other file you find in `.dailybot/` is out of scope for this skill pack — leave it alone. --- ## See also - [`shared/auth.md`](./auth.md) — full authentication / profile resolution model (Bearer token, API key, profile slug, env var). +- [`shared/env-json.md`](./env-json.md) — the sibling `env.json` file (per-repo API keys + URLs, gitignored, CLI 3.7.0+). - [CLI auth-resolution order](https://github.com/DailybotHQ/cli/blob/main/AGENTS.md#14-auth-resolution-order-do-not-break) — the per-field precedence the CLI implements (this doc is the agent-side mirror). - [CLI configuration reference](https://github.com/DailybotHQ/cli/blob/main/docs/CONFIGURATION.md) — the full `.dailybot/profile.json` schema, security rules, and migration notes. diff --git a/.agents/skills/dailybot/teams/SKILL.md b/.agents/skills/dailybot/teams/SKILL.md index e397f72..0294264 100644 --- a/.agents/skills/dailybot/teams/SKILL.md +++ b/.agents/skills/dailybot/teams/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot-teams description: Read and resolve teams visible to the authenticated user. Use when the developer references a team by name (for kudos targeting, member lookup, or routing context) and an agent needs to obtain its UUID. Other Dailybot skills (kudos, messages) delegate team-name resolution to this skill rather than duplicating the logic. -version: "3.9.0" +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: true metadata: {"openclaw":{"emoji":"👥","homepage":"https://dailybot.com","requires":{"anyBins":["dailybot","curl"]},"primaryEnv":"DAILYBOT_API_KEY","install":[{"id":"cli-install-script","kind":"download","url":"https://cli.dailybot.com/install.sh","label":"Install Dailybot CLI (official script — preferred on Linux/macOS)"},{"id":"pip","kind":"pip","package":"dailybot-cli","bins":["dailybot"],"label":"Install Dailybot CLI via pip (fallback if binary fails)"}]}} @@ -10,7 +10,7 @@ allowed-tools: Bash, Read, Grep, Glob # Dailybot Teams -> **Requires `dailybot-cli >= 3.1.2`** (the skill-pack baseline). `dailybot team list`, `dailybot team get`, and the account-context commands `dailybot me` / `org` / `user get` are all available. If `dailybot --version` is below 3.1.2, ask the developer to run `dailybot upgrade`. See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version) for install commands and version-check tooling. +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline). `dailybot team list`, `dailybot team get`, and the account-context commands `dailybot me` / `org` / `user get` are all available. If `dailybot --version` is below 3.7.0, ask the developer to run `dailybot upgrade`. See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version) for install commands and version-check tooling. You help agents resolve and read teams visible to the logged-in user. Teams are how Dailybot groups people inside an organization — they're the targets for team-scoped kudos, the routing context for some messages, and the source of truth for "who's in X?". @@ -170,7 +170,7 @@ Returns the team plus its membership when `--with-members` is set. Useful when t ## Step 4.5 — Read a single user, and your own account context -> **Baseline:** `user get`, `me`, and `org` are part of the `dailybot-cli >= 3.1.2` baseline. +> **Baseline:** `user get`, `me`, and `org` are part of the `dailybot-cli >= 3.7.0` baseline. The org directory has always been readable in bulk via `dailybot user list` (names + UUIDs; emails hidden as PII). You can also read diff --git a/.agents/skills/dailybot/workflow/SKILL.md b/.agents/skills/dailybot/workflow/SKILL.md index 6bab1e3..b557ee1 100644 --- a/.agents/skills/dailybot/workflow/SKILL.md +++ b/.agents/skills/dailybot/workflow/SKILL.md @@ -1,7 +1,7 @@ --- name: dailybot-workflow description: List and inspect Dailybot workflows (read-only) — enumerate the workflows configured for the organization and read one workflow's configuration. Use when the developer asks "list my workflows", "show workflows", or "what's in the release workflow?". Writes are done in the Dailybot web app; this skill only reads. Plan-gated feature. -version: "3.9.0" +version: "3.10.2" documentation_url: https://www.dailybot.com/skill.md user-invocable: true metadata: {"openclaw":{"emoji":"🔀","homepage":"https://dailybot.com","requires":{"anyBins":["dailybot","curl"]},"primaryEnv":"DAILYBOT_API_KEY","install":[{"id":"cli-install-script","kind":"download","url":"https://cli.dailybot.com/install.sh","label":"Install Dailybot CLI (official script — preferred on Linux/macOS)"},{"id":"pip","kind":"pip","package":"dailybot-cli","bins":["dailybot"],"label":"Install Dailybot CLI via pip (fallback if binary fails)"}]}} @@ -10,9 +10,9 @@ allowed-tools: Bash, Read, Grep, Glob # Dailybot Workflows (read-only) -> **Requires `dailybot-cli >= 3.1.2`** (the skill-pack baseline). The `dailybot workflow list` / +> **Requires `dailybot-cli >= 3.7.0`** (the skill-pack baseline). The `dailybot workflow list` / > `dailybot workflow get` command group is available. If -> `dailybot --version` reports below 3.1.2, ask the developer to run +> `dailybot --version` reports below 3.7.0, ask the developer to run > `dailybot upgrade`. See [`../SKILL.md` § Required Dailybot CLI version](../SKILL.md#required-dailybot-cli-version) > for install commands and version-check tooling. diff --git a/.dailybot_example/env.json b/.dailybot_example/env.json new file mode 100644 index 0000000..b981469 --- /dev/null +++ b/.dailybot_example/env.json @@ -0,0 +1,25 @@ +{ + "active": "local-admin", + "profiles": [ + { + "name": "local-admin", + "api_key": "xxxx", + "api_url": "http://localhost:8000", + "app_url": "http://localhost:8090" + }, + { + "name": "local-member", + "api_key": "xxxx", + "api_url": "http://localhost:8000", + "app_url": "http://localhost:8090" + }, + { + "name": "live-admin", + "api_key": "xxxx" + }, + { + "name": "live-member", + "api_key": "xxxx" + } + ] +} diff --git a/AGENTS.md b/AGENTS.md index 6511b17..d694c80 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -487,7 +487,7 @@ dailybot agent update --name "Claude Code" --milestone \ --metadata '{"model":"claude-opus-4-7","plan":"PLAN_agent_profiles","repo":"cli"}' ``` -Full philosophy, what to report, and what to skip: [.agents/skills/dailybot/report/SKILL.md](.agents/skills/dailybot/report/SKILL.md) (part of the vendored Dailybot agent skill pack at `.agents/skills/dailybot/`, **v3.9.0**, which also ships the `chat` (incl. `--send-as-user`/`--send-as-me`), the `conversation` sub-skill (open/reuse a Slack group DM with the bot and post a report, `conversation open`, CLI ≥ 3.2.0), `kudos` (give + browse: `list`/`org`/`wall-of-fame`), `teams` (+ account context `me`/`org`/`user get`), `channels`, the read-only `workflow` (`list`/`get`), and the full `forms` (now org-scoped `list` + `--mine`) / `checkin` **authoring** sub-skills — plus the shared list pagination/search/date filters and machine-readable error-code reference. The whole pack requires `dailybot-cli >= 3.1.2`). Key rules: +Full philosophy, what to report, and what to skip: [.agents/skills/dailybot/report/SKILL.md](.agents/skills/dailybot/report/SKILL.md) (part of the vendored Dailybot agent skill pack at `.agents/skills/dailybot/`, **v3.10.2**, which also ships the `chat` (incl. `--send-as-user`/`--send-as-me`), the `conversation` sub-skill (open/reuse a Slack group DM with the bot and post a report, `conversation open`), `kudos` (give + browse: `list`/`org`/`wall-of-fame`), `teams` (+ account context `me`/`org`/`user get`), `channels`, the read-only `workflow` (`list`/`get`), the full `forms` (org-scoped `list` + `--mine`) / `checkin` **authoring** sub-skills, and the `env` sub-skill (per-repo API keys via the opt-in, gitignored `.dailybot/env.json`) — plus the shared list pagination/search/date filters and machine-readable error-code reference. The whole pack requires `dailybot-cli >= 3.7.0` (single baseline)). Key rules: - 1–3 sentences, **always in English** - Focus on WHAT + WHY, never "Agent completed…" @@ -518,7 +518,7 @@ When applying bot feedback on a PR, agents **must** skip `isMinimized == true` c Reusable **Skills** (slash commands) and **Agents** (specialized personas) live under [`.agents/`](.agents/) — the vendor-neutral standard adopted by most coding agents (Claude Code, Cursor, Codex, Gemini, Copilot, …): -- [`.agents/skills/`](.agents/skills/) — slash-command procedures (e.g., `/quick-fix`, `/release-prep`, `/cli-command-add`, plus the vendored Dailybot pack at `.agents/skills/dailybot/` with `/dailybot-report`, `/dailybot-chat`, `/dailybot-conversation`, `/dailybot-kudos`, `/dailybot-teams`, `/dailybot-forms`, `/dailybot-checkin`, `/dailybot-email`, `/dailybot-health`, `/dailybot-messages`, and the vendored Deep Work Plan pack at `.agents/skills/deepworkplan/` with `/deepworkplan-create`, `/deepworkplan-execute`, `/deepworkplan-refine`, `/deepworkplan-resume`, `/deepworkplan-status`, `/deepworkplan-verify`, `/deepworkplan-onboard`) +- [`.agents/skills/`](.agents/skills/) — slash-command procedures (e.g., `/quick-fix`, `/release-prep`, `/cli-command-add`, plus the vendored Dailybot pack at `.agents/skills/dailybot/` with `/dailybot-report`, `/dailybot-chat`, `/dailybot-conversation`, `/dailybot-kudos`, `/dailybot-teams`, `/dailybot-forms`, `/dailybot-checkin`, `/dailybot-email`, `/dailybot-health`, `/dailybot-messages`, `/dailybot-env`, and the vendored Deep Work Plan pack at `.agents/skills/deepworkplan/` with `/deepworkplan-create`, `/deepworkplan-execute`, `/deepworkplan-refine`, `/deepworkplan-resume`, `/deepworkplan-status`, `/deepworkplan-verify`, `/deepworkplan-onboard`) - [`.agents/agents/`](.agents/agents/) — agent personas (e.g., `cli-developer`, `release-manager`, `docs-writer`, `test-engineer`) - [`.agents/commands/`](.agents/commands/) — thin slash-command delegators that route to a sub-skill (the `dwp-*` short aliases, `/skill-create`, `/agent-create`, `/deepworkplan-onboard`) - [`.agents/docs/skills_agents_catalog.md`](.agents/docs/skills_agents_catalog.md) — full skill + persona index diff --git a/README.md b/README.md index 27119c7..6f304cf 100644 --- a/README.md +++ b/README.md @@ -17,8 +17,8 @@ exact release, or `>=` to set a **minimum floor** (installs the newest release a or above it): ```bash -pip install dailybot-cli==3.0.0 # exactly 3.0.0 -pip install "dailybot-cli>=3.0.0" # 3.0.0 or newer — picks the latest available +pip install dailybot-cli==3.7.0 # exactly 3.7.0 +pip install "dailybot-cli>=3.7.0" # 3.7.0 or newer — picks the latest available ``` ### Alternative installation methods @@ -27,8 +27,8 @@ Every method installs the **latest** release by default. Where a version can be pinned, the pinned form is shown right below the default one. Two pinning styles are supported everywhere `DAILYBOT_VERSION` / `--version` is accepted: -- **Exact** — `3.0.0` (or `==3.0.0`) installs precisely that release. -- **Minimum floor** — `>=3.0.0` installs the newest release at or above `3.0.0`, +- **Exact** — `3.7.0` (or `==3.7.0`) installs precisely that release. +- **Minimum floor** — `>=3.7.0` installs the newest release at or above `3.7.0`, so you get any later version automatically while guaranteeing a lower bound. **macOS (Homebrew)** @@ -41,7 +41,7 @@ Homebrew always installs the latest published formula. To pin a specific version, install with pip instead: ```bash -pip install dailybot-cli==3.0.0 +pip install dailybot-cli==3.7.0 ``` **Linux, WSL2, or Git Bash on Windows (binary or pip fallback)** @@ -56,13 +56,13 @@ accepts an exact version or a `>=` minimum floor: ```bash # exact version, environment variable -curl -fsSL https://cli.dailybot.com/install.sh | DAILYBOT_VERSION=3.0.0 bash +curl -fsSL https://cli.dailybot.com/install.sh | DAILYBOT_VERSION=3.7.0 bash # exact version, equivalent flag (note the `-s --` that forwards args through bash) -curl -fsSL https://cli.dailybot.com/install.sh | bash -s -- --version 3.0.0 +curl -fsSL https://cli.dailybot.com/install.sh | bash -s -- --version 3.7.0 -# minimum floor — installs 3.0.0 or the newest release above it -curl -fsSL https://cli.dailybot.com/install.sh | DAILYBOT_VERSION='>=3.0.0' bash +# minimum floor — installs 3.7.0 or the newest release above it +curl -fsSL https://cli.dailybot.com/install.sh | DAILYBOT_VERSION='>=3.7.0' bash ``` An exact pin installs the matching Linux binary when one exists, otherwise falls @@ -88,10 +88,10 @@ An exact version or a `>=` minimum floor both work: ```powershell # exact version -$env:DAILYBOT_VERSION = '3.0.0'; irm https://cli.dailybot.com/install.ps1 | iex +$env:DAILYBOT_VERSION = '3.7.0'; irm https://cli.dailybot.com/install.ps1 | iex -# minimum floor — installs 3.0.0 or the newest release above it -$env:DAILYBOT_VERSION = '>=3.0.0'; irm https://cli.dailybot.com/install.ps1 | iex +# minimum floor — installs 3.7.0 or the newest release above it +$env:DAILYBOT_VERSION = '>=3.7.0'; irm https://cli.dailybot.com/install.ps1 | iex ``` Requires Python 3.10+ on PATH. Wraps `pipx` / `uv tool` / `pip --user`. @@ -106,7 +106,7 @@ The CLI exposes two ways to inspect what's installed — a quick one-liner for s ```bash # Single-line, scriptable dailybot --version -# → dailybot 3.0.0 (Python 3.12.4) +# → dailybot 3.7.0 (Python 3.12.4) # Multi-line panel: version, Python runtime, install path, release notes link dailybot version diff --git a/docker/local/cli/Dockerfile b/docker/local/cli/Dockerfile index 1835293..b2bc666 100644 --- a/docker/local/cli/Dockerfile +++ b/docker/local/cli/Dockerfile @@ -46,7 +46,7 @@ RUN curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | d # dev-user). `-f` makes an HTTP error a non-zero curl exit instead of piping an error # page into bash; the `SHELL … pipefail` above makes a failing curl abort the build. # install.sh itself runs `set -euo pipefail`, so failures inside it abort too. -RUN curl -fsSL https://cli.dailybot.com/install.sh | DAILYBOT_VERSION='>=3.6.0' bash +RUN curl -fsSL https://cli.dailybot.com/install.sh | DAILYBOT_VERSION='>=3.7.0' bash # Install all Python dev/runtime deps from the repo's lock file. # This single COPY/RUN pair is the only build cache layer pip touches — it