@vpxa/aikit 0.1.186 → 0.1.188

package/scaffold/dist/definitions/skills/brainstorming.mjs

@@ -1,6 +1,6 @@
 var e=[{file:`SKILL.md`,content:`---
 name: brainstorming
-description: "Design exploration for planning-phase agents (Orchestrator, Planner, Researchers). Explores user intent, requirements and design BEFORE handing off to implementation agents. NOT for code agents — they implement designs, not create them."
+description: "Design exploration for planning-phase agents (Orchestrator, Planner, Researchers). Explores user intent, requirements and design BEFORE handing off to implementation agents. Use when there are multiple valid approaches to a problem, when architecture decisions need exploration, when the user says 'how should I...', 'what's the best way to...', 'explore options for...', or when a task has genuine design forks. NOT for code agents - they implement designs, not create them. NOT for single-path decisions - if only one approach makes sense, skip this."
 metadata:
   category: planning
   domain: general
@@ -16,35 +16,40 @@ argument-hint: "Feature, component, or behavior to design"
 
 ## Quick Reference
 
-**Purpose:** Explore user intent, requirements, and design BEFORE any implementation. Mandatory for creative work.
+**Purpose:** Explore requirements and design space before implementation starts.
 
-**HARD GATE:** Do NOT write any code until design is presented and user approves. No exceptions, even for "simple" tasks.
+**Use this skill when:** there are multiple viable approaches, architecture trade-offs matter, or the user is asking for guidance rather than code.
 
-**Two modes** (you decide, don't ask user):
-- **Simple Mode** - <=3 files, single concern, no new boundaries -> brief context + 3-5 targeted questions + short design summary
-- **Full Mode** - multi-file, new services, cross-cutting concerns -> deep context gathering + structured design document + explicit approval
+**Skip this skill when:** the work is already decided, the change is mechanical, or only one reasonable path exists.
 
-**Process:** Understand context -> Ask questions (one at a time) -> Present design -> Get user approval -> Hand off to implementation
+**HARD GATE:** Do NOT write code, scaffold files, or hand off to implementation until a design is presented and approved.
 
-**Output:** Design document with: goal, scope, approach, file changes, edge cases, and acceptance criteria.
-
-Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
-
-Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
+**Expected output:** a short design or spec with constraints, alternatives, recommendation, risks, and acceptance criteria.
 
 <HARD-GATE>
 Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
 </HARD-GATE>
 
-## Anti-Pattern: "This Is Too Simple To Need A Design"
+## When Brainstorming Is Appropriate
+
+Use brainstorming when at least one of these is true:
 
-Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
+- Multiple valid approaches exist and the choice changes cost, risk, or UX
+- The work introduces or changes boundaries: service, module, API, workflow, ownership
+- The user is asking for options, strategy, trade-offs, or "best way" guidance
+- Constraints are real but incomplete: performance, timeline, migration cost, reversibility, team familiarity
+
+Do not use brainstorming when the path is already obvious:
+
+- Fixing a typo, renaming a variable, or updating a pinned dependency
+- Implementing an already-approved spec or ADR
+- Mechanical migrations where the desired end state is predetermined
 
 ---
 
 ## Mode Selection
 
-This skill operates in two modes. **You decide which mode to use** based on the task characteristics — do NOT ask the user which mode.
+This skill operates in two modes. You choose the mode from the problem shape; do not ask the user which mode they want.
 
 ### Simple Mode
 
@@ -57,7 +62,7 @@ Use when **all** of these are true:
 
 Examples: config change, utility function, bug fix with design ambiguity, small feature in existing component.
 
-### Advanced Mode
+### Full Mode
 
 Use when **any** of these are true:
 - Affects >3 files or crosses service boundaries
@@ -71,269 +76,129 @@ Examples: new notification channel, new API service, platform redesign, multi-se
 
 ---
 
-## Simple Mode Process
-
-### Checklist
-
-1. **Explore project context** — check files, docs, recent commits
-2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
-3. **Propose 2-3 approaches** — with trade-offs and your recommendation
-4. **Present design** — in sections scaled to their complexity, get user approval after each section
-5. **Write design doc** — save to \`docs/plans/YYYY-MM-DD-<topic>-design.md\` and commit
-6. **Transition to implementation** — invoke writing-plans skill to create implementation plan
-
-### Process Flow
-
-\`\`\`dot
-digraph brainstorming_simple {
-    "Explore project context" [shape=box];
-    "Ask clarifying questions" [shape=box];
-    "Propose 2-3 approaches" [shape=box];
-    "Present design sections" [shape=box];
-    "User approves design?" [shape=diamond];
-    "Write design doc" [shape=box];
-    "Invoke writing-plans skill" [shape=doublecircle];
-
-    "Explore project context" -> "Ask clarifying questions";
-    "Ask clarifying questions" -> "Propose 2-3 approaches";
-    "Propose 2-3 approaches" -> "Present design sections";
-    "Present design sections" -> "User approves design?";
-    "User approves design?" -> "Present design sections" [label="no, revise"];
-    "User approves design?" -> "Write design doc" [label="yes"];
-    "Write design doc" -> "Invoke writing-plans skill";
-}
-\`\`\`
-
----
-
-## Advanced Mode Process
-
-### Checklist
-
-1. **Explore project context** — check files, docs, recent commits
-2. **Assess scope** — if multiple independent subsystems, decompose before detailing (see below)
-3. **Offer visual presentation support** (if topic will involve visual questions) — this is its own message, not combined with a clarifying question. Use \`present({ schemaVersion: 1, title: "Brainstorming", blocks: [...] })\` to display brainstorming results. Use \`list\` for idea sets, \`table\` for evaluation matrices, \`kv\` for the selected approach, and \`metrics\` for requirement scores. NEVER \`code\` blocks for structured data.
-4. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
-5. **Propose 2-3 approaches via Decision Protocol** — run the full 3-phase multi-model decision protocol: Phase 1 (4 Researchers in parallel), Phase 2 (peer review with anonymized outputs), Phase 3 (structured verdict). Present the verdict visually using \`present({ schemaVersion: 1, title: "Approach Verdict", blocks: [...] })\` with \`table\` for approach comparisons, \`list\` for recommendations, and \`kv\` for verdict metadata. NEVER \`code\` blocks for structured data. *(See "Decision Protocol Integration" below.)*
-6. **Present design** — in sections scaled to their complexity, get user approval after each section
-7. **Write design doc** — save to \`docs/plans/YYYY-MM-DD-<topic>-design.md\` and commit
-8. **Spec review loop** — review the spec for completeness, consistency, clarity, scope, and YAGNI. Fix issues. Max 3 iterations, then surface to user.
-9. **User reviews written spec** — ask user to review the spec file before proceeding
-10. **Transition to implementation** — invoke writing-plans skill to create implementation plan
-
-### Decision Protocol Integration (Advanced Mode Only)
-
-When Advanced Mode reaches step 5 ("Propose approaches"), invoke the **full 3-phase multi-model decision protocol**:
-
-**Phase 1 — Independent Research:**
-1. Frame the design question with full context gathered from steps 1-4
-2. Launch ALL 4 Researcher variants **in parallel** with identical framing — each applies its thinking style:
-   - **Alpha (Contrarian)**: Actively seeks flaws and fatal assumptions
-   - **Beta (First Principles)**: Strips assumptions, rebuilds from ground truth
-   - **Gamma (Expansionist)**: Finds undervalued opportunities, cross-domain patterns
-   - **Delta (Executor)**: Focuses on fastest path, implementation cost, feasibility
-
-**Phase 2 — Peer Review:**
-3. **Anonymize** Phase 1 outputs as Perspective A / B / C / D (strip agent names)
-4. Launch a **second parallel batch** of 4 reviewers, each evaluating ALL perspectives:
-   - Strongest argument — which perspective and why?
-   - Critical blind spot — what did the strongest miss?
-   - Consensus gap — what did ALL overlook?
-   - Verdict — which approach to adopt?
-
-**Phase 3 — Structured Verdict:**
-5. Synthesize BOTH layers into the structured verdict format:
-   - **Where Agrees** / **Where Clashes** / **Blind Spots Caught** / **Recommendation** (with confidence) / **First Step**
-6. Present verdict visually using \`present({ schemaVersion: 1, title: "Approach Verdict", blocks: [...] })\` with \`table\` for approach comparisons, \`list\` for recommendations, and \`kv\` for verdict metadata. NEVER \`code\` blocks for structured data.
-7. If a decision produces an ADR, write it to \`docs/decisions/\`
-
-**Floor-tier shortcut**: Skip Phase 2 (peer review), synthesize directly from Phase 1.
-
-This replaces the single-agent "propose approaches" step with 8 independent evaluations (4 research + 4 review), producing significantly higher-quality decisions.
-
-### Process Flow
-
-\`\`\`dot
-digraph brainstorming_advanced {
-    "Explore project context" [shape=box];
-    "Assess scope" [shape=diamond];
-    "Decompose into sub-projects" [shape=box];
-    "Visual questions ahead?" [shape=diamond];
-    "Offer Visual Presentation\\n(own message)" [shape=box];
-    "Ask clarifying questions" [shape=box];
-    "Phase 1: 4 Researchers\\nin parallel" [shape=box, style=bold];
-    "Phase 2: Peer Review\\n(anonymized, 4 reviewers)" [shape=box, style=bold];
-    "Phase 3: Structured Verdict" [shape=box];
-    "Present design sections" [shape=box];
-    "User approves design?" [shape=diamond];
-    "Write design doc" [shape=box];
-    "Spec review loop" [shape=box];
-    "Spec review passed?" [shape=diamond];
-    "User reviews spec?" [shape=diamond];
-    "Invoke writing-plans skill" [shape=doublecircle];
-
-    "Explore project context" -> "Assess scope";
-    "Assess scope" -> "Decompose into sub-projects" [label="too large"];
-    "Assess scope" -> "Visual questions ahead?" [label="right-sized"];
-    "Decompose into sub-projects" -> "Visual questions ahead?" [label="first sub-project"];
-    "Visual questions ahead?" -> "Offer Visual Presentation\\n(own message)" [label="yes"];
-    "Visual questions ahead?" -> "Ask clarifying questions" [label="no"];
-    "Offer Visual Presentation\\n(own message)" -> "Ask clarifying questions";
-    "Ask clarifying questions" -> "Phase 1: 4 Researchers\\nin parallel";
-    "Phase 1: 4 Researchers\\nin parallel" -> "Phase 2: Peer Review\\n(anonymized, 4 reviewers)";
-    "Phase 2: Peer Review\\n(anonymized, 4 reviewers)" -> "Phase 3: Structured Verdict";
-    "Phase 3: Structured Verdict" -> "Present design sections";
-    "Present design sections" -> "User approves design?";
-    "User approves design?" -> "Present design sections" [label="no, revise"];
-    "User approves design?" -> "Write design doc" [label="yes"];
-    "Write design doc" -> "Spec review loop";
-    "Spec review loop" -> "Spec review passed?";
-    "Spec review passed?" -> "Spec review loop" [label="issues found, fix"];
-    "Spec review passed?" -> "User reviews spec?" [label="approved"];
-    "User reviews spec?" -> "Write design doc" [label="changes requested"];
-    "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
-}
-\`\`\`
-
-### Large Project Decomposition
-
-Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
-
-If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own spec → plan → implementation cycle.
-
-### Spec Review Loop
-
-After writing the spec document, review it yourself for:
-
-| Category | What to Look For |
-|----------|------------------|
-| Completeness | TODOs, placeholders, "TBD", incomplete sections |
-| Consistency | Internal contradictions, conflicting requirements |
-| Clarity | Requirements ambiguous enough to cause someone to build the wrong thing |
-| Scope | Focused enough for a single plan — not covering multiple independent subsystems |
-| YAGNI | Unrequested features, over-engineering |
+## NEVER
 
-**Only flag issues that would cause real problems during implementation planning.** A missing section, a contradiction, or a requirement so ambiguous it could be interpreted two different ways — those are issues. Minor wording improvements and stylistic preferences are not.
+- **NEVER skip divergent thinking to jump to solutions** - premature convergence is the most common brainstorming failure. Force at least 3 alternatives before evaluating.
+- **NEVER present options without trade-off analysis** - listing A/B/C without pros, cons, and context is noise. Each option needs: strength, weakness, best-when.
+- **NEVER conflate requirements with design** - "the user wants to log in" is a requirement; "use OAuth2 + JWT" is a design. Clarify the problem before exploring the solution space.
+- **NEVER evaluate during the divergent phase** - "that won't work" too early kills useful exploration. Generate first, judge second.
+- **NEVER propose more than 5 options** - too many options create analysis paralysis. 3-5 well-differentiated choices is enough.
+- **NEVER present the obvious choice as the only real option with strawman alternatives** - if one option clearly dominates before analysis, say brainstorming is unnecessary and recommend directly.
+- **NEVER use brainstorming for single-path decisions** - if there is only one credible path, execute or hand off; do not manufacture fake alternatives.
+- **NEVER hide the deciding constraint** - if compliance, migration cost, latency, or org ownership is driving the decision, state it explicitly.
 
-Fix issues and re-review. Max 3 iterations, then surface remaining concerns to the user.
+## Core Workflow
 
-### User Review Gate
+| Stage | What you do | What good output looks like |
+|-------|-------------|-----------------------------|
+| Frame | State the problem, constraints, and success criteria | Clear decision question and explicit boundaries |
+| Clarify | Ask one question at a time until ambiguity drops | Requirements are separate from solutions |
+| Diverge | Generate 3 alternatives that differ in shape, not just labels | Options have meaningfully different trade-offs |
+| Evaluate | Compare options against criteria, constraints, reversibility, and delivery cost | Rejection reasons are explicit |
+| Recommend | Pick one option and explain why the others lost | Recommendation matches the stated constraints |
+| Confirm | Present the design, get approval, then hand off | Implementation can proceed without reopening core design questions |
 
-After the spec review passes, ask the user to review:
-
-> "Spec written and committed to \`<path>\`. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."
-
-Wait for the user's response. If they request changes, make them and re-run the spec review. Only proceed once the user approves.
+Simple Mode compresses the workflow into a short design note. Full Mode produces a fuller spec and spends more time on constraints, interfaces, migration, and rollout.
 
 ---
 
-## The Process (Both Modes)
-
-**Understanding the idea:**
-- Check out the current project state first (files, docs, recent commits)
-- Ask questions one at a time to refine the idea
-- Prefer multiple choice questions when possible, but open-ended is fine too
-- Only one question per message — if a topic needs more exploration, break it into multiple questions
-- Focus on understanding: purpose, constraints, success criteria
+## Decision Protocol
 
-**Exploring approaches:**
-- Propose 2-3 different approaches with trade-offs
-- Present options conversationally with your recommendation and reasoning
-- Lead with your recommended option and explain why
+Use the heaviest process the problem actually needs. The protocol scales with decision complexity; it does not assume a giant agent swarm.
 
-**Presenting the design:**
-- Once you believe you understand what you're building, present the design
-- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
-- Ask after each section whether it looks right so far
-- Cover: architecture, components, data flow, error handling, testing
-- Be ready to go back and clarify if something doesn't make sense
+### Multi-Researcher Mode
 
-**Design for isolation and clarity** (Advanced mode emphasis, but good practice always):
-- Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently
-- For each unit, you should be able to answer: what does it do, how do you use it, and what does it depend on?
-- Can someone understand what a unit does without reading its internals? Can you change the internals without breaking consumers? If not, the boundaries need work.
+Use this when the decision is high-impact and the Orchestrator can actually dispatch multiple research passes.
 
-**Working in existing codebases:**
-- Explore the current structure before proposing changes. Follow existing patterns.
-- Where existing code has problems that affect the work (e.g., a file that's grown too large, unclear boundaries, tangled responsibilities), include targeted improvements as part of the design — the way a good developer improves code they're working in.
-- Don't propose unrelated refactoring. Stay focused on what serves the current goal.
+1. **Independent passes** - gather 2-4 perspectives if available. More is optional, not mandatory.
+2. **Cross-check blind spots** - compare where the perspectives agree, clash, and what each missed.
+3. **Structured verdict** - produce one recommendation with confidence, deciding constraints, rejected alternatives, and first implementation step.
 
-## After the Design
+Do not block waiting for an 8-agent protocol. If capacity is limited, reduce the number of perspectives and keep the structure.
 
-**Documentation:**
-- Write the validated design to \`docs/plans/YYYY-MM-DD-<topic>-design.md\`
-  - (User preferences for spec location override this default)
-- Use elements-of-style:writing-clearly-and-concisely skill if available
-- Commit the design document to git
+### Single-Agent Fallback
 
-**Implementation:**
-- Invoke the writing-plans skill to create a detailed implementation plan
-- Do NOT invoke any other skill. writing-plans is the next step.
+When running as a single agent (no Orchestrator dispatching multi-model research), use this structured approach:
 
-**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.
+1. **Frame the decision space** - state the question, list constraints, define success criteria
+2. **Generate 3 alternatives** - force diversity by thinking from different lenses:
+  - Lens A: Simplest approach (minimum viable, least risk)
+  - Lens B: Best long-term approach (might be more work now, pays off later)
+  - Lens C: Unconventional approach (different framing, different trade-off)
+3. **Evaluate against criteria** - for each alternative, score against the stated success criteria
+4. **Recommend with rationale** - pick one, explain WHY, acknowledge what you're trading away
 
-## Key Principles
+This replaces the full Multi-Model Decision Protocol when running solo.
 
-- **One question at a time** — Don't overwhelm with multiple questions
-- **Multiple choice preferred** — Easier to answer than open-ended when possible
-- **YAGNI ruthlessly** — Remove unnecessary features from all designs
-- **Explore alternatives** — Always propose 2-3 approaches before settling
-- **Incremental validation** — Present design, get approval before moving on
-- **Be flexible** — Go back and clarify when something doesn't make sense
+### Verdict Format
 
-## Challenge Discipline
+Express the result in structured text, not diagrams:
 
-Every design MUST be stress-tested before presentation. Apply these checks:
+| Section | Required content |
+|---------|------------------|
+| Decision | What question is being answered |
+| Constraints | What limited the design space |
+| Options | 3 alternatives with strength, weakness, best-when |
+| Recommendation | Chosen option and why |
+| Rejections | Why the other options lost |
+| Risks | What could fail and how reversible it is |
+| First Step | Smallest useful next move after approval |
 
-### 1. Domain Model Cross-Reference
-
-Before presenting any design, \`search\` curated knowledge for existing glossary, domain models, and naming conventions. The design must use **canonical terms** from the codebase — not synonyms, not approximations.
+### Large Project Decomposition
 
-- If the design introduces a new term, justify why no existing term works
-- If fuzzy language exists ("handle the thing", "process the data"), sharpen it to precise domain terms
-- Cross-reference proposed interfaces against existing code: do the names, shapes, and flows match what's already there?
+Before asking detailed questions, assess scope. If the request includes multiple independent subsystems, decompose first. Do not brainstorm the whole platform as one blob.
 
-### 2. Contradiction Detection
+If the project is too large for a single spec, break it into sub-projects, define the order, then brainstorm the first sub-project only.
 
-Search the codebase for existing implementations that touch the same domain:
+## Design Quality Signals
 
-- Does the proposed data flow contradict existing patterns?
-- Do proposed error handling strategies conflict with established conventions?
-- Are there implicit assumptions that contradict documented decisions?
+- **Options are genuinely different** - if they only differ in naming, you have not explored the space.
+- **Trade-offs are real** - if one option dominates on all dimensions, the others are strawmen.
+- **Constraints are explicit** - "we chose X because of Y constraint" is good; "X is better" is lazy.
+- **Reversibility is assessed** - one-way doors need more analysis than two-way doors.
+- **You can explain why NOT the other options** - if you cannot articulate the rejection reason, the analysis is shallow.
 
-If contradictions exist, surface them explicitly: "This design proposes X, but the existing code does Y in [file]. Which should win?"
+## Design Review Checklist
 
-### 3. Specification Precision
+Before presenting the design, verify these quality bars:
 
-Before finalizing each design section, apply this test:
+- **Completeness** - no TODOs, placeholders, or missing constraints that block planning.
+- **Consistency** - sections do not contradict each other.
+- **Precision** - two competent developers would implement compatible solutions from this spec.
+- **Scope control** - the design solves the asked problem and avoids unrequested extras.
+- **Canonical language** - names and domain terms match the codebase or are explicitly introduced.
 
-> "Could two competent developers independently implement this section and produce compatible results?"
+Fix serious issues before handoff. Minor wording changes are advisory, not blockers.
 
-If no — the spec is too vague. Add:
-- Concrete examples (input → output)
-- Boundary conditions (what happens at 0, 1, MAX?)
-- Error cases (what fails, what's the recovery?)
+## Working Method
 
-### 4. Living Documentation
+- Check current project context before proposing changes.
+- Ask one question per message when clarification is needed.
+- Prefer multiple-choice questions when they reduce ambiguity faster.
+- Separate divergent generation from evaluation.
+- Lead with your recommendation once the option space is explored.
+- Stay concrete: boundaries, interfaces, data flow, failure modes, rollout.
 
-During the brainstorming session, when design decisions clarify existing ambiguity:
-- Note which existing docs/comments are now outdated
-- Include documentation updates as part of the design output (not a separate "docs task")
-- The design doc itself becomes the canonical reference — don't create knowledge that lives only in chat
+## Output Contract
 
-## Visual Presentation Support (Advanced Mode Only)
+For Simple Mode, produce a concise design note with:
 
-Use the \`present\` MCP tool for showing mockups, diagrams, and visual options during brainstorming. It is available as a tool, not a separate mode. Choosing this means you can present rich visual output when it helps; it does NOT mean every question should become visual.
+- Goal
+- Constraints
+- 3 options
+- Recommendation
+- Risks and acceptance criteria
 
-**Offering visual presentation:** When you anticipate that upcoming questions will involve visual content (mockups, layouts, diagrams), offer it once for consent:
-> "Some of what we're working on might be easier to explain visually. I can use \`present({ schemaVersion: 1, title: \\"Working Session Visuals\\", blocks: [...] })\` to show mockups, diagrams, comparisons, and other visuals as we go, using \`list\`, \`table\`, \`kv\`, and \`metrics\` blocks as appropriate. I never use \`code\` blocks for structured data. Want me to use that when helpful?"
+For Full Mode, produce a spec that also covers:
 
-**This offer MUST be its own message.** Do not combine it with clarifying questions, context summaries, or any other content. Wait for the user's response before continuing. If they decline, proceed with text-only brainstorming.
+- Boundaries and component responsibilities
+- Interfaces and data flow
+- Migration or rollout strategy
+- Error handling and operational risks
+- Test and acceptance strategy
 
-**Per-question decision:** Even after the user accepts, decide FOR EACH QUESTION whether to use visual output or plain chat. The test: **would the user understand this better by seeing it than reading it?**
+When useful, save the approved design to \`docs/plans/YYYY-MM-DD-<topic>-design.md\` before handing off to implementation planning.
 
-- **Use \`present({ schemaVersion: 1, title: "Visual Option", blocks: [...] })\`** for visual content — mockups, wireframes, layout comparisons, architecture diagrams, side-by-side visual designs. Use \`list\` for idea options, \`table\` for side-by-side evaluations, \`kv\` for selected approach metadata, and \`metrics\` for numeric scoring. NEVER \`code\` blocks for structured data.
-- **Use regular chat** for text content — requirements questions, conceptual choices, tradeoff lists, A/B/C/D text options, scope decisions
 `},{file:`spec-document-reviewer-prompt.md`,content:`# Spec Document Reviewer Prompt Template
 
 Use this template when dispatching a spec document reviewer subagent.