feat(tasks): Tasks Beta parity — owner, board admin, attachments, bulk dry run, recipes

[xergioalex]

Summary

The dailybot-tasks sub-skill reaches parity with Dailybot Tasks on the web, matching dailybot-cli 3.14.0 (DailybotHQ/cli#94).

Beta — Tasks is in beta. Everything under /tasks in the web app, the CLI and agent skill commands for projects, goals, boards and tasks, and the /v1/tasks/ public API may change before general availability. Want to try it with your team? Write to support@dailybot.com.

CLI floor

dailybot-cli 3.14.0 is on PyPI (DailybotHQ/cli#94). This sub-skill requires >= 3.14.0. The capability check in Step 1 (dailybot task set-owner --help) tells an agent to run dailybot upgrade rather than work around a missing command.

What changed

• Beta notice (canonical copy) at the top of tasks/SKILL.md, and in the Tasks section of docs/API_REFERENCE.md.
• Vocabulary: a task has an owner (task set-owner, --owner me|unowned) and a state. Tasks are archived and restored, not deleted. Every task argument accepts ENG-142 or a uuid. task move --state accepts a column name, a category, or a uuid.
• Credentials: the table is rebuilt from the published contract. It lists the commands that need a signed-in person (inbox, cursor, mentionables, participants/watch/mute, members, saved views, pins). It also covers tasks:admin, needed for any change to boards, columns, projects or goals, which an API key can never hold.
• New capabilities: @mentions resolved through board mentionables, attachments, children, duplicate, per-task activity, the activity read-mark, and a new Step 8 for administering boards, projects and goals.
• Destructive previews: bulk now has a real server-side dry run. Commands with no server preview take a client-side --dry-run that sends nothing. shared/destructive-previews.md is updated to match.
• Refusals: new codes are explained, and state_in_use now points at --migrate-to.
• Five recipes for real work: TODO list → tasks (bulk create with dry run), move a task when a PR merges, triage the inbox, plan a sprint (snapshot → bulk update with dry run), and report progress against a goal.
• Complete command reference: a new tasks/commands.md covers all 115 Tasks commands in the CLI (tasks 19, task 37, board 24, project 23, goal 12). Each entry has its arguments, every flag (type, accepted values, required/repeatable, short alias), the API door it calls, whether it needs a signed-in person, and a placeholder example. It is generated from the CLI's Click definitions, so it matches --help. tasks/SKILL.md teaches the safe workflow and links to it for exact flags.
• The router SKILL.md, the README catalog, AGENTS.md and docs/API_REFERENCE.md are updated to the same facts.

Public surface

This is a MINOR change (feat). The previously documented task assign --to and --assignee keep working in the CLI as hidden aliases that now reach the server correctly, so nothing documented stops working. The skill simply teaches task set-owner / --owner now.

Validation

• A script extracted all 72 dailybot tasks|task|board|project|goal … invocations across the four changed files and ran --help for each against the #94 branch. Every command and every --flag exists. The checker was also run against deliberately broken input to confirm it fails.
• Completeness: commands.md has one entry for each of the 115 visible Tasks commands on the #94 branch. None is missing, and hidden deprecated aliases are excluded. The same checker validated every invocation in commands.md and tasks/SKILL.md: ALL OK.
• Frontmatter was checked by hand: required keys, kebab-case name, no homepage key, quoted version, a plain-scalar description. scripts/validate-frontmatter.py could not run locally because PyYAML isn't installed, and I didn't install packages without consent. CI runs it.
• Privacy: no real identifiers. The examples use placeholders, ENG-142 and support@dailybot.com.
• No shell scripts changed, so shellcheck and bats are unaffected.

🤖 Generated with Claude Code

[github-actions]

AI review for 48a5b5f — ✅ done

View review →

Highest severity: warning

Strictness gate: ✅ highest severity warning ≤ critical threshold

8 inline comment(s) attached.

Usage: not reported by this provider · 263s

Iteration-Aware Review: gen 8, round 1, policy=first-pass-exhaustive (rebased) — 8 surfaced.

[github-actions]

Verdict

Solid Tasks Beta parity docs with careful credential tables, untrusted-content Step 0 preserved, and recipes that mostly wait after dry-runs — but bulk --yes is still described like archive auto-preview, which can teach agents to apply up to 100-item batches without a real consequence check.

Findings

#	Severity	File	Summary
1	⚠️ warning	skills/dailybot/tasks/SKILL.md:378	Blanket "--yes skips the prompt, not the preview" is false for bulk (and client-only dry-runs)
2	⚠️ warning	docs/API_REFERENCE.md:963	Same --yes claim sits beside the new bulk dry-run sentence
3	⚠️ warning	skills/dailybot/shared/destructive-previews.md:63	Dry-run and --yes shown back-to-back with no wait (recipes already fixed this)
4	⚠️ warning	skills/dailybot/tasks/commands.md:377	Bulk --yes omits that it does not still preview
5	⚠️ warning	skills/dailybot/tasks/SKILL.md:578	Sprint "second batch" move omits dry-run + developer wait
6	ℹ️ info	skills/dailybot/tasks/SKILL.md:556	inbox-read-all in the same fence as triage, no explicit go-ahead
7	ℹ️ info	skills/dailybot/tasks/SKILL.md:374	Project cascade fact not mirrored in shared destructive-previews.md Facts
8	ℹ️ info	skills/dailybot/tasks/commands.md:5	115-command reference claims "generated" but no regen script ships in-repo

Notes (no extra inline)

• ships? vs contributor-only: findings 1, 3–8 touch skills/dailybot/ (install surface). Finding 2 is contributor-only (docs/) but mirrors the same agent-facing contract.
• Privacy / consent floors look sound: placeholders only, support@dailybot.com allowed, Step 0 intact, CLI floor >= 3.14.0 consistent across README / AGENTS / router / tasks skill / API ref, router routes Tasks, frontmatter validates.
• Prior AI rounds already fixed inbox-in-status, view-save review, recipe 1/4 waits, caption size, and --migrate-to. Remaining risk is mostly bulk preview semantics.
• Open question (not filed): whether --owner me / set-owner … me works with a bare DAILYBOT_API_KEY; examples use me on key-capable doors without a login caveat. Worth confirming against CLI 3.14.0.

Recommendation: request-changes

---

Check status: ✅ passing — strictness block-on-critical, highest severity in effect warning: highest severity warning ≤ critical threshold.

This line is written by the reviewer runtime after the gate ran and matches the check conclusion and the tracking comment. Any recommendation above is the model's advisory opinion, not the gate.

[github-actions]

ships? Blanket claim is wrong for bulk (and for client-only --dry-run doors).

Archive doors auto-preview before --yes, so “skips the prompt, not the preview” is true there. task bulk --yes does not run a server dry-run — it skips confirmation and can apply up to 100 rows. An agent that learned this bullet then runs task bulk --operation archive -f batch.json --yes never sees items[].changes / refused[].

Fix: scope the bullet to auto-preview doors, e.g. “On archive/restore doors, --yes skips the prompt, not the preview. On task bulk and client-preview deletes, run --dry-run first, show the result, wait, then apply (with --yes only after that).”

[github-actions]

contributor-only (mirrors the shipped skill). Same over-broad --yes sentence now sits next to “Bulk has a real dry run”.

Readers can take “--yes skips the prompt, not the preview” as applying to bulk. For bulk, preview is opt-in via --dry-run; --yes alone does not preview.

Split the sentences: keep the archive auto-preview rule, then state explicitly that bulk requires a separate --dry-run (and a human go-ahead) before --yes.

[github-actions]

ships? Dry-run and apply are shown in one fence with no wait — the opposite of Recipes 1 and 4 in tasks/SKILL.md (fixed in AI review round 3).

Agents copy fences. Chaining --dry-run then --yes in the same block teaches unattended apply of up to 100 bulk rows.

Suggested change

	dailybot task bulk --operation archive -f batch.json --yes --json
	dailybot task bulk --operation archive -f batch.json --dry-run --json
	# show items[].changes / refused[] to the developer and wait; only then:
	dailybot task bulk --operation archive -f batch.json --yes --json

[github-actions]

ships? Archive entries say --yes — “Skip the prompt (still previews).” Bulk only says “Skip the confirmation,” with no warning that nothing was previewed unless --dry-run was used.

Agents looking up flags here will treat bulk like archive and ship --yes alone.

Fix: e.g. “Skip the confirmation. Does not run a dry-run — pass --dry-run first, show the preview, wait, then re-run with --yes.”

[github-actions]

ships? Recipe 4 correctly dry-runs the update batch and waits, then tells the agent to run a second --operation move batch with no dry-run or go-ahead.

Moving a sprint’s worth of cards is the same blast radius class as the update batch. If the wrong column uuid is copied from the snapshot, cards jump without a preview.

Fix: require task bulk --operation move -f move.json --dry-run, present from → to, wait, then --yes — same shape as the update steps above.

[github-actions]

ships? inbox-read-all sits in the same copy-paste fence as the triage reads. The prose says to decide from the developer, but the fence does not stop between list and mark-all-read.

Also, inbox-read <item> advances a single “read up to here” cursor (everything older is marked too) — easy to over-clear.

Prefer splitting: list/filter in one fence; after an explicit go-ahead, show inbox-read / inbox-read-all in a second fence.

[github-actions]

ships? Good that Step 6 now states project archive cascades to boards/tasks and restore walks up, not down.

shared/destructive-previews.md “Facts that surprise people” (still board-only) was updated in this PR for bulk/views but not for this cascade. Agents that follow the shared “Full treatment” link understate project archive blast radius.

Mirror this bullet into destructive-previews.md Facts (and ideally the API reference destructive paragraph).

[github-actions]

ships? This 115-command file says it is “generated from the CLI,” but the repo has no checked-in generator or CI check that regenerates/diffs it against dailybot-cli.

Drift risk on the next CLI Tasks release: agents will trust flags here that no longer match --help.

Worth a one-line note on how it was produced (or a scripts/ helper + CI drift check) so the next bump is mechanical.