Make the orchestrating session the single dispatcher of verify-task

skills/address-feedback/SKILL.md

@@ -22,8 +22,9 @@ TODO:
 - [ ] Fetch and filter PR comments
 - [ ] Present filtered list to user for approval
 - [ ] Generate fix task file (round N)
-- [ ] Dispatch execute-task subagent — do NOT implement fixes in this session
-- [ ] Dispatch verify-task subagent — do NOT self-verify
+- [ ] Dispatch execute-task subagent — do NOT implement fixes in this session; execute-task returns a report and
+  does not self-verify or dispatch verify-task
+- [ ] Dispatch verify-task subagent — this orchestrating session dispatches it (see `verify-task`)
 - [ ] Ask user about pr-review re-check
 - [ ] Create local commit — do NOT push
 - [ ] Present questions to user (if any)
@@ -160,7 +161,8 @@ Address PR review feedback (round N): <count> comments from <PR_URL>
 
 ## VERIFY
 
-After implementation, dispatch a fresh `verify-task` subagent (model: haiku, effort: medium).
+After implementation, the orchestrating session dispatches a fresh `verify-task` subagent (model: haiku, effort:
+medium). The implementer does not self-verify or dispatch it.
 ```
 
 ### STANDARD format (more than 5 comments)

skills/execute-task/SKILL.md

@@ -51,9 +51,9 @@ TODO:
 - [ ] Run build + tests — smoke test + unit tests per DONE WHEN.
 - [ ] Update docs — per DOC UPDATE. Append new findings to `docs/tasks/{branch-slug}/exploration.md` using
   flagged format from `skills/ticket-review/templates/exploration.md`. Create the file if it doesn't exist.
-- [ ] Report — use output format below. One final report, no intermediate dumps.
-- [ ] Dispatch verify-task subagent — fresh subagent (model: haiku, effort: medium). Provide task file path + diff.
-  Do not self-verify. Do not report the task as complete until the verify-task subagent passes.
+- [ ] Report — use output format below. One final report, no intermediate dumps. Return the report to the
+  orchestrating session; do not self-verify and do not dispatch subagents. The orchestrating session dispatches
+  verify-task (see `verify-task`).
 ```
 
 ## Output format
@@ -102,5 +102,6 @@ Keep your working context clean to preserve performance and reduce cost:
 
 ## Next
 
-The last step in the Process checklist dispatches a verify-task subagent. Follow the Process — do not skip the
-dispatch step.
+Return your report to the orchestrating session and stop. The orchestrating session — not this subagent —
+dispatches a fresh verify-task subagent (model: haiku, effort: medium) to check the work. Do not self-verify and do
+not dispatch subagents from here. `verify-task` defines the canonical execute → verify → re-verify control flow.

skills/pr-review/SKILL.md

@@ -345,8 +345,9 @@ After presenting the review:
 
 **If verdict is Approve:** invoke the `wrap-up` skill to promote exploration entries, verify doc updates, and report final status.
 
-**If verdict is Request Changes:** the orchestrating session creates a **fix-cycle TODO** and a SIMPLE fix task file
-from the review findings using the SIMPLE template in `task-files.md`:
+**If verdict is Request Changes:** report the findings back to the orchestrating session and stop — this skill runs
+as a subagent and does not dispatch subagents or apply fixes. The orchestrating session then creates a
+**fix-cycle TODO** and a SIMPLE fix task file from the review findings using the SIMPLE template in `task-files.md`:
 
 TODO:
 
@@ -361,11 +362,12 @@ Fix task format:
 
 - TASK: "Fix pr-review findings: \<list the specific issues\>"
 - DONE WHEN: one checkbox per finding + compile check + scope check
-- VERIFY: dispatch fresh subagent to run `verify-task` skill
+- VERIFY: the orchestrating session dispatches a fresh subagent to run `verify-task` (see `verify-task`)
 
-Then dispatches a fresh subagent to run `execute-task` with that fix task file, followed by another
-to run `verify-task` (model: haiku, effort: medium), then another to run `pr-review` (model: sonnet, effort: high).
-If the new review also returns Request Changes, create a new fix-cycle TODO and repeat.
+The orchestrating session dispatches a fresh subagent to run `execute-task` with that fix task file; when it returns,
+the orchestrating session dispatches another to run `verify-task` (model: haiku, effort: medium), then another to run
+`pr-review` (model: sonnet, effort: high). If the new review also returns Request Changes, the orchestrating session
+creates a new fix-cycle TODO and repeats.
 
 **Circuit breaker:** if the same finding appears in 2 consecutive review cycles, or if 3 review cycles complete
 without reaching Approve, stop and escalate to the user — the issue likely requires a design discussion, not

skills/start-ritus/SKILL.md

@@ -56,16 +56,23 @@ it, do not pre-plan the full chain.
 
 ## Subagent configs
 
-The **orchestrating session** is whatever agent loaded start-ritus — typically the main conversation session.
+The **orchestrating session** is whatever agent loaded start-ritus — typically the main conversation session, and
+also the session running an orchestration skill such as `ticket-review`, `address-feedback`, or `debug`.
 When a skill says to dispatch, spawn a **fresh subagent** and instruct it to load the target skill.
 Never use a skill name as the agent type — skill names are not agent types.
 
+**Only the orchestrating session dispatches subagents.** A dispatched subagent (`execute-task`, `verify-task`,
+`pr-review`) never dispatches another subagent — it returns a report and the orchestrating session dispatches the
+next one. `verify-task` holds the canonical description of the execute → verify → re-verify dispatch loop.
+
 | Subagent | Model | Effort | Key constraints |
 |----------|-------|--------|-----------------|
-| `execute-task` | per triage | per triage | Implement STEPS exactly; do not redesign |
+| `execute-task` | per triage | per triage | Implement STEPS exactly; do not redesign; return a report — never dispatch verify-task |
 | `verify-task` | haiku | medium | Read-only except build/test/lint; never fix; never trust implementer claims |
 | `pr-review` | sonnet | high | Adversarial; never apply fixes; use `origin/` refs; default to "Request changes" |
-| `address-feedback` | per triage | per triage | Fetch PR comments, generate fix task, dispatch execute-task; never push |
+
+`address-feedback` is not dispatched as a subagent — it runs in the orchestrating session (it gates on user
+approval) and itself dispatches `execute-task` then `verify-task`.
 
 Parallel vs sequential grouping is determined by `ticket-review`'s execution plan. When in doubt, run sequentially.
 

skills/ticket-review/SKILL.md

@@ -419,10 +419,12 @@ TODO:
 For parallel groups, list all tasks in the group together. Mark each item as subagents complete. If verify-task
 returns FAIL, add fix items inline before marking the original task done.
 
-Then dispatch `execute-task` following the execution plan:
+Then dispatch `execute-task` following the execution plan. This orchestrating session owns every dispatch —
+`execute-task` returns a report and never dispatches `verify-task` itself (see `verify-task` for the canonical
+control flow):
 
-- **Parallel groups**: dispatch multiple `execute-task` subagents simultaneously. Each execute-task dispatches its own
-  `verify-task` subagent (model: haiku, effort: medium) per execute-task's Process checklist.
-- **Sequential groups**: wait for previous group's tasks to all pass `verify-task` subagent before starting.
+- **Parallel groups**: dispatch multiple `execute-task` subagents simultaneously. When each execute-task returns its
+  report, dispatch a fresh `verify-task` subagent (model: haiku, effort: medium) for that task.
+- **Sequential groups**: wait for the previous group's tasks to all pass their `verify-task` subagent before starting.
 
 Do not implement tasks in this session.

skills/ticket-review/templates/task-files.md

@@ -19,7 +19,8 @@ Implement directly. Log in commit message only.
 
 ## VERIFY
 
-After implementation, dispatch a fresh `verify-task` subagent (model: haiku, effort: medium). Do not self-verify.
+After implementation, the orchestrating session dispatches a fresh `verify-task` subagent (model: haiku, effort:
+medium). The implementer does not self-verify or dispatch it.
 ```
 
 ## STANDARD / EPIC — full task file
@@ -80,10 +81,10 @@ none | Add a new <resource> | Add a new endpoint | ...
 
 ## VERIFY
 
-After implementation, dispatch a fresh `verify-task` subagent (model: haiku, effort: medium) to independently verify
-DONE WHEN conditions. Do not self-verify — the reviewer must have a clean context.
-If verification fails, dispatch `execute-task` (fresh subagent) to fix the gaps,
-then dispatch a new `verify-task` subagent to re-verify. Repeat until PASS.
+After implementation, the orchestrating session dispatches a fresh `verify-task` subagent (model: haiku, effort:
+medium) to independently verify DONE WHEN conditions. The implementer does not self-verify — the reviewer must have
+a clean context. If verification fails, the orchestrating session dispatches `execute-task` (fresh subagent) to fix
+the gaps, then dispatches a new `verify-task` subagent to re-verify. Repeat until PASS.
 
 ## DOC UPDATE
 

skills/verify-task/SKILL.md

@@ -25,6 +25,10 @@ TODO:
 
 ## Subagent dispatch instructions
 
+**This section is the single source of truth for the execute → verify → re-verify dispatch loop.** Other skills
+reference it rather than redefining who dispatches. The **orchestrating session** (the agent that loaded
+`start-ritus` — never an implementer/reviewer subagent) owns every dispatch in the loop.
+
 When the orchestrating session needs to run verify-task, dispatch a fresh subagent with:
 - **Model:** haiku
 - **Effort:** medium