feat(tasks): wire the task tools into role_pipeline

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>

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.
 

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

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.