From afb536f21f2804ac9efbbbd39057669c48c144df Mon Sep 17 00:00:00 2001 From: kami Date: Wed, 24 Jun 2026 10:04:01 +0000 Subject: [PATCH] feat(tasks): wire the task tools into role_pipeline MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- examples/workflows/prompts/analyst.md | 5 ++++- examples/workflows/prompts/implementer.md | 12 ++++++++---- examples/workflows/prompts/reviewer.md | 5 +++++ examples/workflows/role_pipeline.toml | 15 +++++++++++++-- 4 files changed, 30 insertions(+), 7 deletions(-) diff --git a/examples/workflows/prompts/analyst.md b/examples/workflows/prompts/analyst.md index 477a18a7..b96e0bf7 100644 --- a/examples/workflows/prompts/analyst.md +++ b/examples/workflows/prompts/analyst.md @@ -8,7 +8,10 @@ Steps: 1. Read the user's request carefully. Restate what is actually being asked. 2. Use `file_read` and shell (read-only: `ls`, `grep`, `cat`, `find`) to locate the relevant code. Identify the files, modules, and subsystems involved. Do not modify anything. -3. Derive concrete, checkable requirements and acceptance criteria. +3. Check for existing work: `task_search` for related, duplicate, or blocking tasks, and + `task_context` to load any the request names. Fold what you find into the analysis rather + than re-deriving it; flag a duplicate instead of restating it. +4. Derive concrete, checkable requirements and acceptance criteria. The decision history above (steering, approvals, prior verdicts) is ground truth — honour it. diff --git a/examples/workflows/prompts/implementer.md b/examples/workflows/prompts/implementer.md index d639ba0e..6e117c78 100644 --- a/examples/workflows/prompts/implementer.md +++ b/examples/workflows/prompts/implementer.md @@ -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 diff --git a/examples/workflows/prompts/reviewer.md b/examples/workflows/prompts/reviewer.md index 29bd1f74..04d87e18 100644 --- a/examples/workflows/prompts/reviewer.md +++ b/examples/workflows/prompts/reviewer.md @@ -29,5 +29,10 @@ Emit your result as the `review_report` artifact (JSON, schema provided): line), each tied to the requirement or plan step it violates, so the implementer knows exactly what to fix. If `approved`, briefly state which requirements the patch satisfies. +If the work is tracked as a task, reflect your verdict on it (use `task_context` first if you +need its own acceptance criteria): on `approved`, `task_update action=complete`; on +`changes_requested`, leave it claimed for the implementer — optionally add a `note` summarising +what's needed. + Use `changes_requested` only for real problems — the loop is capped and will escalate to a human if it runs too long. Be decisive. diff --git a/examples/workflows/role_pipeline.toml b/examples/workflows/role_pipeline.toml index e62175a1..e8e77e62 100644 --- a/examples/workflows/role_pipeline.toml +++ b/examples/workflows/role_pipeline.toml @@ -27,11 +27,13 @@ start = "analyst" # 1. Understand the request and the relevant code. Read-only. # ground_references: every workspace-relative file path the analysis names is checked # for existence; a hallucinated path fails the stage and retries with the misses fed back. +# task_search/task_context (read-only) let it find related or duplicate tasks and load +# their context, so the analysis is grounded in existing work rather than re-derived. [[stages]] id = "analyst" prompt = "prompts/analyst.md" produces = [{ name = "analysis", kind = "analysis" }] -allowed_tools = ["file_read", "ShellTool"] +allowed_tools = ["file_read", "ShellTool", "task_search", "task_context"] ground_references = true token_budget = 16384 max_retries = 2 @@ -60,12 +62,18 @@ max_retries = 2 # stage may write — a FILE_WRITE outside it is blocked as scope creep. Left open # here because the targets are task-specific; a task-scoped workflow would set e.g. # writes = ["core/sessions/**", "testing/sessions/**"] +# The task tools let it own the work item across the loop: claim before starting, +# submit_for_review once verification passes, and add notes (create one first if the +# work warrants tracking and none exists — see the task policy in .correx/project.toml). [[stages]] id = "implementer" prompt = "prompts/implementer.md" needs = ["impl_plan"] produces = [{ name = "patch", kind = "file_written" }] -allowed_tools = ["file_read", "file_write", "file_edit", "ShellTool"] +allowed_tools = [ + "file_read", "file_write", "file_edit", "ShellTool", + "task_create", "task_update", "task_context", "task_search", +] token_budget = 32768 max_retries = 3 @@ -85,11 +93,14 @@ max_retries = 0 # 5. Review the patch against the plan AND the analyst's acceptance criteria. The reviewer # needs `analysis` so it judges the diff against concrete, pre-stated criteria (§5 narrow # question) rather than whole files against taste. +# 5b. task_context lets the reviewer judge the patch against the task's own acceptance +# criteria; task_update lets it complete the task on an approved verdict (and only then). [[stages]] id = "reviewer" prompt = "prompts/reviewer.md" needs = ["patch", "impl_plan", "analysis"] produces = [{ name = "review_report", kind = "review_report" }] +allowed_tools = ["task_context", "task_update"] token_budget = 32768 max_retries = 2