Task Progress Tracking
Record development progress on a durable task: phase, progress, next step,
blockers, and validation evidence.
Requires the optional task command. Use npx ai-devkit@latest for task and
agent commands. Before recording task events, run a real read probe:
npx ai-devkit@latest task list --json
# or, when a task name is known:
npx ai-devkit@latest task list --name <task-name> --json
Only treat task tracing as available when the read probe exits 0. If it fails,
continue without task logging and include the failed command plus stderr/stdout
summary in the final report. Do not block the user's work just because optional
task tracing is unavailable or unusable.
Core idea
- One task per work item. Create it once; advance its
phase field as work
moves through the lifecycle or debug workflow.
<id> can be a task name. Every command below accepts the task name in
place of a task id, resolving to the latest non-terminal task. Prefer
<task-name> so agents do not track task ids.
- Choose stable names. For lifecycle work, use the feature key as the task
name. For debugging or review work, choose a short kebab-case task name.
- Emit at checkpoints, not streaming. Phase transitions, task toggles,
immediate next-step changes, fresh evidence, blockers discovered/resolved. A
handful of calls per session.
- Sequence mutations. Never run task mutation commands in parallel for the
same task. Each mutation reads the current task snapshot and writes it back;
parallel writes can clobber snapshot fields even though events append. Run
create/assign/phase/next/progress/evidence/blocker/artifact/close commands
one at a time, then read back with
show --events --json when the final state
matters.
- Attribution is explicit. Identify self once, then pass actor flags on
mutation commands.
Identify self
Use agent-management when attribution is needed:
- Run the
agent-management self-identification workflow with npx ai-devkit@latest agent list --json.
- Match the current agent entry from that list. Prefer an exact session match when available; otherwise use the unambiguous entry for the current project/worktree.
- Build actor flags from the matched entry:
--agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId>.
Map JSON fields directly: name -> --agent, type -> --agent-type,
pid -> --pid, and sessionId -> --session.
- If identity is ambiguous, do not guess. Continue task logging without actor
flags rather than fabricating attribution.
- Add
--agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> to every mutation command once known. If a task already
exists, run npx ai-devkit@latest task assign <task-name> --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json once so
the task snapshot has current ownership.
- If actor identity is unknown, run the same mutation commands without the four
actor flags.
Canonical commands
When self identity is known, add all four actor flags to every mutation command:
--agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId>.
# Create the task once (capture taskId from --json if needed)
npx ai-devkit@latest task create --title "<title>" --name <task-name> --phase requirements --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json
# If the task already exists, assign current ownership once when known
npx ai-devkit@latest task assign <task-name> --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json
# Mark real work as active after create/resume
npx ai-devkit@latest task status <task-name> active --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json
# Advance phase as the lifecycle moves on
npx ai-devkit@latest task phase <task-name> implementation --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json
# Progress (use --text; positional text is ignored)
npx ai-devkit@latest task progress <task-name> --text "Implementing task CLI" --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json
# Next step
npx ai-devkit@latest task next <task-name> "Run validation" --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json
# Blockers
npx ai-devkit@latest task status <task-name> blocked --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json
npx ai-devkit@latest task blocker <task-name> add "Waiting for review" --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json
npx ai-devkit@latest task blocker <task-name> resolve <blocker-id> --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json
npx ai-devkit@latest task status <task-name> active --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json
# Validation evidence - record after a fresh verify/tdd/test run
npx ai-devkit@latest task evidence <task-name> --passed --command "npm test" --exit-code 0 --summary "tests passed" --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json
# Reference an artifact (never copies the file)
npx ai-devkit@latest task artifact <task-name> docs/ai/testing/foo.md --kind test-report --description "Testing notes" --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json
# Read current status / list
npx ai-devkit@latest task show <task-name> --json
npx ai-devkit@latest task list --name <task-name> --json
# Close at lifecycle end
npx ai-devkit@latest task close <task-name> completed --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json
When to emit (by workflow)
- dev-lifecycle - real read probe first;
create at start when no
non-terminal task exists for the feature; assign once when actor is known; set
status active when real work starts or resumes; phase on every phase
transition; next after phase planning; progress after
planning/implementation task toggles; show at resume; close completed
only after final verification/review is done.
- verify / tdd / dev-testing -
evidence after fresh proof (this is what
makes "last validation" trustworthy). Use --failed when it fails.
- structured-debug - reuse the same commands:
evidence for repro results,
next for the next hypothesis, blocker add/resolve, progress.
- Any phase -
blocker add when blocked, resolve when clear; next to
state the immediate next step. Set status blocked when an open blocker stops
progress, and set status active again after the blocker is resolved.
Tips
- Add
--json when an agent must parse output (create/show/list). Omit for
human-readable checks.
- Don't restate obvious nearby files or transient state; keep summaries short.
- Good task records let a later reader answer: who worked on it, which phase it
reached, what changed, what is next, what verified the claim, and what blocked
or changed scope. Do not log every command; do log those checkpoints.
1---2name: task3description: AI DevKit · Track dev-lifecycle / structured-debug progress on a durable task with the ai-devkit task CLI. Use to record phase, progress, next step, blockers, and validation evidence.4---56# Task Progress Tracking78Record development progress on a durable task: phase, progress, next step,9blockers, and validation evidence.1011Requires the optional task command. Use `npx ai-devkit@latest` for task and12agent commands. Before recording task events, run a real read probe:1314```bash15npx ai-devkit@latest task list --json16# or, when a task name is known:17npx ai-devkit@latest task list --name <task-name> --json18```1920Only treat task tracing as available when the read probe exits 0. If it fails,21continue without task logging and include the failed command plus stderr/stdout22summary in the final report. Do not block the user's work just because optional23task tracing is unavailable or unusable.2425## Core idea2627- **One task per work item.** Create it once; advance its `phase` field as work28 moves through the lifecycle or debug workflow.29- **`<id>` can be a task name.** Every command below accepts the task name in30 place of a task id, resolving to the latest non-terminal task. Prefer31 `<task-name>` so agents do not track task ids.32- **Choose stable names.** For lifecycle work, use the feature key as the task33 name. For debugging or review work, choose a short kebab-case task name.34- **Emit at checkpoints, not streaming.** Phase transitions, task toggles,35 immediate next-step changes, fresh evidence, blockers discovered/resolved. A36 handful of calls per session.37- **Sequence mutations.** Never run task mutation commands in parallel for the38 same task. Each mutation reads the current task snapshot and writes it back;39 parallel writes can clobber snapshot fields even though events append. Run40 create/assign/phase/next/progress/evidence/blocker/artifact/close commands41 one at a time, then read back with `show --events --json` when the final state42 matters.43- **Attribution is explicit.** Identify self once, then pass actor flags on44 mutation commands.4546## Identify self4748Use `agent-management` when attribution is needed:49501. Run the `agent-management` self-identification workflow with `npx ai-devkit@latest agent list --json`.512. Match the current agent entry from that list. Prefer an exact session match when available; otherwise use the unambiguous entry for the current project/worktree.523. Build actor flags from the matched entry:53 `--agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId>`.54 Map JSON fields directly: `name` -> `--agent`, `type` -> `--agent-type`,55 `pid` -> `--pid`, and `sessionId` -> `--session`.564. If identity is ambiguous, do not guess. Continue task logging without actor57 flags rather than fabricating attribution.585. Add `--agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId>` to every mutation command once known. If a task already59 exists, run `npx ai-devkit@latest task assign <task-name> --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json` once so60 the task snapshot has current ownership.616. If actor identity is unknown, run the same mutation commands without the four62 actor flags.6364## Canonical commands6566When self identity is known, add all four actor flags to every mutation command:67`--agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId>`.6869```bash70# Create the task once (capture taskId from --json if needed)71npx ai-devkit@latest task create --title "<title>" --name <task-name> --phase requirements --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json7273# If the task already exists, assign current ownership once when known74npx ai-devkit@latest task assign <task-name> --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json7576# Mark real work as active after create/resume77npx ai-devkit@latest task status <task-name> active --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json7879# Advance phase as the lifecycle moves on80npx ai-devkit@latest task phase <task-name> implementation --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json8182# Progress (use --text; positional text is ignored)83npx ai-devkit@latest task progress <task-name> --text "Implementing task CLI" --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json8485# Next step86npx ai-devkit@latest task next <task-name> "Run validation" --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json8788# Blockers89npx ai-devkit@latest task status <task-name> blocked --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json90npx ai-devkit@latest task blocker <task-name> add "Waiting for review" --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json91npx ai-devkit@latest task blocker <task-name> resolve <blocker-id> --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json92npx ai-devkit@latest task status <task-name> active --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json9394# Validation evidence - record after a fresh verify/tdd/test run95npx ai-devkit@latest task evidence <task-name> --passed --command "npm test" --exit-code 0 --summary "tests passed" --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json9697# Reference an artifact (never copies the file)98npx ai-devkit@latest task artifact <task-name> docs/ai/testing/foo.md --kind test-report --description "Testing notes" --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json99100# Read current status / list101npx ai-devkit@latest task show <task-name> --json102npx ai-devkit@latest task list --name <task-name> --json103104# Close at lifecycle end105npx ai-devkit@latest task close <task-name> completed --agent <agent-name> --agent-type <agent-type> --pid <pid> --session <sessionId> --json106```107108## When to emit (by workflow)109110- **dev-lifecycle** - real read probe first; `create` at start when no111 non-terminal task exists for the feature; `assign` once when actor is known; set112 `status active` when real work starts or resumes; `phase` on every phase113 transition; `next` after phase planning; `progress` after114 planning/implementation task toggles; `show` at resume; `close completed`115 only after final verification/review is done.116- **verify / tdd / dev-testing** - `evidence` after fresh proof (this is what117 makes "last validation" trustworthy). Use `--failed` when it fails.118- **structured-debug** - reuse the same commands: `evidence` for repro results,119 `next` for the next hypothesis, `blocker add`/`resolve`, `progress`.120- **Any phase** - `blocker add` when blocked, `resolve` when clear; `next` to121 state the immediate next step. Set `status blocked` when an open blocker stops122 progress, and set `status active` again after the blocker is resolved.123124## Tips125126- Add `--json` when an agent must parse output (create/show/list). Omit for127 human-readable checks.128- Don't restate obvious nearby files or transient state; keep summaries short.129- Good task records let a later reader answer: who worked on it, which phase it130 reached, what changed, what is next, what verified the claim, and what blocked131 or changed scope. Do not log every command; do log those checkpoints.