var e=[{file:`architecture-review-prompt.md`,content:`# Architecture Review Prompt Template

Use when dispatching **Architect-Reviewer-Alpha** and **Architect-Reviewer-Beta** for boundary, pattern, infra, or public API changes.

---

## Prompt Template

\`\`\`markdown
You are performing an architecture review. Focus on structural decisions, not code quality (that's handled separately).

## Change Summary
[What was changed and why — high-level description]

## Files Changed
[List of files with module/boundary information]

## Architectural Context
[Paste relevant architecture docs, module graph, dependency structure from compact/digest]

---

## Review Dimensions

### 1. Boundary Integrity
- Do changes respect existing module boundaries?
- Are there new cross-module dependencies that shouldn't exist?
- Is the dependency direction correct (inner → outer, not reverse)?

### 2. Pattern Adherence
- Do new components follow established architectural patterns?
- Are there deviations from the documented architecture?
- If a new pattern is introduced, is it justified and documented?

### 3. Coupling & Cohesion
- Are new dependencies minimal and well-justified?
- Could any coupling be reduced with interfaces or inversion?
- Are related concerns grouped together?

### 4. Scalability Impact
- Will this change create bottlenecks under load?
- Are there single points of failure introduced?
- Does this work with horizontal scaling?

### 5. Migration & Evolution
- Does this change make future changes harder?
- Are there implicit assumptions that will break?
- Is the change reversible if needed?

### 6. API Surface
- Are new public APIs minimal and well-designed?
- Could any public surface be internal instead?
- Are breaking changes flagged?

---

## Output Format

### Verdict: [APPROVE | APPROVE_WITH_NOTES | REQUEST_CHANGES]

**APPROVE** — Architecture is sound.
**APPROVE_WITH_NOTES** — Acceptable, but track these concerns.
**REQUEST_CHANGES** — Structural issues that must be resolved.

### Findings:
| # | Dimension | Severity | Description | Impact |
|---|-----------|----------|-------------|--------|
| 1 | [Dimension] | [Blocker/Concern/Note] | [Issue] | [What breaks/degrades] |

### Recommendation:
[Structural guidance for improvement]
\`\`\`

---

## Usage Notes

- 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 when dispatching **Code-Reviewer-Alpha** and **Code-Reviewer-Beta** for dual code review. Same prompt; different models catch different issues.

Runs in code review stage. Gather evidence first; FORGE gate runs after code review and any conditional reviews.

---

## Prompt Template

\`\`\`markdown
You are performing a code review. Your job is to evaluate HOW the implementation works while cross-checking that it still matches what was requested.

## Task Context
[Brief description of what was implemented and why]

## Files Changed
[List of files with a one-line description of changes in each]

## Code Diff
[Paste the actual code changes — full diff or new file contents]

---

## Review Dimensions

### 1. Readability & Maintainability
- Are names clear and intention-revealing?
- Is the code self-documenting or does it need comments?
- Is complexity managed (small functions, single responsibility)?
- Would a new team member understand this in 5 minutes?

### 2. Pattern Adherence
- Does the code follow the project's established patterns?
- Are there inconsistencies with surrounding code?
- Are there framework idioms being violated?

### 3. Error Handling & Edge Cases
- Are errors handled at appropriate boundaries?
- Are edge cases considered (null, empty, overflow, concurrent access)?
- Are error messages helpful for debugging?

### 4. Performance
- Any obvious N+1 queries or unnecessary iterations?
- Any blocking operations that should be async?
- Any missing caching opportunities or unnecessary allocations?

### 5. Security
- Input validation present for external data?
- No secrets in code?
- No injection vulnerabilities (SQL, XSS, command)?
- Proper authorization checks?

### 6. Spec Alignment (Cross-Check)
- Does the implementation match what was requested?
- Any over-engineering beyond requirements?
- Any subtle deviations from the intended behavior?

### 7. Testability
- Is the code testable in isolation?
- Are dependencies injectable?
- Are there missing test cases?

---

## Output Format

### Verdict: [APPROVE | APPROVE_WITH_SUGGESTIONS | REQUEST_CHANGES]

**APPROVE** — Code is production-ready.
**APPROVE_WITH_SUGGESTIONS** — Good to merge, but consider these improvements.
**REQUEST_CHANGES** — Must fix before proceeding. List blocking issues.

### Findings:
| # | Dimension | Severity | Description | Location | Suggestion |
|---|-----------|----------|-------------|----------|------------|
| 1 | [Dimension] | [Blocker/Major/Minor/Nit] | [Issue] | [file:line] | [Fix] |

### Summary:
[2-3 sentence overall assessment]
\`\`\`

---

## Usage Notes

- 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 when dispatching **Implementer**, **Frontend**, or **Refactor**. Provide all needed context; subagent should not search beyond scope.

---

## Prompt Template

\`\`\`markdown
You are implementing a focused task. All context you need is provided below. Do NOT search for additional files or read the full plan — work only within the scope defined here.

## 1. Scope
**Files to create/modify:**
- [exact/path/to/file1.ts] — [create | modify]
- [exact/path/to/file2.ts] — [create | modify]

**Boundary — do NOT touch:**
- [files/that/are/off/limits.ts]
- [other/agents/territory/]

## 2. Goal
[Clear description of what the code should do]

**Acceptance criteria:**
- [ ] [Specific, testable criterion 1]
- [ ] [Specific, testable criterion 2]
- [ ] [Specific, testable criterion 3]

## 3. Architectural Context
[Relevant code snippets, patterns, conventions from compact/digest — paste actual code, don't reference files]

Example existing pattern:
\\\`\\\`\\\`typescript
// From services/auth.service.ts — follow this pattern
export class AuthService {
  constructor(private readonly repo: AuthRepository) {}
  async validate(token: string): Promise<User> { ... }
}
\\\`\\\`\\\`

## 4. Constraints
- Follow [specific pattern/convention]
- Use [specific library/approach]
- Do NOT [specific anti-pattern to avoid]
- [Any other boundaries]

## 5. FORGE Context
**Tier:** [Floor | Standard | Critical]
**Evidence requirements:** [What evidence to collect — test results, type coverage, etc.]

## 6. Self-Review Checklist
Before declaring your status, verify ALL:
- [ ] All acceptance criteria from §2 are met
- [ ] No files outside §1 scope were modified
- [ ] Code follows conventions from §3 and constraints from §4
- [ ] Tests pass (run them if possible)
- [ ] No TODO/FIXME/HACK left without justification
- [ ] No hardcoded values that should be configurable

---

**STATUS PROTOCOL — End your response with EXACTLY ONE:**

### DONE
All tasks complete. Self-review checklist passed. Ready for review.

### DONE_WITH_CONCERNS
All tasks complete, but I have concerns:
- [Concern 1: description + suggested resolution]
- [Concern 2: description + suggested resolution]

### NEEDS_CONTEXT
Cannot proceed without the following:
- [Specific question or missing information]

### BLOCKED
Hit a wall and cannot proceed:
- [Description of blocker]
- [What I tried]
- [Suggestion for resolution]
\`\`\`

---

## Usage Notes

- 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

Shows parallel feature decomposition and review flow.

---

## Scenario: Add User Notification Preferences

**User request:** "Add a notification preferences page where users can toggle email, push, and in-app notifications per category (marketing, security, product updates)."

---

## Step 1: Scope Map & Decomposition

Orchestrator runs \`scope_map({ task: "notification preferences" })\`:
Backend API + DB → Implementer. Frontend page → Frontend. Tests → Implementer.

## Step 2: Independence Check (5-Question Checklist)

Different files, no shared mutable state, no execution-order dependency. Shared type contract first.

**Decision: PARALLEL**

## Step 3: Shared Context Prep

Before dispatching, Orchestrator creates shared contract:

\`\`\`typescript
// Type contract — paste into BOTH agent prompts
interface NotificationPrefs {
  userId: string;
  categories: {
    marketing: { email: boolean; push: boolean; inApp: boolean };
    security: { email: boolean; push: boolean; inApp: boolean };
    product: { email: boolean; push: boolean; inApp: boolean };
  };
  updatedAt: Date;
}

// API contract
// GET  /api/notifications/preferences → NotificationPrefs
// PUT  /api/notifications/preferences → NotificationPrefs (body: Partial<NotificationPrefs['categories']>)
\`\`\`

## Step 4: Parallel Dispatch

### Dispatch A → Implementer (Backend + DB + Tests)

\`\`\`markdown
You are implementing a focused task. All context below.

## 1. Scope
- services/notification-prefs.service.ts — create
- routes/notification-prefs.route.ts — create
- migrations/add-notification-prefs.ts — create
- models/notification-prefs.model.ts — create
- __tests__/notification-prefs.test.ts — create

## 2. Goal
Create backend API for notification preferences CRUD.
- GET endpoint returns current prefs (default all-true for new users)
- PUT endpoint updates partial categories
- Migration creates notification_preferences table

## 3. Architectural Context
[Paste existing service pattern from compact()]
[Paste existing route pattern from compact()]
[Paste existing migration pattern from compact()]
[Paste the shared type contract above]

## 4. Constraints
- Follow existing repository pattern (see §3)
- Use Zod for request validation
- Include unit tests for service layer

## 5. FORGE Context
Tier: Standard. Evidence: test pass, type coverage.

## 6. Self-Review Checklist
[standard checklist]

STATUS PROTOCOL: DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED
\`\`\`

### Dispatch B → Frontend (UI Page + Components)

\`\`\`markdown
You are implementing a focused task. All context below.

## 1. Scope
- pages/settings/notifications.tsx — create
- components/NotificationToggle.tsx — create

## 2. Goal
Create notification preferences settings page.
- Grid layout: rows = categories, columns = channels
- Toggle switches for each cell
- Auto-save on toggle (optimistic update with rollback)
- Loading skeleton on initial fetch

## 3. Architectural Context
[Paste existing settings page pattern from compact()]
[Paste existing toggle component from compact()]
[Paste the shared type contract + API contract above]

## 4. Constraints
- Use existing Toggle component from design system
- Follow settings page layout pattern
- Mobile responsive (stack columns on small screens)
- Mock API response for now: GET returns all-true defaults

## 5. FORGE Context
Tier: Floor. Evidence: renders without error.

## 6. Self-Review Checklist
[standard checklist]

STATUS PROTOCOL: DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED
\`\`\`

## Step 5: Review Pipeline

Both agents return DONE. Orchestrator reviews:

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

Present review findings and gate result before commit or merge.

---

## Key Takeaways

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."
metadata:
  category: cross-cutting
  domain: general
  applicability: always
  inputs: [plan, codebase]
  outputs: [task-decomposition, dispatch-templates]
  requires: [aikit]
  relatedSkills: [session-handoff]
---

# Multi-Agent Development

Patterns for parallel multi-agent work: decomposition, dispatch, context, status, review, recovery.

**Core Principle**: Dispatch focused agents with fresh context and explicit scope.

---

## §1 Agent Roles & Model Selection

### Role Categories

| Role | Agents | When to Use | Parallelizable |
|------|--------|-------------|----------------|
| **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

| Complexity Signal | Model Tier | Example Agents |
|-------------------|-----------|----------------|
| Mechanical (rename, move, add field) | Fast model | Explorer |
| Standard (implement spec, write tests) | Mid-tier | Implementer/Refactor |

**Upgrade signal**: \`BLOCKED\` or \`DONE_WITH_CONCERNS\` on Standard task → re-dispatch to stronger model.

---

## §2 Task Decomposition Rules

### The Golden Rule
> **One task = one focused problem domain = 1-3 files maximum.**

### Decomposition Checklist

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 |
|-----------|-------|---------|-------|
| **Standard** | 2-3 files | Service + controller + test | Implementer |

### Splitting Strategies
- **By layer**: Service + UI + tests

---

## §3 Independence Decision 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 same file)
│   ├─ YES → SEQUENTIAL (or merge into one task)
│   └─ NO ↓
│
├─ Do they share mutable state? (env vars, globals, same DB table, shared config)
│   ├─ YES → SEQUENTIAL
│   └─ NO ↓
│
├─ Does B need A's output? (B reads file A creates, B uses A's new export)
│   ├─ YES → SEQUENTIAL (A before B)
│   └─ NO ↓
│
├─ Would A's result change B's approach? (A discovers something that affects B)
│   ├─ YES → SEQUENTIAL or single agent
│   └─ NO ↓
│
├─ Resource contention? (same port, same build process, same lock file)
│   ├─ YES → SEQUENTIAL
│   └─ NO ↓
│
└─ ✅ SAFE TO PARALLELIZE
\`\`\`

### Edge Cases

| Situation | Verdict | Why |
|-----------|---------|-----|
| Same shared import only | ✅ Parallel | Read-only |
| Same index/package file | ❌ Sequential | Shared edit |

### Integration Verification (after parallel batch completes)

1. **Conflict check**: unexpected overlap?
2. **Import check**: cross-references resolve?
3. **Full suite**: \`check({})\` + \`test_run({})\`

---

## §4 Parallel Dispatch Patterns

### Dispatch Rules

1. **Max 4 concurrent file-modifying agents** per batch
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

\`\`\`
Phase Plan:
  Phase 1: [Task A, Task B, Task C]  ← no dependencies between A/B/C
  Phase 2: [Task D, Task E]          ← D depends on A, E depends on B
  Phase 3: [Task F]                  ← F depends on D and E

Execution:
  Batch 1: dispatch(A, B, C) in parallel → review → gate
  Batch 2: dispatch(D, E) in parallel → review → gate
  Batch 3: dispatch(F) → review → gate
\`\`\`

### Anti-Patterns

| ❌ Don't | ✅ Do Instead |
|----------|--------------|
| 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 search for it.**

Fresh prompt only. No inherited session state.

### The 6-Point Prompt Template

Every delegation prompt MUST include:

\`\`\`markdown
## 1. Scope
Files to create/modify: [exact paths]
Files to NOT touch: [boundaries]

## 2. Goal
[What the code should do — acceptance criteria, testable outcomes]

## 3. Architectural Context
[Relevant patterns, conventions, existing code structure]
[Include actual code snippets from compact/digest — don't tell agent to "go read X"]

## 4. Constraints
- Follow [pattern/convention]
- Do NOT modify [boundary files]
- Use [specific library/approach]

## 5. FORGE Context
Tier: [Floor/Standard/Critical]
Evidence requirements: [what evidence to collect]

## 6. Self-Review & Status
Before declaring DONE, verify:
- [ ] All acceptance criteria met
- [ ] No files outside scope modified
- [ ] Tests pass (if applicable)
- [ ] Code follows stated conventions

End with status: DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
\`\`\`

### What to Include vs Omit

| ✅ Include | ❌ Omit |
|-----------|---------|
| Exact file paths and snippets | Full session history |

### Context Size Budget

| Task Complexity | Context Target | Approach |
|-----------------|---------------|----------|
| Standard (2-3 files) | ~2000 tokens | \`digest\` + architecture |

---

## §6 Subagent Execution Cycle

### Lifecycle

\`\`\`
Orchestrator                          Subagent (fresh instance)
    │                                      │
    ├─ Craft focused prompt ──────────────►│
    │  (6-point template)                  │
    │                                      ├─ Understand scope
    │                                      ├─ Implement changes
    │                                      ├─ Self-review (checklist)
    │◄─────────────────── Return status ───┤
    │                                      │ (DONE/CONCERNS/NEEDS/BLOCKED)
    │                                      │
    ├─ Handle status (see §7)              ×  (subagent terminates)
    │
    ├─ Automated gate (check/test_run)
    │
    ├─ Dispatch reviewers (see §8)
    │
    └─ FORGE evidence_map gate
\`\`\`

### Key Rules

1. **One subagent = one task**
2. **Controller provides context**
3. **Status is mandatory**

---

## §7 Implementer Status Protocol

### Status Codes

Every implementer (Implementer, Frontend, Refactor) MUST end response with exactly ONE:

| Status | Meaning | Orchestrator Action |
|--------|---------|-------------------|
| **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

\`\`\`
Agent returned BLOCKED
│
├─ Missing context? (needs info not in prompt)
│   → Provide context, re-dispatch
│
├─ Wrong model? (task too complex for assigned model)
│   → Re-dispatch to stronger model (e.g., Implementer → Debugger)
│
├─ Scope too broad? (agent overwhelmed)
│   → Split task further, re-dispatch smaller pieces
│
├─ Plan wrong? (implementation approach won't work)
│   → Re-plan this phase, check AI Kit for alternatives
│
└─ External blocker? (dependency not ready, API unavailable)
    → Park task, proceed with independent work, revisit later
\`\`\`

### FORGE Composition

- **Status** = agent telemetry
- **FORGE** = evidence-based quality gate

\`\`\`
DONE               → proceed to code review → conditional architecture/security review → FORGE evidence_map → present results
DONE_WITH_CONCERNS → concerns become 'Assumed' claims → reviewers validate them → evidence_map likely HOLDs
NEEDS_CONTEXT      → provide context, re-dispatch (no FORGE yet)
BLOCKED            → diagnose:
                      contract/security issue → HARD_BLOCK
                      resource/scope issue → re-plan, no FORGE
\`\`\`

**Critical rule**: Every \`DONE\` must complete code review and any conditional architecture/security review BEFORE \`evidence_map({ action: "gate" })\`.

---

## §8 Review Pipeline

### Ordered Review Pipeline

\`\`\`
Stage 1: Implementer Self-Review (embedded in agent output)
  └─ Checklist: scope respected, tests pass, conventions followed
      │
Stage 2: Dual Code Review (parallel)
  ├─ Code-Reviewer-Alpha (GPT-5.4): code quality + Spec Alignment
  └─ Code-Reviewer-Beta (Opus 4.6): code quality + Spec Alignment
      │ Both review same code, different model perspectives
      │ Spec Alignment = "Does this match what was asked?"
      │
Stage 3: Architecture Review (conditional)
  └─ Trigger only for boundary changes, new modules, or pattern shifts
      │
Stage 4: Security Review (conditional)
  └─ Trigger for auth, crypto, input handling, or external data
      │
Stage 5: FORGE Gate — evidence_map({ action: "gate" })
  └─ YIELD → stop and present results
  └─ HOLD → address flagged items → re-gate (**Max 2 retries** per task)
  └─ HARD_BLOCK → escalate to user
\`\`\`

Use \`check({})\` + \`test_run({})\` for reviewer evidence; not gate.

### Spec Alignment Dimension (for Code Reviewers)

Check acceptance criteria, over-build, under-build, and expected file set.

### When to Skip Stages

| Stage | Skip When |
|-------|-----------|
| Architecture Review | No new modules/boundary changes/patterns |

---

## §9 Recovery & Escalation

### Retry Policy

**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**
2. Recheck approach
3. Change agent, model, decomposition, or escalate

### Emergency Procedures

When parallel batch causes cascading failures:

\`\`\`
STOP    → Halt all running agents immediately
ASSESS  → git diff --stat + check({}) — how bad is it?
CONTAIN → Limited (1-3 files): fix or re-delegate
           Widespread (10+ files): git stash to preserve for analysis
RECOVER → Partial: git checkout -- {specific files}
           Full: git stash (preserves) or git checkout . (discards)
           Nuclear: git reset --hard HEAD (last resort)
DOCUMENT → remember what went wrong, update plan
\`\`\`

### Scope Tripwires

| Signal | Action |
|--------|--------|
| 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 |

---

## §10 Common Mistakes & Red Flags

### Delegation Anti-Patterns

| ❌ Mistake | Why It Fails | ✅ Fix |
|-----------|-------------|--------|
| **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 |
|------|--------------|--------|
| Files outside scope | Scope creep | Roll back, re-delegate tighter |

---

## §11 Flow Context Sharing

### Flow Context Broker

The \`knowledge\` tool supports flow-scoped context sharing.

**How it works:** auto-deposit captures tool output, Orchestrator calls \`withdraw\`, subagents can deposit findings, \`flush\` clears flow context.

### Orchestrator Workflow

#### Before Dispatching a Subagent

\`\`\`
// Get role-filtered context for the subagent
knowledge({ action: 'withdraw', profile: '<role>', budget: 6000 })
// Profiles: implementer, documenter, reviewer, researcher, debugger
\`\`\`

Paste withdrawn context into "## 3. Architectural Context" from §5.

#### After All Work Completes

\`\`\`
// Clean up flow context on flow completion
knowledge({ action: 'flush' })
\`\`\`

### Subagent Deposit Pattern

\`\`\`
// Subagent deposits a finding for future agents
knowledge({ action: 'remember', scope: 'flow', title: 'API validation pattern', content: '...' })
\`\`\`

### Profile Filtering

Use \`implementer\` profile for Implementer/Frontend/Refactor tasks.

### Budget Management

\`budget\` caps returned context. Standard implementation: 6000.

### Integration with 6-Point Template

Update the prompt template from §5 to include flow context:

\`\`\`markdown
## 3. Architectural Context
[Paste the result of knowledge({ action: 'withdraw', profile: '<role>' })]
[Supplement with additional compact/digest if the withdrawn context is insufficient]
\`\`\`

### Key Rules

1. **Always withdraw before dispatch**
2. **Flush on completion**
3. **Profile matters**

## Prompt Template Reference

| Template | File | Use When |
|----------|------|----------|
| 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 when dispatching a code reviewer who should emphasize spec alignment during code review.

**Mindset: "Don't trust the report."** Verify independently.

---

## Prompt Template

\`\`\`markdown
You are performing an adversarial spec alignment review. Your job is to verify that the implementation matches what was requested — nothing more, nothing less.

**Do NOT trust the implementer's self-assessment.** Verify independently.

## Task Specification
[Paste the original task that was dispatched to the implementer — including all acceptance criteria]

## Implementation Output
[Paste the implementer's response — code changes, self-review, status]

## Files Changed
[List of files modified with brief description of changes]

---

## Review Dimensions

### 1. Acceptance Criteria Match
For EACH acceptance criterion in the task spec:
- [ ] **Met** / **Not Met** / **Partially Met**
- Evidence: [specific code or test that proves it]

### 2. Over-Build Detection
- Are there features, functions, or abstractions NOT requested in the spec?
- Are there unnecessary generalizations?
- Were files modified outside the stated scope?
→ Flag each over-build with: what was added, why it shouldn't be there

### 3. Under-Build Detection
- Are any acceptance criteria unaddressed?
- Are there edge cases implied by the spec but not handled?
- Are there missing tests for stated requirements?
→ Flag each under-build with: what's missing, what should exist

### 4. Scope Compliance
- List every file modified — does it match the scope in the original task?
- Were any out-of-scope files touched? (this is a red flag)

### 5. Contract Adherence
- Do new exports/interfaces match what other components expect?
- Are function signatures compatible with existing callers?
- Will this break anything downstream?

---

## Output Format

### Verdict: [PASS | PASS_WITH_NOTES | FAIL]

**PASS** — Implementation matches spec completely.
**PASS_WITH_NOTES** — Matches spec but has minor concerns that don't block.
**FAIL** — Implementation does not match spec. List specific gaps.

### Findings:
| # | Type | Severity | Description | Location |
|---|------|----------|-------------|----------|
| 1 | [Over/Under/Scope/Contract] | [Critical/Major/Minor] | [Description] | [file:line] |

### Recommendation:
[What needs to change before this passes spec review]
\`\`\`

---

## Usage Notes

- 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};