feat(chat,workflow): document interactive buttons and workflow trigger - #43
Conversation
Document chat approval/workflow button flags, full --buttons JSON contract, workflow trigger, and the matching error codes for agents. Co-authored-by: Cursor <cursoragent@cursor.com>
## Summary
CLI 3.8.0 is published on PyPI. Raise the skill-pack baseline to match and
correct the button contract docs against the shipped CLI help/API.
## Change Log
- Pack baseline: dailybot-cli >= 3.8.0 everywhere (was 3.7.0)
- chat: document real modal_body shape ({title, blocks}), callback_auth
object form, button_type/value, env-var preference for --callback-bearer
- chat: remove "next release after 3.7.4" hedges; add modal dialogue
- workflow: trigger/filter available at the new floor (no provisional note)
- shared errors: fix modal/auth guidance; add workflow_execute_not_allowed
and workflow_frozen
- README: chat/workflow rows pin >= 3.8.0
Co-authored-by: Cursor <cursoragent@cursor.com>
This comment has been minimized.
This comment has been minimized.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
## Summary Fix the four live review comments on #43 plus the off-diff floor stragglers. ## Change Log - Drop duplicate workflow_execute_not_allowed / workflow_frozen rows from the 400 table (keep 403 only) - channels + env-json: align adjacent 3.7.0 strings with the 3.8.0 floor - workflow trigger: require confirm of target + payload before firing - report/README/AGENTS: finish the 3.8.0 floor sweep called out in the review Co-authored-by: Cursor <cursoragent@cursor.com>
xergioalex
added
Ready
AI review for
|
There was a problem hiding this comment.
Verdict
Solid, well-structured docs-only PR — no blocking issues. The interactive-button surface, workflow trigger, and the 3.8.0 floor bump are documented consistently across the router, sub-skills, shared error table, and README. A few consistency nits and one real doc-mirror gap worth addressing before merge; nothing critical.
ships? All findings touch skills/dailybot/ (installed) except the doc-mirror gap, which is a public-surface completeness issue.
Findings
| # | Severity | File | Summary |
|---|---|---|---|
| 1 | README.md:241 |
New public HTTP surface (/v1/workflows/<uuid>/trigger/, buttons[] on send-message) not mirrored into docs/API_REFERENCE.md |
|
| 2 | ℹ️ info | skills/dailybot/chat/SKILL.md:273 |
Mixed button-flag separators (:: vs =) are an easy footgun for agents |
| 3 | ℹ️ info | skills/dailybot/chat/SKILL.md:550 |
Error-description wording drifts from the shared table ("isn't triggerable" vs "isn't API-triggerable") |
Cross-cutting notes (off-diff)
docs/API_REFERENCE.mdis stale relative to this change. It still documentsGET /v1/workflows/only (line 859) and asend-messagerow (line 853) with no buttons and a1.13.0/1.16.0version story — noPOST /v1/workflows/<uuid>/trigger/, nobuttons[], and none of the newbutton_*/workflow_*error codes. PerAGENTS.md(DON'T #13), the public API reference must track the same public surface as the runtimeSKILL.mdfiles, and this file is served standalone atwww.dailybot.com/skill.md. Finding #1 anchors this to the README line that documents the same endpoint.- Router capability count.
skills/dailybot/SKILL.mdstill opens with "Thirteen coordinated capabilities" but the table now lists 14 rows (report, ask, messages, email, chat, conversation, health, checkin, kudos, teams, forms, workflows, channels, env). This line is outside the diff, so I can't inline it, but it's worth correcting while you're in this file.
Praise
- The
workflow triggerconfirm-before-triggering block (Step 4) correctly treats triggering as side-effecting and preserves the pack's confirm-before-write consent posture — good instinct given a trigger can start a real deploy. - The approval-flow example passes the callback token via
--callback-bearer "$CI_TOKEN"with an explicit note about avoiding shell history / process lists, and the--buttonsJSON uses a<token>placeholder — no secret leakage. Consistent with the repo's privacy-hygiene rules.
Recommendation: approve
| | `POST /v1/send-message/` | `dailybot-chat` skill | **Either** `X-API-KEY` (org-wide) **or** Bearer token (login, role-scoped). Targets users/channels/teams, optional `thread_responses[]` for replies, optional `bot_message_id` to edit a previous message (parent or reply) | | ||
| | `POST /v1/send-message/` | `dailybot-chat` skill | **Either** `X-API-KEY` (org-wide) **or** Bearer token (login, role-scoped). Targets users/channels/teams, optional `thread_responses[]` for replies, optional `bot_message_id` to edit a previous message (parent or reply), optional `buttons[]` for interactive buttons | | ||
| | `GET /v1/workflows/` | `dailybot-workflow` skill (list/get) | `X-API-KEY` **or** Bearer | | ||
| | `POST /v1/workflows/<uuid>/trigger/` | `dailybot-workflow` skill (trigger) | `X-API-KEY` **or** Bearer; optional `{payload}` JSON object (≤8 KiB) | |
There was a problem hiding this comment.
ships? public surface. This adds POST /v1/workflows/<uuid>/trigger/ (and, one row up, buttons[] on /v1/send-message/) to the README's outbound-calls table, but docs/API_REFERENCE.md — the canonical public API reference served standalone at www.dailybot.com/skill.md — still documents only GET /v1/workflows/ and a buttons-less send-message. Per AGENTS.md (DON'T #13), the public API ref must track the same surface as the runtime SKILL.md files. An agent working from API_REFERENCE.md alone won't discover workflow trigger or interactive buttons. Mirror the new endpoint, the buttons[] field, and the new button_* / workflow_* error codes into docs/API_REFERENCE.md.
| --callback-url "https://ci.example.com/hooks/release" \ | ||
| --callback-bearer "$CI_TOKEN" | ||
| ``` | ||
|
|
There was a problem hiding this comment.
Heads-up nit: the button flags use two different separators — --link-button / --button take "Label::value" (double colon), while --approve-button / --reject-button / --workflow-button take "Label=value" (equals). This mirrors the real CLI, but an agent that reads one example and reuses the wrong separator will silently mis-parse the label/value. Consider a one-line callout (e.g. "note: approval/workflow buttons use =, not ::") so the distinction is hard to miss.
| | `400` | `button_callback_form_not_found` | `callback_form` UUID doesn't match a form | Verify the form UUID (`dailybot form list`). | | ||
| | `400` | `button_callback_command_invalid` | `callback_command` is not a recognized ChatOps command | Check the command string. | | ||
| | `400` | `button_callback_prompt_invalid` | `callback_prompt` is empty or too long | Fix the prompt text. | | ||
| | `400` | `button_callback_workflow_not_found` | `callback_workflow` UUID doesn't match a workflow, or the workflow isn't triggerable | Verify the UUID (`dailybot workflow list --filter api_trigger`). | |
There was a problem hiding this comment.
Wording drift: this row describes button_callback_workflow_not_found as "the workflow isn't triggerable", but the shared table in shared/list-query-and-errors.md:172 says "isn't API-triggerable". Same code, slightly different prose. Align on "API-triggerable" so agents matching on the shared source of truth read the identical meaning.
1 participant
Summary
dailybot-chat:--buttonsJSON (callbacks / modals / response /callback_authobject), approval-flow flags,--workflow-button, and the matchingbutton_*error codes — aligned with the published dailybot-cli 3.8.0 contract.dailybot-workflowto includeworkflow trigger,api_triggerrequirements,--filter api_trigger, payload →{{trigger.body.*}}, andworkflow_*errors (includingworkflow_execute_not_allowed/workflow_frozen).dailybot-cli >= 3.8.0everywhere (single floor).Companion CLI release: https://pypi.org/project/dailybot-cli/3.8.0/ (merged via DailybotHQ/cli#76)
Test plan
skills/dailybot/chat/SKILL.mdButtons § — modal_body is{title, blocks}, callback_auth is an objectskills/dailybot/workflow/SKILL.mdtrigger steps + error table>= 3.8.0in router + sub-skill headersshared/list-query-and-errors.mdlists the new codesversion:/ CHANGELOG release header (auto-release owns those)