kami/correx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(tasks): wire the task tools into role_pipeline

Browse Source 
Tool availability is a strict per-stage allowlist, so the task doctrine was
inert in role_pipeline — no stage granted the tools. Add them where they fit
each stage's tier and role, and point the stage prompts at the lifecycle:

- analyst (read-only): task_search/task_context to find related or duplicate
  work and ground the analysis.
- implementer: full set — claim before working, submit_for_review once
  verification passes, create one if the work warrants tracking.
- reviewer: task_context to judge against the task's own criteria, task_update
  to complete it on an approved verdict.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
kami
2026-06-24 10:04:01 +00:00
parent 06c225e3bd
commit afb536f21f
4 changed files with 30 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
examples/workflows/prompts/implementer.md
+8 -4
View File
@@ -4,12 +4,16 @@ You receive the `impl_plan` artifact (above). Execute it using the tools availab
(`file_read`, `file_write`, `file_edit`, and shell). File writes land in the bound workspace.
Steps:
1. Work through the plan `steps` in order. Read before you edit.
2. Make the change with `file_write` / `file_edit`. Keep new code consistent with the
1. If this work is tracked as a task — or warrants it per the task policy in the context above —
`task_context` to load it and `task_update action=claim` before you start; `task_create` one
if none exists. Skip this for a self-contained change.
2. Work through the plan `steps` in order. Read before you edit.
3. Make the change with `file_write` / `file_edit`. Keep new code consistent with the
surrounding style, naming, and patterns.
3. Run the plan's `verification` commands (build/tests) via shell and fix what fails. Do not
4. Run the plan's `verification` commands (build/tests) via shell and fix what fails. Do not
leave a step in a broken state.
4. When every step is done and verification passes, call the `stage_complete` tool.
5. When every step is done and verification passes, `task_update action=submit_for_review` on the
task (if any), then call the `stage_complete` tool.
The decision history above is ground truth. **If the reviewer requested changes** in a prior
round, you will see that verdict and its notes above — address those specific points; do not