Full API-key parity + headless dailybot ask

.agents/skills/dailybot/checkin/SKILL.md

@@ -16,14 +16,15 @@ You help developers complete their pending check-ins (daily standups, weekly sur
 
 ## Auth model — user-scoped commands
 
-Check-in commands require a **Bearer token** (user session), not an API key.
-The developer must be logged in via `dailybot login`. This is the same
-session used by the webapp — it scopes actions to the logged-in human's
-permissions and pending check-ins.
+Check-in commands accept **either** a Bearer login session (`dailybot login`)
+**or** an org API key (`DAILYBOT_API_KEY`). The server honours `X-API-KEY` on
+`/v1/cli/status/` (pending check-ins) and `/v1/checkins/<uuid>/responses/`
+(completion), resolving the acting user from the key's owner — identical scope
+to the Bearer path (the logged-in human's permissions and pending check-ins).
 
-If the developer only has an API key (`DAILYBOT_API_KEY`), guide them through
-`dailybot login` first. API keys authenticate agent-scoped endpoints
-(`dailybot agent ...`), not user-scoped ones.
+If the developer has only an API key, check-in commands still work — the CLI
+falls back to `X-API-KEY`. Prefer `dailybot login` when the developer wants
+their own personal, human-scoped pending check-ins.
 
 ---
 
@@ -43,15 +44,16 @@ specific questions; reports are freeform updates.
 
 Read and follow the authentication steps in [`../shared/auth.md`](../shared/auth.md). That file covers CLI installation, login, API key setup, and agent profile configuration.
 
-**Additionally**, verify the developer has a user session (Bearer token):
+**Additionally**, confirm at least one credential is present (a Bearer login
+session or an API key):
 
 ```bash
 dailybot status --auth 2>&1
 ```
 
-If the output shows a logged-in user session, proceed. If not, guide them
-through `dailybot login` (see auth.md for the OTP flow). Check-in commands
-will not work with only an API key.
+If the output shows a logged-in user session **or** a configured API key,
+proceed. Otherwise guide them through `dailybot login` (see auth.md for the
+OTP flow) or ask them to set `DAILYBOT_API_KEY`.
 
 If auth fails or the developer declines, skip and continue with your primary task.
 
@@ -170,7 +172,7 @@ dailybot checkin complete <followup_uuid> \
 
 See [`../shared/http-fallback.md`](../shared/http-fallback.md) for base patterns.
 
-**Important:** Check-in endpoints use **Bearer token** auth, not API key auth.
+**Important:** Check-in endpoints accept **either** Bearer token or `X-API-KEY` auth.
 
 ### List pending check-ins
 

.agents/skills/dailybot/forms/SKILL.md

@@ -35,9 +35,9 @@ Customer-authored form skills live at `.agents/skills/dailybot-custom/<name>/SKI
 
 ## Auth model — user-scoped commands
 
-All form commands require a **Bearer token** (user session), not an API key. The developer must be logged in via `dailybot login`. This scopes form access to the logged-in human's permissions — they only see forms (and responses) they have access to, and the server enforces every audience check on the API side.
+All form commands accept **either** a Bearer login session (`dailybot login`) **or** an org API key (`DAILYBOT_API_KEY`). Access is scoped to the acting identity's permissions — they only see forms (and responses) they have access to, and the server enforces every audience check on the API side.
 
-If the developer only has an API key (`DAILYBOT_API_KEY`), guide them through `dailybot login` first. API keys authenticate agent-scoped endpoints (`dailybot agent ...`), not user-scoped ones.
+If the developer has only an API key, form commands still work — the CLI falls back to `X-API-KEY`. Prefer `dailybot login` when the developer wants a personal, human-scoped view.
 
 ---
 
@@ -58,13 +58,13 @@ Do **not** use this skill for daily standup check-ins — route those to `dailyb
 
 Read and follow the authentication steps in [`../shared/auth.md`](../shared/auth.md). That file covers CLI installation, login, API key setup, and agent profile configuration.
 
-**Additionally**, verify the developer has a user session (Bearer token):
+**Additionally**, confirm at least one credential is present (a Bearer login session or an API key):
 
 ```bash
 dailybot status --auth 2>&1
 ```
 
-If the output shows a logged-in user session, proceed. If not, guide them through `dailybot login` (see auth.md for the OTP flow). Form commands will not work with only an API key.
+If the output shows a logged-in user session **or** a configured API key, proceed. Otherwise guide them through `dailybot login` (see auth.md for the OTP flow) or ask them to set `DAILYBOT_API_KEY`.
 
 A scripted preflight that does both at once and exits with code `3` if unauthenticated:
 
@@ -284,13 +284,13 @@ In `.dailybot/profile.json` at the repo root, under the CLI's free-form `vars` n
 
 ```json
 {
-  "name": "API Services",
-  "default_metadata": { "repo": "api-services" },
+  "name": "My Team",
+  "default_metadata": { "repo": "my-service" },
   "vars": {
-    "active_organization_uuid": "00e2b30f-b581-44ae-8981-4cdbd060b78d",
+    "active_organization_uuid": "<your-org-uuid>",
     "custom_form_skills": {
       "by_uuid": {
-        "65de0ec6-2353-4e17-94d7-7beaa905e92a": ".agents/skills/dailybot-custom/coderelease-form"
+        "<form-uuid>": ".agents/skills/dailybot-custom/coderelease-form"
       },
       "by_slug": {
         "code-release-form": ".agents/skills/dailybot-custom/coderelease-form"
@@ -588,7 +588,7 @@ If the server returns a body without a `code` (network error, gateway error, mal
 
 See [`../shared/http-fallback.md`](../shared/http-fallback.md) for base patterns.
 
-**Important:** Form endpoints use **Bearer token** auth, not API key auth.
+**Important:** Form endpoints accept **either** Bearer token or `X-API-KEY` auth.
 
 ### List forms (with questions)
 

.agents/skills/dailybot/forms/_custom-template/SKILL.md

@@ -114,7 +114,7 @@ What does the agent do when:
 
 ## 7 — Reference implementation
 
-For a complete reference of this template applied to a real workflow form, see the Dailybot-internal code-release skill at `api-services/.agents/skills/dailybot-custom/coderelease-form/SKILL.md` (ships in the `api-services` repo, separate from this skill pack). It demonstrates per-state validation, autofill from repo metadata, and channel-routing reminders end-to-end.
+A complete reference implementation of this template lives as a custom skill at `.agents/skills/dailybot-custom/<form-slug>/SKILL.md` in the consuming repo (a customer- or team-owned namespace, separate from this skill pack). Such a skill demonstrates per-state validation, autofill from repo metadata, and channel-routing reminders end-to-end.
 
 ---
 

.agents/skills/dailybot/kudos/SKILL.md

@@ -23,9 +23,9 @@ Two recipient types are supported:
 
 ## Auth model — user-scoped commands
 
-Kudos commands require a **Bearer token** (user session), not an API key. The developer must be logged in via `dailybot login`. This scopes kudos to the logged-in human — the kudos appear as coming from them, not from an agent.
+Kudos commands accept **either** a Bearer login session (`dailybot login`) **or** an org API key (`DAILYBOT_API_KEY`). Kudos are scoped to the acting identity — the server resolves the API key's owner, so they appear as coming from that user.
 
-If the developer only has an API key (`DAILYBOT_API_KEY`), guide them through `dailybot login` first. API keys authenticate agent-scoped endpoints (`dailybot agent ...`), not user-scoped ones.
+If the developer has only an API key, kudos still work — the CLI falls back to `X-API-KEY`. Prefer `dailybot login` when the developer wants the kudos attributed to their own human account.
 
 ---
 
@@ -53,13 +53,13 @@ Do **not** send kudos autonomously without the developer's explicit request. Kud
 
 Read and follow the authentication steps in [`../shared/auth.md`](../shared/auth.md). That file covers CLI installation, login, API key setup, and agent profile configuration.
 
-**Additionally**, verify the developer has a user session (Bearer token):
+**Additionally**, confirm at least one credential is present (a Bearer login session or an API key):
 
 ```bash
 dailybot status --auth 2>&1
 ```
 
-If the output shows a logged-in user session, proceed. If not, guide them through `dailybot login` (see auth.md for the OTP flow).
+If the output shows a logged-in user session **or** a configured API key, proceed. Otherwise guide them through `dailybot login` (see auth.md for the OTP flow) or ask them to set `DAILYBOT_API_KEY`.
 
 If auth fails or the developer declines, skip and continue with your primary task.
 
@@ -292,7 +292,7 @@ Agent:
 
 See [`../shared/http-fallback.md`](../shared/http-fallback.md) for base patterns.
 
-**Important:** Kudos endpoints use **Bearer token** auth, not API key auth.
+**Important:** Kudos endpoints accept **either** Bearer token or `X-API-KEY` auth.
 
 ### List teams (to resolve team names)
 

.agents/skills/dailybot/shared/auth.md

@@ -303,33 +303,38 @@ Dailybot → Settings → API Keys.
 
 ---
 
-## 4. User-Scoped Commands (Bearer Token Auth)
+## 4. User-Scoped Commands (API Key *or* Bearer Token)
 
-Some Dailybot features — **check-ins**, **forms**, **kudos**, and **user
-directory** — are scoped to the logged-in human's session, not to an agent
-identity. These commands use a **Bearer token** stored at
-`~/.config/dailybot/credentials.json` after `dailybot login`.
+Almost all Dailybot CLI commands — **check-ins**, **forms**, **kudos**,
+**teams**, the **user directory**, **status**, and **update** — accept
+**either** credential: a Bearer login token (stored at
+`~/.config/dailybot/credentials.json` after `dailybot login`) **or** an org
+API key (`DAILYBOT_API_KEY` env var or `dailybot config key=...`). The CLI
+prefers the login session when present and falls back to the API key, so these
+commands work in headless/CI environments with only an API key set. The server
+resolves the acting user from the API key's owner, so the scope is identical to
+the Bearer path.
 
-### Auth model distinction
+### Auth model
 
-| Scope | Auth method | How to set up | Used by |
-|-------|-------------|---------------|---------|
-| **Agent endpoints** | API key (`X-API-KEY` header) | `dailybot config key=...` or `DAILYBOT_API_KEY` env | `dailybot agent update`, `dailybot agent health`, `dailybot agent email send` |
-| **User endpoints** | Bearer token (`Authorization: Bearer <token>`) | `dailybot login` (OTP email flow) | `dailybot checkin`, `dailybot form`, `dailybot kudos`, `dailybot user` |
+| Scope | Accepted credentials | Used by |
+|-------|----------------------|---------|
+| **Agent endpoints** | API key (`X-API-KEY`) preferred, Bearer fallback | `dailybot agent update`, `dailybot agent health`, `dailybot agent email send` |
+| **User / CLI endpoints** | Bearer token preferred, API key fallback — **either works** | `dailybot status`, `dailybot update`, `dailybot checkin`, `dailybot form`, `dailybot kudos`, `dailybot team`, `dailybot user`, `dailybot chat`, `dailybot ask` / `dailybot interactive` (AI chat) |
+| **Login lifecycle** | OTP / Bearer only | `dailybot login`, `dailybot logout` (revokes the session token) |
 
-Both auth paths can coexist — the CLI stores them separately. A developer
-can have both an API key (for agent operations) and a Bearer session (for
-user-scoped operations) active at the same time.
+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.
 
-### Checking user session status
+### Checking session status
 
 ```bash
 dailybot status --auth 2>&1
 ```
 
 The output shows both the agent API key status and the Bearer session status.
-If the user session is missing or expired, guide through `dailybot login`
-using the OTP flow in Section 2 above.
+If neither is present, guide the developer through `dailybot login` (Section 2)
+or ask them to export `DAILYBOT_API_KEY`.
 
 ### Config directory override
 
@@ -345,10 +350,15 @@ This is useful for development sandboxes, CI environments, or testing
 scenarios with isolated config directories. The directory is created
 automatically if it does not exist.
 
-### User-scoped commands fail without a Bearer session
+### Commands need *some* credential
 
-If a developer tries to use `dailybot checkin`, `dailybot form`,
-`dailybot kudos`, or `dailybot user` with only an API key and no login
-session, the CLI exits with code `3` (not authenticated). Guide them
-through `dailybot login` — these commands require the human's own
-session, not an agent key.
+Every authenticated command — `status`, `update`, `checkin`, `form`, `kudos`,
+`team`, `user`, `chat`, and the AI chat (`ask` / `interactive`) — works with
+**either** a Bearer login session or an org API key. They exit with a non-zero
+"not authenticated" code only when **neither** is present — in that case guide
+the developer through `dailybot login` or ask them to set `DAILYBOT_API_KEY`.
+The only command that still requires a Bearer session is `dailybot logout`
+(it revokes the session token itself).
+
+This makes `dailybot ask "<question>"` the primary way an autonomous agent
+(with only `DAILYBOT_API_KEY`) can query the Dailybot AI headlessly.

.agents/skills/dailybot/teams/SKILL.md

@@ -20,9 +20,9 @@ This skill is primarily a **resolver dependency** for other Dailybot skills (mos
 
 ## Auth model — user-scoped commands
 
-Team-read commands require a **Bearer token** (user session), not an API key. The developer must be logged in via `dailybot login`. This scopes results to the logged-in human's permissions — they only see teams the server allows them to see.
+Team-read commands accept **either** a Bearer login session (`dailybot login`) **or** an org API key (`DAILYBOT_API_KEY`). Results are scoped to the acting identity's permissions — they only see teams the server allows them to see.
 
-If the developer only has an API key (`DAILYBOT_API_KEY`), guide them through `dailybot login` first. API keys authenticate agent-scoped endpoints (`dailybot agent ...`), not user-scoped ones.
+If the developer has only an API key, team commands still work — the CLI falls back to `X-API-KEY`. Prefer `dailybot login` when the developer wants a personal, human-scoped view.
 
 ---
 
@@ -58,13 +58,13 @@ Do **not** use this skill to enumerate org members when the goal is to recognize
 
 Read and follow the authentication steps in [`../shared/auth.md`](../shared/auth.md). That file covers CLI installation, login, API key setup, and agent profile configuration.
 
-**Additionally**, verify the developer has a user session (Bearer token):
+**Additionally**, confirm at least one credential is present (a Bearer login session or an API key):
 
 ```bash
 dailybot status --auth 2>&1
 ```
 
-If the output shows a logged-in user session, proceed. If not, guide them through `dailybot login` (see auth.md for the OTP flow). Team commands will not work with only an API key.
+If the output shows a logged-in user session **or** a configured API key, proceed. Otherwise guide them through `dailybot login` (see auth.md for the OTP flow) or ask them to set `DAILYBOT_API_KEY`.
 
 If auth fails or the developer declines, skip and continue with your primary task.
 
@@ -183,7 +183,7 @@ Concretely: a calling skill should invoke the same `dailybot team list --json` c
 
 See [`../shared/http-fallback.md`](../shared/http-fallback.md) for base patterns.
 
-**Important:** Team endpoints use **Bearer token** auth, not API key auth.
+**Important:** Team endpoints accept **either** Bearer token or `X-API-KEY` auth.
 
 ### List teams (role-scoped)
 

AGENTS.md

@@ -69,7 +69,7 @@ dailybot_cli/                # Source package
     ├── team.py              # `team` group: list / get (server-scoped by role)
     ├── kudos.py             # `kudos give` (to a user, a team, or both)
     ├── user.py              # `user list` (org directory)
-    ├── public_api_helpers.py  # require_bearer_auth, exit_for_api_error,
+    ├── public_api_helpers.py  # require_auth, exit_for_api_error,
     │                        #   ERROR_CODE_MESSAGES, resolve_user_/team_by_name_or_uuid
     ├── user_scoped_actions.py # shared handlers for checkin + form (used by CLI + TUI)
     ├── interactive.py       # questionary-based TUI when run with no args
@@ -218,6 +218,17 @@ os.chmod(PATH, 0o600)
 
 Never log full API keys or Bearer tokens. Use the `_mask` helper (or equivalent: first 4 chars + `****`).
 
+#### 11.a Open-source privacy hygiene — this repo is PUBLIC
+
+`DailybotHQ/cli` is a **public, open-source repository**. Anything you commit is world-readable forever (git history included). Never put **real internal or personal data** into tracked files — source, docs, tests, examples, or help text. This is a hard rule, and it applies even to "just an example":
+
+- **No real credentials/tokens** — no API keys, Bearer tokens, session tokens, webhook secrets, or `.env` values. Tests use obvious fakes (`"test-key"`, `"test-token"`); docs use `<your-api-key>` / `DAILYBOT_API_KEY`.
+- **No real identifiers or PII** — no real organization/user/form UUIDs, no real emails or names. Use placeholders: `<your-org-uuid>`, `<form-uuid>`, `me@example.com`, `Jane Doe`, `My Team`. (`security@dailybot.com` / `ops@dailybot.com` are the *intended* public contacts and are fine.)
+- **No internal infrastructure** — no internal hostnames (`djangovscode`, staging/dev URLs), no private repo names or internal architecture in **shipped/user-facing** content. Prefer generic example names (`my-service`, `my-api`) over real internal repo names. (The `docker/` local-dev tooling is a deliberate exception — it targets the internal dev container — but keep its internal references out of user-facing docs and the CLI's own output.)
+- **Scratch with real data stays in `tmp/`** — screenshots, API dumps, and probe output that contain real org UUIDs / emails / hosts go in `tmp/` (gitignored) and are **never** promoted into the repo. Do not `git add -A` blindly; prefer `git add -u` + explicit paths so stray artifacts (e.g. a debug `image.png` at the repo root) can't slip in.
+
+When in doubt, mask or genericize. To report a vulnerability, see [docs/SECURITY.md](docs/SECURITY.md) — never open a public issue for a security problem.
+
 ### 12. No Magic Numbers
 Extract limits, timeouts, and counts into module-level constants: