Reuse named agents within recipe flows

.agents/skills/recipe-add-integration-tests/SKILL.md

@@ -10,7 +10,7 @@ description: "Add integration/E2E tests to existing codebase using Design Docs."
 3. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` — review resolution and agent coordination
 4. [LOAD IF NOT ACTIVE] `llm-friendly-context` — task file contract
 
-**Spawn rule**: every `spawn_agent` call uses `fork_turns="none"` so the subagent receives only the task message and explicitly provided context.
+**Invocation rule**: Start each named agent with `spawn_agent` and `fork_turns="none"`. When invoking the same named agent again within this flow, use `followup_task` on its existing instance with the inputs specified for the current invocation.
 
 **Context**: Test addition workflow for existing implementations
 
@@ -21,11 +21,11 @@ description: "Add integration/E2E tests to existing codebase using Design Docs."
 **Execution Plan**: Reuse the active execution plan. When the workflow has multiple dependent actions and no plan exists, create one that tracks them through final verification.
 
 **Execution Method**:
-- Skeleton generation -> Spawn acceptance-test-generator agent
+- Skeleton generation -> Invoke acceptance-test-generator agent
 - Task file creation -> Orchestrator creates directly (minimal context usage)
-- Test implementation -> Spawn task-executor agent
-- Test review -> Spawn integration-test-reviewer agent
-- Quality checks -> Spawn quality-fixer agent
+- Test implementation -> Invoke task-executor agent
+- Test review -> Invoke integration-test-reviewer agent
+- Quality checks -> Invoke quality-fixer agent
 
 Document paths: $ARGUMENTS
 
@@ -48,7 +48,7 @@ Treat paths under `docs/ui-spec/` as UI Specs and the supplied `docs/design/` pa
 
 ### Step 2: Skeleton Generation
 
-Spawn acceptance-test-generator with the validated document paths from Step 1. Include UI Specs as optional UI evidence.
+Invoke acceptance-test-generator with the validated document paths from Step 1. Include UI Specs as optional UI evidence.
 ```text
 Generate test skeletons from the following documents:
 - Design Docs: [paths]
@@ -103,7 +103,7 @@ Execute one task file at a time through Steps 4 -> 5 -> 6 -> 7 before starting t
 ### Step 5: Test Review
 
 Use integration/E2E paths from `taskWriteSet` as the test-review input set.
-Spawn integration-test-reviewer with `changedTestFiles`, `diffBase`, `skeletonFiles: [artifact paths in the current task]`, and `taskFile`.
+Invoke integration-test-reviewer with `changedTestFiles`, `diffBase`, `skeletonFiles: [artifact paths in the current task]`, and `taskFile`.
 Keep `testsAdded` as reporting metadata only.
 
 Consume the reviewer decision, actionable findings, and governing basis. Apply Orchestrator Escalation Resolution when the result is blocked or cannot support the next action.
@@ -116,7 +116,7 @@ Proceed when the review passes. When it contains actionable revision findings, a
 
 ### Step 7: Quality Check
 
-Spawn the quality fixer from the current task's Step 3 table row with `task_file`, `filesModified: taskWriteSet`, and the executor's operation-verification evidence.
+Invoke the quality fixer from the current task's Step 3 table row with `task_file`, `filesModified: taskWriteSet`, and the executor's operation-verification evidence.
 
 **Expected output**: `status` (`stub_detected`/`pass`/`blocked`)
 

.agents/skills/recipe-build/SKILL.md

@@ -11,7 +11,7 @@ description: "Execute an approved backend Work Plan autonomously through task ex
 4. `subagents-orchestration-guide`
 5. `llm-friendly-context`
 
-Every `spawn_agent` call uses `fork_turns="none"` and supplies the exact artifact paths needed by that specialist.
+**Invocation rule**: Start each named agent with `spawn_agent` and `fork_turns="none"`. When invoking the same named agent again within this flow, use `followup_task` on its existing instance with the inputs specified for the current invocation. Supply the exact artifact paths needed by that specialist.
 
 ## Orchestrator Role
 

.agents/skills/recipe-design/SKILL.md

@@ -10,7 +10,7 @@ description: "Execute from codebase-scoped analysis to design document creation.
 3. [LOAD IF NOT ACTIVE] `requirement-convergence` — requirements hearing and scope-confirmation output
 4. [LOAD IF NOT ACTIVE] `llm-friendly-context` — document and review handoffs
 
-**Spawn rule**: every `spawn_agent` call uses `fork_turns="none"` so the subagent receives only the task message and explicitly provided context.
+**Invocation rule**: Start each named agent with `spawn_agent` and `fork_turns="none"`. When invoking the same named agent again within this flow, use `followup_task` on its existing instance with the inputs specified for the current invocation.
 
 **Context**: Dedicated to the design phase.
 
@@ -21,7 +21,7 @@ description: "Execute from codebase-scoped analysis to design document creation.
 **Execution Plan**: Reuse the active execution plan. When the workflow has multiple dependent actions and no plan exists, create one that tracks them through final verification.
 
 **Execution Protocol**:
-1. **Spawn agents for analysis and document work** -- your role is to invoke sub-agents, select from their compact evidence against governing requirements, pass the selected material onward, and report results.
+1. **Invoke agents for analysis and document work** -- your role is to invoke sub-agents, select from their compact evidence against governing requirements, pass the selected material onward, and report results.
 2. **Run the design flow below in order**:
    - Execute: scope evidence -> [Stop: Scope confirmation] -> optional PRD update/review/[Stop: PRD confirmation] -> codebase-analyzer -> optional ADR batch/batch review/[Stop: ADR-batch confirmation] -> Design Doc -> code-verifier/Review Resolution -> document-reviewer -> design-sync -> [Stop: Design confirmation]
    - **[STOP — BLOCKING]** At every `[Stop: ...]` marker -> Present status to user for confirmation and proceed after explicit confirmation.
@@ -66,7 +66,7 @@ Execute the process below within design scope.
 
 ### Step 1: Scope and Cost Evidence
 
-Apply the subagents-orchestration-guide Requirement Evidence Handoff, then spawn requirement-analyzer with that minimum contract.
+Apply the subagents-orchestration-guide Requirement Evidence Handoff, then invoke requirement-analyzer with that minimum contract.
 
 Step 1 completes when the requirement-analyzer result is received. While it runs, apply the subagent-delegation independence boundary; Step 2 depends on the completed scope and cost evidence.
 
@@ -89,39 +89,39 @@ If `prdRequired` is true and the user neither provides a PRD path nor explicitly
 After confirmation, record the final scale. When the user's answer changes the analysis target or scope/cost evidence, re-run requirement-analyzer; otherwise update the convergence record directly. Use the current PRD path as carrier when available; otherwise use the compact `convergence` object.
 
 ### Step 3: Upstream Confirmation and Codebase Analysis
-When Step 2 marked an existing PRD for update, spawn prd-creator in update mode with that PRD path and the confirmed `convergence` object. Review the updated PRD with document-reviewer using its path as `target`, then resolve findings through Review Resolution. After the review permits approval, present the updated PRD for user confirmation. Continue with its path as the carrier after approval.
+When Step 2 marked an existing PRD for update, invoke prd-creator in update mode with that PRD path and the confirmed `convergence` object. Review the updated PRD with document-reviewer using its path as `target`, then resolve findings through Review Resolution. After the review permits approval, present the updated PRD for user confirmation. Continue with its path as the carrier after approval.
 
 **[STOP — BLOCKING when a PRD was updated]** Wait for user confirmation of the updated PRD.
 
-When analysis is required under the subagents-orchestration-guide reuse rule, use the Fullstack Codebase Analysis assignment in `subagents-orchestration-guide`'s `references/monorepo-flow.md` for a fullstack scope; otherwise spawn codebase-analyzer: "exploration_mode: [mode from Analysis Assignment]. Analyze the existing codebase to provide compact decision materials for ADR selection, minimal Design Doc creation, and verification. requirement_analysis: [confirmed Step 1 scopeEvidence]. requirements: [confirmed requirements]. prd_path: [current PRD path when present]. target_paths: [confirmed scopeEvidence.affectedFiles]."
+When analysis is required under the subagents-orchestration-guide reuse rule, use the Fullstack Codebase Analysis assignment in `subagents-orchestration-guide`'s `references/monorepo-flow.md` for a fullstack scope; otherwise invoke codebase-analyzer: "exploration_mode: [mode from Analysis Assignment]. Analyze the existing codebase to provide compact decision materials for ADR selection, minimal Design Doc creation, and verification. requirement_analysis: [confirmed Step 1 scopeEvidence]. requirements: [confirmed requirements]. prd_path: [current PRD path when present]. target_paths: [confirmed scopeEvidence.affectedFiles]."
 
 Apply the documentation-criteria Choice filter, then the Durability filter, to `decisionMaterials.candidateDecisionPoints`. `adrDecisionPoints` contains every current-scope point that passes both filters; an empty array routes directly to Design Doc. Record `documentTypeRationale` from the retained points.
 
 ### Step 4: Design Document Creation
 Create documents according to `documentTypeRationale`:
-- When `adrDecisionPoints` is non-empty, spawn technical-designer once with `document_to_create: ADRBatch`, `decision_points: [adrDecisionPoints]`, confirmed requirements, and `decision_materials: [only the Step 3 simplification, reuse, invalidation, option/cost, contract, and decision-changing unknown material relevant to those points]`. Review all returned `paths[]` in one document-reviewer invocation using `doc_type: ADRBatch` and `targets: [all paths]`. Apply Review Resolution to the batch, rerun the batch review when an accepted correction changes a file, then present one ADR-batch confirmation request.
+- When `adrDecisionPoints` is non-empty, invoke technical-designer once with `document_to_create: ADRBatch`, `decision_points: [adrDecisionPoints]`, confirmed requirements, and `decision_materials: [only the Step 3 simplification, reuse, invalidation, option/cost, contract, and decision-changing unknown material relevant to those points]`. Review all returned `paths[]` in one document-reviewer invocation using `doc_type: ADRBatch` and `targets: [all paths]`. Apply Review Resolution to the batch, rerun the batch review when an accepted correction changes a file, then present one ADR-batch confirmation request.
 
 **[STOP — BLOCKING when ADRs were created]** Wait for one user confirmation of the reviewed ADR batch before creating the Design Doc.
 
-Record every approved ADR file as `Accepted` when ADRs were created. Spawn technical-designer with `document_to_create: DesignDoc`, `adr_paths: [accepted ADR paths or []]`, the confirmed requirement carrier, and `decision_materials: [only Step 3 material that changes reuse, simplification, implementation validity, a selected ADR decision, a preserved contract, or verification]`. The confirmed requirements define scope, and selected ADR decisions supply the current technical choices, revisable when a smaller sufficient design is supported.
+Record every approved ADR file as `Accepted` when ADRs were created. Invoke technical-designer with `document_to_create: DesignDoc`, `adr_paths: [accepted ADR paths or []]`, the confirmed requirement carrier, and `decision_materials: [only Step 3 material that changes reuse, simplification, implementation validity, a selected ADR decision, a preserved contract, or verification]`. The confirmed requirements define scope, and selected ADR decisions supply the current technical choices, revisable when a smaller sufficient design is supported.
 
 ### Step 5: Code Verification
 
 **Review reception:** Unnecessary repairs create lasting work. Before assigning a fix, use Review Resolution to judge no change, removal or narrowing, and reuse first; record why any retained or added mechanism is necessary.
-Spawn code-verifier agent: "Verify the Design Doc against the current codebase. document_path: [Design Doc path from Step 4]. doc_type: design-doc."
+Invoke code-verifier agent: "Verify the Design Doc against the current codebase. document_path: [Design Doc path from Step 4]. doc_type: design-doc."
 
 Apply Review Resolution to every discrepancy before document review, using technical-designer in update mode for selected corrections and its bounded rerun rule. When the `apply` set is empty, carry the resolved verification summary, declines with reasons, and material limitations to Step 6.
 
 ### Step 6: Document Review
-Spawn document-reviewer agent: "Review the Design Doc for consistency, completeness, and adopted design validity. doc_type: DesignDoc. review_context: creation. target: [Design Doc path]. requirements_verbatim: [original user requirements]. confirmed_requirement_context: [complete confirmed requirement context from Step 2]. decision_materials: [only Step 3 material that constrains this design]. verification_resolution: [resolved Step 5 evidence]."
+Invoke document-reviewer agent: "Review the Design Doc for consistency, completeness, and adopted design validity. doc_type: DesignDoc. review_context: creation. target: [Design Doc path]. requirements_verbatim: [original user requirements]. confirmed_requirement_context: [complete confirmed requirement context from Step 2]. decision_materials: [only Step 3 material that constrains this design]. verification_resolution: [resolved Step 5 evidence]."
 
 Route the result before consistency verification:
 - `pass`: continue
 - `needs_revision`: apply Review Resolution with the creating technical-designer, then review the updated document
 - `rejected`: apply Orchestrator Escalation Resolution. Continue after an evidence-based self-resolution; ask the user only when that procedure reaches a user-decision condition
 
 ### Step 7: Consistency Verification
-Spawn design-sync agent: "Verify consistency of the design document with other existing design documents and project constraints."
+Invoke design-sync agent: "Verify consistency of the design document with other existing design documents and project constraints."
 
 **Note**: design-sync returns `sync_status: "SKIPPED"` when only 1 Design Doc exists. This is distinct from `NO_CONFLICTS` and MUST be reported as such to the user.
 
@@ -130,13 +130,13 @@ Request user confirmation using the shared Design Confirmation alignment.
 ## Completion Criteria
 
 - [ ] Obtained compact scope and cost evidence while the user retained product requirements and exclusions and the orchestrator handled comparison, readiness, scale, and routing
-- [ ] Spawned codebase-analyzer and passed only decision-relevant material into ADR/Design Doc creation
+- [ ] Invoked codebase-analyzer and passed only decision-relevant material into ADR/Design Doc creation
 - [ ] Converged the requirement and persisted the record
 - [ ] Confirmed the design scope before codebase analysis and document creation
 - [ ] Created one ADR per qualifying decision point and reviewed the complete batch once, or routed an empty decision-point set directly to Design Doc
 - [ ] Applied Review Resolution to code-verifier discrepancies before document review
-- [ ] Spawned document-reviewer and addressed feedback
-- [ ] Spawned design-sync for consistency verification for Design Docs
+- [ ] Invoked document-reviewer and addressed feedback
+- [ ] Invoked design-sync for consistency verification for Design Docs
 - [ ] Obtained user confirmation for design document
 - [ ] All `[Stop: ...]` markers honored with user confirmation