@vpxa/aikit 0.1.213 → 0.1.215

package/scaffold/dist/definitions/skills/multi-agents-development.mjs

@@ -1,6 +1,6 @@
 var e=[{file:`architecture-review-prompt.md`,content:`# Architecture Review Prompt Template
 
-Use this template when dispatching **Architect-Reviewer-Alpha** and **Architect-Reviewer-Beta** for architecture review. Only needed when changes cross module boundaries, introduce new patterns, or modify shared infrastructure.
+Use when dispatching **Architect-Reviewer-Alpha** and **Architect-Reviewer-Beta** for boundary, pattern, infra, or public API changes.
 
 ---
 
@@ -75,15 +75,14 @@ You are performing an architecture review. Focus on structural decisions, not co
 
 ## Usage Notes
 
-- **Only trigger architecture review when**: changes cross module boundaries, new patterns are introduced, shared infrastructure is modified, or public API surface changes
-- Both Alpha and Beta reviewers run in parallel for multi-model perspective
-- Architecture blockers are HIGH priority — must resolve before merge
-- If both reviewers flag the same concern, it's almost certainly a real issue
+- Trigger for boundary, pattern, infra, or API-surface changes
+- Run Alpha and Beta in parallel
+- Shared blocker from both reviewers = likely real issue
 `},{file:`code-quality-review-prompt.md`,content:`# Code Quality Review Prompt Template
 
-Use this template when dispatching **Code-Reviewer-Alpha** and **Code-Reviewer-Beta** for dual code quality review. Both reviewers get the same prompt — different models catch different issues.
+Use when dispatching **Code-Reviewer-Alpha** and **Code-Reviewer-Beta** for dual code review. Same prompt; different models catch different issues.
 
-This review runs as part of the code review stage. Reviewers gather evidence first; the FORGE gate runs only after code review and any conditional reviews complete.
+Runs in code review stage. Gather evidence first; FORGE gate runs after code review and any conditional reviews.
 
 ---
 
@@ -165,17 +164,13 @@ You are performing a code review. Your job is to evaluate HOW the implementation
 
 ## Usage Notes
 
-- Run this during the code review stage, before any architecture/security review and before the FORGE gate
-- Both Alpha and Beta reviewers can use this template for multi-model cross-validation, or one reviewer can use the spec-alignment-focused template below
-- Combine findings from both reviewers before deciding on action
-- **Blocker** findings = REQUEST_CHANGES (must fix)
-- **Major** findings = usually REQUEST_CHANGES unless truly optional
-- **Minor/Nit** = APPROVE_WITH_SUGGESTIONS (fix in follow-up or ignore)
+- Run before architecture/security review and before FORGE gate
+- Use for dual review or pair with spec-review prompt
+- Blocker = REQUEST_CHANGES
+- Minor/Nit = APPROVE_WITH_SUGGESTIONS
 `},{file:`implementer-prompt.md`,content:`# Implementer Dispatch Prompt Template
 
-Use this template when dispatching **Implementer**, **Frontend**, or **Refactor** agents.
-
-Fill in the bracketed sections with task-specific content. The Orchestrator provides ALL context — the subagent should NOT need to search/explore.
+Use when dispatching **Implementer**, **Frontend**, or **Refactor**. Provide all needed context; subagent should not search beyond scope.
 
 ---
 
@@ -259,14 +254,13 @@ Hit a wall and cannot proceed:
 
 ## Usage Notes
 
-- **Always paste actual code snippets** in §3 — use \`compact()\` or \`digest()\` to extract relevant context before crafting the prompt
-- **Keep scope tight** — 1-3 files maximum per dispatch
-- **Include failing test output** if dispatching a bug fix
-- **For Frontend agent**: add design requirements, responsive breakpoints, component hierarchy
-- **For Refactor agent**: include before/after expectations, what specifically to clean up
+- Paste actual code snippets in §3
+- Keep scope to 1-3 files
+- Include failing test output for bug fixes
+- Add frontend or refactor-specific constraints when needed
 `},{file:`parallel-dispatch-example.md`,content:`# Parallel Dispatch Worked Example
 
-This example shows how the Orchestrator decomposes a feature into parallel tasks, crafts context for each subagent, and manages the batch through review.
+Shows parallel feature decomposition and review flow.
 
 ---
 
@@ -278,30 +272,18 @@ This example shows how the Orchestrator decomposes a feature into parallel tasks
 
 ## Step 1: Scope Map & Decomposition
 
-Orchestrator runs \`scope_map({ task: "notification preferences" })\` and identifies:
-
-| Area | Files | Agent |
-|------|-------|-------|
-| Backend API | \`services/notification-prefs.service.ts\`, \`routes/notification-prefs.route.ts\` | Implementer |
-| Database | \`migrations/add-notification-prefs.ts\`, \`models/notification-prefs.model.ts\` | Implementer |
-| Frontend Page | \`pages/settings/notifications.tsx\`, \`components/NotificationToggle.tsx\` | Frontend |
-| Tests | \`__tests__/notification-prefs.test.ts\` | Implementer |
+Orchestrator runs \`scope_map({ task: "notification preferences" })\`:
+Backend API + DB → Implementer. Frontend page → Frontend. Tests → Implementer.
 
 ## Step 2: Independence Check (5-Question Checklist)
 
-| # | Question | Backend API + DB | Frontend Page |
-|---|----------|-----------------|---------------|
-| 1 | Same files? | \`services/\`, \`routes/\`, \`migrations/\`, \`models/\` | \`pages/\`, \`components/\` |
-| 2 | Shared state? | No — backend defines API contract | No — consumes API contract |
-| 3 | Execution order? | No — can define API while UI is built | No — can mock API response |
-| 4 | Shared new types? | Exports \`NotificationPrefs\` type | Imports same type |
-| 5 | Parallel-safe? | ✅ Yes — different directories | ✅ Yes — different directories |
+Different files, no shared mutable state, no execution-order dependency. Shared type contract first.
 
-**Decision: PARALLEL** — But first define the shared type contract.
+**Decision: PARALLEL**
 
 ## Step 3: Shared Context Prep
 
-Before dispatching, Orchestrator creates the shared contract:
+Before dispatching, Orchestrator creates shared contract:
 
 \`\`\`typescript
 // Type contract — paste into BOTH agent prompts
@@ -398,31 +380,22 @@ STATUS PROTOCOL: DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED
 
 ## Step 5: Review Pipeline
 
-Both agents return DONE. Orchestrator runs the ordered review cycle:
-
-1. **Code Review** (Alpha + Beta in parallel):
-  - Alpha: PASS_WITH_NOTES — acceptance criteria met; add keyboard accessibility on toggles
-  - Beta: APPROVE_WITH_SUGGESTIONS — extract validation schema to shared file
-
-2. **Architecture Review** (not triggered — no boundary changes)
+Both agents return DONE. Orchestrator reviews:
 
-3. **Security Review** (not triggered — no auth, crypto, or risky input handling)
-
-4. **FORGE Gate**: \`evidence_map({ action: "gate" })\` → YIELD (all review evidence collected)
+1. **Code Review** (Alpha + Beta): PASS_WITH_NOTES + APPROVE_WITH_SUGGESTIONS
+2. **Architecture Review**: not triggered
+3. **Security Review**: not triggered
+4. **FORGE Gate**: \`evidence_map({ action: "gate" })\` → YIELD
 
 ## Step 6: Present Results
 
-Stop here and present the review findings and gate result before any commit or merge action.
+Present review findings and gate result before commit or merge.
 
 ---
 
 ## Key Takeaways
 
-1. **Define shared contracts FIRST** — paste into all agent prompts
-2. **Independence check takes 30 seconds** — prevents hours of merge conflicts
-3. **Each agent gets ONLY its files** — focused context = better output
-4. **Review happens before the gate** — code review first, then architecture/security (conditional), then FORGE
-5. **FORGE gates at the end** — not between every step
+Define contract first. Batch only independent work. Review before gate.
 `},{file:`SKILL.md`,content:`---
 name: multi-agents-development
 description: "Comprehensive patterns for orchestrating multiple AI agents in parallel development workflows. Covers task decomposition, parallel dispatch, context crafting, status handling, review pipelines, and recovery."
@@ -438,11 +411,9 @@ metadata:
 
 # Multi-Agent Development
 
-Comprehensive patterns for orchestrating multiple AI agents in parallel development workflows. Covers task decomposition, parallel dispatch, context crafting, status handling, review pipelines, and recovery.
-
-**Core Principle**: Dispatch multiple agents for focused tasks. Each subagent gets fresh, focused context with explicit scope — never inherited session state.
+Patterns for parallel multi-agent work: decomposition, dispatch, context, status, review, recovery.
 
-Load this skill when orchestrating multi-agent work: planning parallel batches, crafting delegation prompts, handling implementer status, running review pipelines, or recovering from agent failures.
+**Core Principle**: Dispatch focused agents with fresh context and explicit scope.
 
 ---
 
@@ -452,25 +423,18 @@ Load this skill when orchestrating multi-agent work: planning parallel batches,
 
 | Role | Agents | When to Use | Parallelizable |
 |------|--------|-------------|----------------|
-| **Orchestration** | Orchestrator, Planner | Workflow control, planning | No (sequential) |
-| **Implementation** | Implementer, Frontend, Refactor | Code creation/modification | Yes (disjoint files only) |
-| **Research** | Explorer, Researcher-Alpha/Beta/Gamma/Delta | Codebase exploration, decisions | Yes (always) |
-| **Review** | Code-Reviewer-Alpha/Beta, Architect-Reviewer-Alpha/Beta | Quality verification | Yes (always) |
-| **Diagnostics** | Debugger, Security | Issue tracing, vulnerability analysis | Yes (read-only) |
-| **Documentation** | Documenter | README, API docs, changelog | Yes (disjoint files) |
+| **Orchestration** | Orchestrator, Planner | Plan/control | No |
+| **Implementation** | Implementer, Frontend, Refactor | Code changes | Yes |
+| **Review** | Code-Reviewer-Alpha/Beta, Architect-Reviewer-Alpha/Beta | Verify | Yes |
 
 ### Model Selection by Task Complexity
 
-Choose the **least powerful model that can handle the role**:
-
 | Complexity Signal | Model Tier | Example Agents |
 |-------------------|-----------|----------------|
-| Mechanical (rename, move, add field) | Fast model | Explorer (Gemini Flash) |
-| Standard (implement spec, write tests) | Mid-tier | Implementer (GPT-5.4), Refactor (GPT-5.4) |
-| Judgment-heavy (architecture, security, debug) | Strongest | Debugger (Opus 4.6), Security (Opus 4.6) |
-| Multi-model cross-validation | Mixed | Researcher-Alpha/Beta/Gamma/Delta (all different) |
+| Mechanical (rename, move, add field) | Fast model | Explorer |
+| Standard (implement spec, write tests) | Mid-tier | Implementer/Refactor |
 
-**Upgrade signal**: If an agent returns \`BLOCKED\` or \`DONE_WITH_CONCERNS\` on a task classified as "Standard", consider re-dispatching to a stronger model.
+**Upgrade signal**: \`BLOCKED\` or \`DONE_WITH_CONCERNS\` on Standard task → re-dispatch to stronger model.
 
 ---
 
@@ -481,36 +445,31 @@ Choose the **least powerful model that can handle the role**:
 
 ### Decomposition Checklist
 
-For each task, specify ALL of:
-- [ ] **Target files** — exact paths to create or modify
-- [ ] **Acceptance criteria** — what "done" looks like (testable)
-- [ ] **Agent assignment** — which agent handles this
-- [ ] **Dependencies** — which tasks must complete first (if any)
+For each task, specify:
+- [ ] **Target files** — exact paths
+- [ ] **Acceptance criteria** — testable done state
+- [ ] **Agent assignment** — who owns task
+- [ ] **Dependencies** — prerequisite tasks
 
 ### Sizing Guide
 
 | Task Size | Files | Example | Agent |
 |-----------|-------|---------|-------|
-| **Micro** | 1 file | Add a utility function | Implementer |
-| **Small** | 1-2 files | New endpoint + test | Implementer |
-| **Standard** | 2-3 files | Feature with service + controller + test | Implementer |
-| **Too big** | 4+ files | **SPLIT IT** — decompose further | — |
+| **Standard** | 2-3 files | Service + controller + test | Implementer |
 
 ### Splitting Strategies
-- **By layer**: Service logic (Implementer) + UI component (Frontend) + tests (Implementer)
-- **By feature boundary**: Auth endpoints (Implementer A) + Profile endpoints (Implementer B)
-- **By concern**: Data model changes (Implementer) + API route changes (Implementer) + UI updates (Frontend)
+- **By layer**: Service + UI + tests
 
 ---
 
 ## §3 Independence Decision Tree
 
-Before marking tasks as parallel, walk this tree:
+Before marking tasks parallel, walk this tree:
 
 \`\`\`
 Task A and Task B — can they run in parallel?
 │
-├─ Do they share ANY files? (create, modify, or delete the same file)
+├─ Do they share ANY files? (create, modify, or delete same file)
 │   ├─ YES → SEQUENTIAL (or merge into one task)
 │   └─ NO ↓
 │
@@ -518,7 +477,7 @@ Task A and Task B — can they run in parallel?
 │   ├─ YES → SEQUENTIAL
 │   └─ NO ↓
 │
-├─ Does B need A's output? (B reads a file A creates, B uses A's new export)
+├─ Does B need A's output? (B reads file A creates, B uses A's new export)
 │   ├─ YES → SEQUENTIAL (A before B)
 │   └─ NO ↓
 │
@@ -537,19 +496,14 @@ Task A and Task B — can they run in parallel?
 
 | Situation | Verdict | Why |
 |-----------|---------|-----|
-| Both import from same module (read-only) | ✅ Parallel | Reading shared code is fine |
-| Both add exports to same index file | ❌ Sequential | Concurrent index.ts edits will conflict |
-| A creates a type, B uses that type | ❌ Sequential | B depends on A's output |
-| Both modify different test files | ✅ Parallel | Disjoint file sets |
-| Both touch package.json | ❌ Sequential | Shared file |
-| A adds a route, B adds middleware | ⚠️ Check | If B's middleware affects A's route → sequential |
+| Same shared import only | ✅ Parallel | Read-only |
+| Same index/package file | ❌ Sequential | Shared edit |
 
 ### Integration Verification (after parallel batch completes)
 
-1. **Conflict check**: Did any agent unexpectedly modify a file assigned to another agent?
-2. **Import check**: Do all new cross-references resolve?
-3. **Full suite**: \`check({})\` + \`test_run({})\` — everything must pass
-4. **Spot check**: Manually verify at least one task's output matches acceptance criteria
+1. **Conflict check**: unexpected overlap?
+2. **Import check**: cross-references resolve?
+3. **Full suite**: \`check({})\` + \`test_run({})\`
 
 ---
 
@@ -558,9 +512,9 @@ Task A and Task B — can they run in parallel?
 ### Dispatch Rules
 
 1. **Max 4 concurrent file-modifying agents** per batch
-2. **Read-only agents have no limit** — Explorer, Researcher*, Reviewer*, Security can always run in parallel
-3. **Build dependency graph first** — phases with no dependencies MUST be batched together
-4. **Never dispatch two implementers to the same file** — even different sections
+2. **Read-only agents have no limit** — Explorer, Researcher*, Reviewer*, Security
+3. **Build dependency graph first** — dependency-free phases batch together
+4. **Never dispatch two implementers to same file**
 
 ### Batch Strategy
 
@@ -580,21 +534,18 @@ Execution:
 
 | ❌ Don't | ✅ Do Instead |
 |----------|--------------|
-| Dispatch 6 implementers at once | Max 4, queue the rest |
-| Give one agent 10 files | Split into 3-4 focused tasks |
-| Let agents read the full plan | Give each agent ONLY its task context |
-| Retry same prompt on failure | Diagnose first, then re-prompt with fix |
-| Skip review after parallel batch | ALWAYS review + integration verify |
-| Inherit session context to subagent | Build fresh, focused context per dispatch |
+| Dispatch 6 implementers at once | Max 4, queue rest |
+| Give one agent 10 files | Split tasks |
+| Skip review after batch | ALWAYS review + integrate |
 
 ---
 
 ## §5 Context Crafting Guide
 
 ### The Controller Principle
-> **The Orchestrator provides ALL context. Subagents never need to search for context themselves.**
+> **The Orchestrator provides ALL context. Subagents never search for it.**
 
-Each subagent gets a fresh, self-contained prompt. No inherited session state. No "read the plan first."
+Fresh prompt only. No inherited session state.
 
 ### The 6-Point Prompt Template
 
@@ -635,21 +586,13 @@ End with status: DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
 
 | ✅ Include | ❌ Omit |
 |-----------|---------|
-| Exact file paths and code snippets | Full session history |
-| Acceptance criteria | Other agents' tasks |
-| Relevant conventions (from KB) | Unrelated architecture context |
-| Compact/digest of relevant files | Raw file contents of large files |
-| Error messages (if fixing a bug) | Previous failed attempts (unless relevant) |
-| FORGE tier and ceremony | Full FORGE protocol explanation |
+| Exact file paths and snippets | Full session history |
 
 ### Context Size Budget
 
 | Task Complexity | Context Target | Approach |
 |-----------------|---------------|----------|
-| Micro (1 file) | ~500 tokens | Inline code snippet + goal |
-| Small (1-2 files) | ~1000 tokens | \`compact\` of target files + goal |
-| Standard (2-3 files) | ~2000 tokens | \`digest\` of related files + architectural context |
-| Complex (judgment-heavy) | ~3000 tokens | \`digest\` + relevant decisions from AI Kit |
+| Standard (2-3 files) | ~2000 tokens | \`digest\` + architecture |
 
 ---
 
@@ -679,10 +622,9 @@ Orchestrator                          Subagent (fresh instance)
 
 ### Key Rules
 
-1. **One subagent = one task**. Never reuse a subagent for a different task.
-2. **Controller provides context**. The subagent's prompt contains everything it needs — it should NOT need to search/explore the codebase.
-3. **Self-review before handoff**. Every implementer must complete the self-review checklist before declaring DONE.
-4. **Status is mandatory**. Every subagent response MUST end with exactly ONE status code.
+1. **One subagent = one task**
+2. **Controller provides context**
+3. **Status is mandatory**
 
 ---
 
@@ -690,14 +632,14 @@ Orchestrator                          Subagent (fresh instance)
 
 ### Status Codes
 
-Every implementer (Implementer, Frontend, Refactor) MUST end their response with exactly ONE:
+Every implementer (Implementer, Frontend, Refactor) MUST end response with exactly ONE:
 
 | Status | Meaning | Orchestrator Action |
 |--------|---------|-------------------|
-| **DONE** | All tasks complete, self-review passed | → Code review → Conditional architecture/security review → \`evidence_map\` gate → Present results |
-| **DONE_WITH_CONCERNS** | Complete but flagging issues: [list] | → Surface concerns in review and as \`Assumed\` claims in \`evidence_map\` → Likely HOLD at gate |
-| **NEEDS_CONTEXT** | Cannot proceed without: [specific question] | → Provide missing context → Re-dispatch same task (counts toward **Max 2 retries** per task) |
-| **BLOCKED** | Hit a wall: [description] | → Diagnose (see below) |
+| **DONE** | Complete, self-review passed | → Review → arch/security if needed → \`evidence_map\` gate |
+| **DONE_WITH_CONCERNS** | Complete, concerns raised | → Review + \`Assumed\` claims |
+| **NEEDS_CONTEXT** | Missing info | → Add context → re-dispatch |
+| **BLOCKED** | Cannot proceed | → Diagnose |
 
 ### BLOCKED Diagnosis Tree
 
@@ -722,10 +664,8 @@ Agent returned BLOCKED
 
 ### FORGE Composition
 
-Status protocol and FORGE are **independent but composable**:
-
-- **Status** = subjective agent telemetry ("I think I'm done")
-- **FORGE** = objective quality evidence ("the evidence says it's done")
+- **Status** = agent telemetry
+- **FORGE** = evidence-based quality gate
 
 \`\`\`
 DONE               → proceed to code review → conditional architecture/security review → FORGE evidence_map → present results
@@ -736,7 +676,7 @@ BLOCKED            → diagnose:
                       resource/scope issue → re-plan, no FORGE
 \`\`\`
 
-**Critical rule**: Every \`DONE\` status MUST complete code review and any conditional architecture/security review BEFORE \`evidence_map({ action: "gate" })\`. No shortcuts.
+**Critical rule**: Every \`DONE\` must complete code review and any conditional architecture/security review BEFORE \`evidence_map({ action: "gate" })\`.
 
 ---
 
@@ -766,26 +706,17 @@ Stage 5: FORGE Gate — evidence_map({ action: "gate" })
   └─ HARD_BLOCK → escalate to user
 \`\`\`
 
-Use \`check({})\` + \`test_run({})\` to gather evidence for reviewers, but they are not the gate.
+Use \`check({})\` + \`test_run({})\` for reviewer evidence; not gate.
 
 ### Spec Alignment Dimension (for Code Reviewers)
 
-Both Code-Reviewer-Alpha and Code-Reviewer-Beta evaluate an explicit **Spec Alignment** dimension:
-
-1. Does the implementation match the acceptance criteria from the task?
-2. Are there over-builds (features not requested)?
-3. Are there under-builds (requirements missed)?
-4. Does the output match the expected file changes?
-
-This catches spec drift that automated tests might miss.
+Check acceptance criteria, over-build, under-build, and expected file set.
 
 ### When to Skip Stages
 
 | Stage | Skip When |
 |-------|-----------|
-| Architecture Review | No new modules, no boundary changes, no new patterns |
-| Security Review | No auth, no crypto, no external input handling |
-| FORGE Gate | Floor-tier tasks only (simple, mechanical changes) |
+| Architecture Review | No new modules/boundary changes/patterns |
 
 ---
 
@@ -793,16 +724,14 @@ This catches spec drift that automated tests might miss.
 
 ### Retry Policy
 
-- **Max 2 retries** per task — after that, re-plan or escalate
-- Each retry MUST include the specific failure reason in the new prompt
-- Never retry with the same prompt — always add diagnostic context
+**Max 2 retries** per task. Include failure reason. Never reuse same prompt.
 
 ### Loop Detection
 
 If an agent returns the same error/status 2+ times:
-1. **STOP** — do not retry again
-2. Check if the approach is fundamentally wrong
-3. Consider: different agent, different model, different decomposition, or user escalation
+1. **STOP**
+2. Recheck approach
+3. Change agent, model, decomposition, or escalate
 
 ### Emergency Procedures
 
@@ -823,9 +752,9 @@ DOCUMENT → remember what went wrong, update plan
 
 | Signal | Action |
 |--------|--------|
-| Agent modified **2x more files** than planned | Pause, review before continuing |
-| Agent returns \`ESCALATE\` or \`BLOCKED\` repeatedly | Do NOT re-delegate unchanged. Diagnose first |
-| Agent's output contradicts the plan | Stop, compare with plan, re-align |
+| Agent modified **2x more files** than planned | Pause, review |
+| Agent returns \`ESCALATE\` or \`BLOCKED\` repeatedly | Diagnose before re-delegating |
+| Agent's output contradicts plan | Stop, compare, re-align |
 | Tests that were passing now fail | Immediate rollback of that agent's changes |
 
 ---
@@ -836,41 +765,24 @@ DOCUMENT → remember what went wrong, update plan
 
 | ❌ Mistake | Why It Fails | ✅ Fix |
 |-----------|-------------|--------|
-| **Too broad scope** — "implement the auth system" | Agent lacks clear boundaries, produces sprawling changes | Split: "add JWT middleware to auth.ts" + "add login endpoint to routes.ts" |
-| **No constraints** — "add a feature" | Agent invents architecture, conflicts with existing patterns | Include conventions, boundaries, existing patterns in prompt |
-| **Vague output** — "make it work" | No way to verify completion | Specific acceptance criteria: "endpoint returns 200 with {schema}" |
-| **Session context inheritance** — "continue from where we left off" | Subagent has stale/polluted context | Fresh prompt with 6-point template every time |
-| **Skipping reviews** — "it's a small change" | Small changes cause big regressions | ALWAYS run automated gate minimum |
-| **Parallel on shared files** — "both agents edit config.ts" | Merge conflicts, lost changes | Sequential, or merge into one task |
-| **Trusting the report** — "agent said DONE so it's done" | Agents are optimistic, miss edge cases | Automated gate + dual code review catches this |
-| **Brute-force retries** — same prompt beyond **Max 2 retries** per task | Repeating without diagnosis will not change the outcome | Diagnose, change approach, then retry within the limit |
-| **Orchestrator implements** — "just this one small fix" | Breaks the delegation contract, no review | ALWAYS delegate, no matter how small |
+| **Too broad scope** | Sprawling changes | Split tasks |
+| **Parallel on shared files** | Merge conflicts | Sequential or merge task |
 
 ### Red Flags in Agent Output
 
 | Flag | What It Means | Action |
 |------|--------------|--------|
-| Agent modified files outside its scope | Scope creep or misunderstanding | Rollback out-of-scope files, re-delegate with tighter constraints |
-| Agent added dependencies not in plan | Unauthorized architectural decision | Review necessity, likely rollback |
-| Agent skipped self-review checklist | Rushing, likely incomplete | Bounce back with checklist requirement |
-| Agent's DONE but tests fail | Didn't actually self-test | Bounce back with failing test output |
-| Agent asks questions in output instead of using NEEDS_CONTEXT | Misunderstands status protocol | Treat as NEEDS_CONTEXT, educate in next prompt |
+| Files outside scope | Scope creep | Roll back, re-delegate tighter |
 
 ---
 
 ## §11 Flow Context Sharing
 
-### The Problem
-Subagents start fresh — they don't know what the Orchestrator already analyzed. Without context sharing, each subagent redundantly re-reads and re-analyzes the same files, wasting tokens and time.
+### Flow Context Broker
 
-### The Solution: Flow Context Broker
-The \`knowledge\` tool has flow-scoped context actions that enable automatic context sharing between the Orchestrator and subagents during a flow.
+The \`knowledge\` tool supports flow-scoped context sharing.
 
-**How it works:**
-1. **Auto-deposit** — The auto-knowledge interceptor captures results from \`search\`, \`file_summary\`, \`stratum_card\`, \`compact\`, \`blast_radius\`, and \`scope_map\` as flow-scoped context entries
-2. **Role-filtered retrieval** — Before dispatching a subagent, the Orchestrator calls \`withdraw\` with a role profile to get relevant context
-3. **Manual deposit** — Subagents deposit their own discoveries for later agents
-4. **Cleanup** — On flow completion or reset, \`flush\` removes all flow context
+**How it works:** auto-deposit captures tool output, Orchestrator calls \`withdraw\`, subagents can deposit findings, \`flush\` clears flow context.
 
 ### Orchestrator Workflow
 
@@ -882,7 +794,7 @@ knowledge({ action: 'withdraw', profile: '<role>', budget: 6000 })
 // Profiles: implementer, documenter, reviewer, researcher, debugger
 \`\`\`
 
-Include the withdrawn context in the subagent's prompt under "## 3. Architectural Context" (from the 6-point template in §5).
+Paste withdrawn context into "## 3. Architectural Context" from §5.
 
 #### After All Work Completes
 
@@ -893,8 +805,6 @@ knowledge({ action: 'flush' })
 
 ### Subagent Deposit Pattern
 
-Subagents can deposit discoveries for later agents:
-
 \`\`\`
 // Subagent deposits a finding for future agents
 knowledge({ action: 'remember', scope: 'flow', title: 'API validation pattern', content: '...' })
@@ -902,26 +812,11 @@ knowledge({ action: 'remember', scope: 'flow', title: 'API validation pattern',
 
 ### Profile Filtering
 
-Each profile prioritizes different context types:
-
-| Profile | Priorities (highest first) | Use For |
-|---------|---------------------------|---------|
-| \`implementer\` | decisions, patterns, file-cards | Implementer, Frontend, Refactor |
-| \`documenter\` | decisions, step-summaries, analysis | Documenter |
-| \`reviewer\` | decisions, patterns, analysis | Code-Reviewer, Architect-Reviewer |
-| \`researcher\` | search-results, analysis, decisions | Researcher-Alpha/Beta/Gamma/Delta |
-| \`debugger\` | file-cards, analysis, search-results | Debugger |
+Use \`implementer\` profile for Implementer/Frontend/Refactor tasks.
 
 ### Budget Management
 
-The \`budget\` parameter (default: 6000 chars) caps the total context returned. Adjust based on task complexity:
-
-| Task Type | Recommended Budget |
-|-----------|--------------------|
-| Micro (1 file fix) | 2000 |
-| Standard implementation | 6000 |
-| Complex multi-file | 10000 |
-| Research/investigation | 8000 |
+\`budget\` caps returned context. Standard implementation: 6000.
 
 ### Integration with 6-Point Template
 
@@ -935,28 +830,21 @@ Update the prompt template from §5 to include flow context:
 
 ### Key Rules
 
-1. **Always withdraw before dispatch** — even if context seems small, it prevents redundant work
-2. **Flush on completion** — flow context is temporary; don't let it accumulate across flows
-3. **Profile matters** — a reviewer needs different context than an implementer
-4. **Budget caps prevent bloat** — large context confuses subagents, keep it focused
-5. **Auto-deposit is passive** — it captures tool output automatically, no extra calls needed
+1. **Always withdraw before dispatch**
+2. **Flush on completion**
+3. **Profile matters**
 
 ## Prompt Template Reference
 
-Detailed prompt templates are provided as sidecar files:
-
 | Template | File | Use When |
 |----------|------|----------|
-| Implementer dispatch | [\`implementer-prompt.md\`](implementer-prompt.md) | Dispatching Implementer, Frontend, or Refactor agents |
-| Code review (spec alignment focus) | [\`spec-review-prompt.md\`](spec-review-prompt.md) | Bias one code reviewer toward acceptance criteria, scope, and contract alignment |
-| Code review (quality focus) | [\`code-quality-review-prompt.md\`](code-quality-review-prompt.md) | Bias one or both code reviewers toward maintainability, quality, and security within the same review stage |
-| Architecture review | [\`architecture-review-prompt.md\`](architecture-review-prompt.md) | Boundary changes, pattern adherence review |
-| Parallel dispatch example | [\`parallel-dispatch-example.md\`](parallel-dispatch-example.md) | Worked example of decomposing a feature into parallel tasks |
+| Implementer dispatch | [\`implementer-prompt.md\`](implementer-prompt.md) | Implementer/Frontend/Refactor |
+| Parallel dispatch example | [\`parallel-dispatch-example.md\`](parallel-dispatch-example.md) | Worked example |
 `},{file:`spec-review-prompt.md`,content:`# Spec Alignment Review Prompt Template
 
-Use this template when dispatching a code reviewer who should emphasize spec alignment during the code review stage. This runs as part of code review, not before a separate gate.
+Use when dispatching a code reviewer who should emphasize spec alignment during code review.
 
-**Mindset: "Don't trust the report."** The implementer says it's done — verify independently.
+**Mindset: "Don't trust the report."** Verify independently.
 
 ---
 
@@ -1029,8 +917,8 @@ For EACH acceptance criterion in the task spec:
 
 ## Usage Notes
 
-- Run this during the code review stage — gather this evidence before any conditional architecture/security review and before the FORGE gate
-- Paste the ORIGINAL task spec, not a summary — the reviewer needs exact acceptance criteria
-- If verdict is FAIL, bounce back to implementer with specific gaps before moving to later reviews or the gate
-- PASS_WITH_NOTES can proceed to the remaining reviews, but notes should be tracked
+- Run during code review, before conditional architecture/security review and before FORGE gate
+- Paste original task spec, not summary
+- FAIL → bounce back with specific gaps
+- PASS_WITH_NOTES can proceed, but track notes
 `}];export{e as default};