@kinqs/brainrouter-mcp-server 0.3.4

package/skills/agent/doubt-driven-skill/SKILL.md

@@ -0,0 +1,249 @@
+---
+name: doubt-driven-skill
+description: Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production, security-sensitive logic, irreversible operations), or any time a confident output would be cheaper to verify now than to debug later.
+hints: |
+  - Use this skill to challenge assumptions and logic boundaries in non-trivial changes.
+  - Separate the review unit into a distinct ARTIFACT and CONTRACT before testing.
+  - Formulate adversarial reviewer prompts focused on disproving correctness, not validating it.
+  - Limit the doubt review loop to a maximum of 3 cycles to avoid unproductive recursion.
+  - In interactive mode, explicitly offer a cross-model second opinion to the user.
+---
+
+# Doubt-Driven Development
+
+## Overview
+
+A confident answer is not a correct one. Long sessions accumulate context that quietly turns assumptions into "facts" without anyone noticing. Doubt-driven development is the discipline of materializing a fresh-context reviewer — biased to **disprove**, not approve — before any non-trivial output stands.
+
+This is not `/review`. `/review` is a verdict on a finished artifact. This is an in-flight posture: non-trivial decisions get cross-examined while course-correction is still cheap.
+
+## When to Use
+
+A decision is **non-trivial** when at least one of these is true:
+
+- It introduces or modifies branching logic
+- It crosses a module or service boundary
+- It asserts a property the type system or compiler cannot verify (thread safety, idempotence, ordering, invariants)
+- Its correctness depends on context the future reader cannot see
+- Its blast radius is irreversible (production deploy, data migration, public API change)
+
+Apply the skill when:
+
+- About to make an architectural decision under uncertainty
+- About to commit non-trivial code
+- About to claim a non-obvious fact ("this is safe", "this scales", "this matches the spec")
+- Working in code you don't fully understand
+
+**When NOT to use:**
+
+- Mechanical operations (renaming, formatting, file moves)
+- Following a clear, unambiguous user instruction
+- Reading or summarizing existing code
+- One-line changes with obvious correctness
+- Pure tooling operations (running tests, listing files)
+- The user has explicitly asked for speed over verification
+
+If you doubt every keystroke, you ship nothing. The skill applies only to non-trivial decisions as defined above.
+
+## Loading Constraints
+
+This skill is designed for the **main-session orchestrator**, where Step 3 (DOUBT, detailed below) can spawn a fresh-context reviewer.
+
+- **Do NOT add this skill to a persona's `skills:` frontmatter.** A persona that follows Step 3 would spawn another persona — the orchestration anti-pattern explicitly forbidden by `references/orchestration-patterns.md` ("personas do not invoke other personas").
+- **If you find yourself applying this skill from inside a subagent context** (where Claude Code prevents nested subagent spawn): the preferred path is to surface to the user that doubt-driven cannot run nested and let the main session handle it. As a last resort only, a degraded self-questioning fallback exists — rewrite ARTIFACT + CONTRACT as a fresh self-prompt with a hard mental separator from your prior reasoning, and walk Steps 1–5. This is **not fresh-context review** (you carry your own context with you), so flag the result as degraded and prefer escalation whenever the user is reachable.
+
+## The Process
+
+Copy this checklist when applying the skill:
+
+```
+Doubt cycle:
+- [ ] Step 1: CLAIM — wrote the claim + why-it-matters
+- [ ] Step 2: EXTRACT — isolated artifact + contract, stripped reasoning
+- [ ] Step 3: DOUBT — invoked fresh-context reviewer with adversarial prompt
+- [ ] Step 4: RECONCILE — classified every finding against the artifact text
+- [ ] Step 5: STOP — met stop condition (trivial findings, 3 cycles, or user override)
+```
+
+### Step 1: CLAIM — Surface what stands
+
+Name the decision in two or three lines:
+
+```
+CLAIM: "The new caching layer is thread-safe under the
+        read-heavy workload described in the spec."
+WHY THIS MATTERS: a race here corrupts user data and is
+                  hard to detect in QA.
+```
+
+If you can't write the claim that compactly, you have a vibe, not a decision. Surface it before scrutinizing it.
+
+### Step 2: EXTRACT — Smallest reviewable unit
+
+A fresh-context reviewer needs the **artifact** and the **contract**, not the journey.
+
+- Code: the diff or the function — not the whole file
+- Decision: the proposal in 3–5 sentences plus the constraints it has to satisfy
+- Assertion: the claim plus the evidence that supposedly supports it (kept distinct from the Step 1 CLAIM block, which is the orchestrator's hypothesis under scrutiny)
+
+Strip your reasoning. If you hand over conclusions, you'll get back validation of your conclusions. The unit must be small enough that a reviewer can hold it in mind in one read — if it's a 500-line PR, decompose first.
+
+### Step 3: DOUBT — Invoke the fresh-context reviewer
+
+The reviewer's prompt **must be adversarial**. Framing decides the answer.
+
+```
+Adversarial review. Find what is wrong with this artifact.
+Assume the author is overconfident. Look for:
+- Unstated assumptions
+- Edge cases not handled
+- Hidden coupling or shared state
+- Ways the contract could be violated
+- Existing conventions this might break
+- Failure modes under unexpected input
+
+Do NOT validate. Do NOT summarize. Find issues, or state
+explicitly that you cannot find any after thorough examination.
+
+ARTIFACT: <paste artifact>
+CONTRACT: <paste contract>
+```
+
+**Pass ARTIFACT + CONTRACT only. Do NOT pass the CLAIM.** Handing the reviewer your conclusion biases it toward agreement. The reviewer must independently determine whether the artifact satisfies the contract.
+
+In Claude Code, the role-based reviewers in `agents/` start with isolated context by design and are usable here — see `agents/` for the roster and per-domain match.
+
+**The adversarial prompt above takes precedence over the persona's default response shape.** Personas like `code-reviewer` are written to produce balanced verdicts with both strengths and weaknesses; doubt-driven needs issues-only output. Paste the adversarial prompt verbatim into the invocation so it overrides the persona's default. If a persona's response shape can't be overridden cleanly, fall back to a generic subagent with the adversarial prompt.
+
+#### Cross-model escalation
+
+A single-model reviewer shares blind spots with the original author — a colder, different-architecture model catches them. Doubt-driven is already opt-in for non-trivial decisions, so within that scope offering cross-model is part of the skill's value, not optional friction.
+
+**Interactive sessions: always offer. Never silently skip.**
+
+**Step 1: Ask the user**
+
+After the single-model review in Step 3 above, but before RECONCILE, pause and ask:
+
+> *"Single-model review complete. Want a cross-model second opinion? Options: Gemini CLI, Codex CLI, manual external review (you paste it elsewhere), or skip."*
+
+This question is mandatory in every interactive doubt cycle — even on artifacts that feel low-stakes. The user — not the agent — decides whether the cost is worth it. The agent's job is to surface the choice.
+
+**Step 2: If the user picks a CLI — verify, then invoke**
+
+1. Check the tool is in PATH (`which gemini`, `which codex`).
+2. Test it works (`gemini --version` or equivalent) before passing the full prompt — a stale or broken binary may pass `which` but fail on real input.
+3. Confirm the exact invocation with the user, including required flags, auth, and env vars (e.g., API keys). Implementations vary; never assume.
+4. Pass ARTIFACT + CONTRACT + the adversarial prompt **only**. No session context, no CLAIM.
+5. Mind shell escaping. If the artifact contains quotes, `$(...)`, or backticks, prefer stdin (`echo … | gemini`) or a heredoc over inline `-p "…"`. When in doubt, ask the user to confirm the invocation before running it.
+6. Take the output into Step 4 (RECONCILE).
+
+**Never interpolate the artifact into a shell-quoted argument.** Code, markdown, and review prompts routinely contain backticks, `$(...)`, and quote characters that will either truncate the prompt or execute embedded shell. Write the full prompt to a file and pipe it through stdin.
+
+Example shapes (verify flags against your installed tool — syntax differs across implementations and versions):
+
+```bash
+# Write the adversarial prompt + ARTIFACT + CONTRACT to a temp file first.
+# Then pipe via stdin so shell metacharacters in the artifact stay inert.
+
+# Codex (read-only sandbox keeps the CLI from writing to your workspace):
+codex exec --sandbox read-only -C <repo-path> - < /tmp/doubt-prompt.md
+
+# Gemini ('--approval-mode plan' is read-only; '-p ""' triggers non-interactive
+# mode and the prompt is read from stdin):
+gemini --approval-mode plan -p "" < /tmp/doubt-prompt.md
+```
+
+A read-only sandbox is the load-bearing detail: a doubt artifact may itself contain instructions (intentional or accidental prompt injection) that the cross-model CLI would otherwise execute against your workspace.
+
+**Step 3: If the CLI is unavailable or fails**
+
+Surface the failure explicitly. Offer: run it manually, try a different tool, or skip. Do not silently fall back to single-model — the user should know cross-model didn't happen.
+
+**Step 4: If the user skips**
+
+Acknowledge the skip in the output (*"Proceeding with single-model findings only"*) and continue to RECONCILE. Skipping is fine; silent skipping is not.
+
+**Non-interactive contexts** (CI, `/loop`, autonomous-loop, scheduled runs):
+
+- Cross-model is **skipped**, and the skip must be **announced** in the output: *"Cross-model skipped: non-interactive context."*
+- **Never invoke an external CLI without explicit user authorization** — this is a load-bearing safety property.
+
+Cross-model adds cost, latency, and tool fragility. The agent surfaces the choice every cycle; the user decides whether this artifact warrants it.
+
+### Step 4: RECONCILE — Fold findings back
+
+The reviewer's output is data, not verdict. **You are still the orchestrator.** Re-read the artifact text against each finding before classifying — rubber-stamping the reviewer is the same failure mode as ignoring it.
+
+For each finding, classify in this **precedence order** (first matching class wins):
+
+1. **Contract misread** — reviewer flagged something specifically because the CONTRACT you provided was unclear or incomplete. Fix the contract first, re-classify on the next cycle.
+2. **Valid + actionable** — real issue requiring a change to the artifact. Change it, re-loop.
+3. **Valid trade-off** — issue is real but cost of fixing exceeds cost of accepting. Document the trade-off explicitly so the user sees it.
+4. **Noise** — reviewer flagged something that's actually correct under context the reviewer didn't have. Note it, move on, and ask: would adding that context to the contract have prevented the false flag?
+
+A fresh reviewer can be wrong because it lacks context. Don't defer just because it's "fresh."
+
+### Step 5: STOP — Bounded loop, not recursion
+
+Stop when:
+
+- Next iteration returns only trivial or already-considered findings, **or**
+- 3 cycles completed (escalate to user, don't grind a fourth alone), **or**
+- User explicitly says "ship it"
+
+If after 3 cycles the reviewer still surfaces substantive issues, the artifact may not be ready. Surface this to the user — three unresolved cycles is information about the artifact, not a reason to keep looping.
+
+If 3 cycles is "obviously insufficient" because the artifact is large: the artifact is too big — return to Step 2 and decompose. Do not lift the bound.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I'm confident, skip the doubt step" | Confidence correlates poorly with correctness on novel problems. Moments of certainty are exactly when blind spots hide. |
+| "Spawning a reviewer is expensive" | Debugging a wrong commit in production is more expensive. The check is bounded; the bug isn't. |
+| "The reviewer will just nitpick" | Only if unscoped. Constrain the prompt to "issues that would make this fail under the contract." |
+| "I'll do doubt at the end with `/review`" | `/review` is a final gate. Doubt-driven catches wrong directions early when course-correction is cheap. By PR time it's too late. |
+| "If I doubt every step I'll never ship" | The skill applies to non-trivial decisions, not every keystroke. Re-read "When NOT to Use." |
+| "Two opinions are always better than one" | Not when the second has less context and produces noise. Reconcile, don't defer. |
+| "The reviewer disagreed so I was wrong" | The reviewer lacks your context — disagreement is information, not verdict. Re-read the artifact, classify, then decide. |
+| "Cross-model is always better" | Cross-model catches blind spots a single model shares with itself, but it adds cost and tool fragility. Offer it every interactive doubt cycle — the user decides whether the artifact warrants it. The agent's job is to surface the choice, not to gate it. |
+| "User said yes once, so I can keep invoking the CLI" | Each invocation is its own authorization. The artifact, the prompt, and the flags change between calls — re-confirm the exact command with the user before every run. |
+
+## Red Flags
+
+- Spawning a fresh-context reviewer for a one-line rename or formatting change
+- Treating reviewer output as authoritative without re-reading the artifact text
+- Looping >3 cycles without escalating to the user
+- Prompting the reviewer with "is this good?" instead of "find issues"
+- Skipping doubt under time pressure on a high-stakes decision
+- Re-spawning fresh-context on an unchanged artifact (you'll get the same findings; you're stalling)
+- **Doubt theater (checkable signal)**: across 2 or more cycles where the reviewer surfaced substantive findings, zero findings were classified as actionable. You are validating, not doubting. Stop and escalate.
+- Doubting only after committing — that's `/review`, not doubt-driven development
+- Hardcoding an external CLI invocation without confirming with the user that the tool exists, is configured, and accepts that exact syntax
+- **Silently skipping cross-model in an interactive doubt cycle.** Even when not recommending it, the offer must be visible. Skipping is fine; silent skipping is not.
+- Falling back silently when an external CLI errors or is missing — surface the failure and let the user redirect
+- Stripping the contract from the reviewer's input
+- Passing the CLAIM to the reviewer (biases toward agreement)
+
+## Interaction with Other Skills
+
+- **`code-review-and-quality` / `/review`**: complementary. `/review` is post-hoc PR verdict; doubt-driven is in-flight per-decision. Use both.
+- **`source-driven-development`**: SDD verifies *facts about frameworks* against official docs. Doubt-driven verifies *your reasoning about the artifact*. SDD checks the API exists; doubt-driven checks you used it correctly under the contract.
+- **`test-driven-development`**: TDD's RED step is doubt made concrete — a failing test is a disproof attempt. When TDD applies, that failing test *is* the doubt step for behavioral claims.
+- **`debugging-and-error-recovery`**: when the reviewer surfaces a real failure mode, drop into the debugging skill to localize and fix.
+- **Repo orchestration rules** (`references/orchestration-patterns.md`): this skill orchestrates from the main session. A persona calling another persona is anti-pattern B — see Loading Constraints above.
+
+## Verification
+
+After applying doubt-driven development, confirm:
+
+- [ ] Every non-trivial decision (per the definition above) was named explicitly as a CLAIM before standing
+- [ ] At least one fresh-context review per non-trivial artifact (a failing test produced by TDD's RED step satisfies this for behavioral claims, per Interaction with Other Skills)
+- [ ] The reviewer received ARTIFACT + CONTRACT — NOT the CLAIM, NOT your reasoning
+- [ ] The reviewer's prompt was adversarial ("find issues"), not validating ("is it good")
+- [ ] Findings were classified against the artifact text (not rubber-stamped) using the precedence: contract misread / actionable / trade-off / noise
+- [ ] A stop condition was met (trivial findings, 3 cycles, or user override)
+- [ ] In interactive mode, cross-model was **explicitly offered** to the user (regardless of artifact stakes) and the response was acknowledged in the output
+- [ ] In non-interactive mode, cross-model was skipped and the skip was announced
+- [ ] Any external CLI invocation was preceded by a PATH check, a working-binary test, syntax confirmation with the user, and explicit authorization to run

package/skills/agent/handover-skill/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: handover-skill
+description: Summarizes completed work and provides a walkthrough. Use when a project, feature, or task is finished and needs to be reviewed or handed over to a human or another agent.
+hints: |
+  - Always verify that all tests pass and lint checks are green before initiating a handover.
+  - Create or update the walkthrough.md artifact to detail structural changes and decisions.
+  - Ensure every key change is explained in terms of product behavior, not just raw file diffs.
+  - Document all verification results with exact commands run and observable outcomes.
+  - Clearly flag any remaining technical debt or future enhancement work.
+---
+
+# Project Handover and Walkthrough
+
+## Overview
+
+A good handover ensures that the work you've done is understandable, verifiable, and maintainable. The walkthrough is the final "sales pitch" and "instruction manual" for your changes. It should explain what was done, why it was done that way, and how the human can verify the results.
+
+## When to Use
+
+- You have completed all tasks in the implementation plan.
+- You are finishing a session and want to leave a clear state for the next one.
+- You need a human to review and sign off on a significant change.
+- You want to document the technical decisions made during implementation.
+
+## The Handover Process
+
+### Step 1: Final Verification
+
+Before writing the walkthrough, confirm that everything works as expected:
+- Run the full test suite.
+- Perform manual verification of the main user flows.
+- Ensure the code follows project conventions and linting rules.
+- Check that all tasks in `task.md` are marked as completed.
+
+### Step 2: Create the Walkthrough File
+
+Create a `walkthrough.md` file in the project root. This is your primary artifact for the handover.
+
+### Step 3: Summarize Key Changes
+
+Don't just list files. Explain the *logic* of the changes.
+- What were the main architectural decisions?
+- What new components or modules were added?
+- Were there any significant refactors?
+
+### Step 4: Evidence of Success
+
+Provide proof that the work is correct.
+- Include test results (e.g., "15 tests passed, 0 failed").
+- If applicable, include screenshots or recordings (if the tool supports it).
+- Link to relevant documentation or updated files.
+
+## Walkthrough Template
+
+```markdown
+# Walkthrough: [Feature/Project Name]
+
+## Overview
+[A brief summary of what was accomplished and why.]
+
+## Key Changes
+[Bullet points of the most important changes, grouped logically.]
+
+- **Core Logic**: Description of changes to business logic.
+- **UI/UX**: Description of changes to the interface.
+- **Infrastructure**: Changes to databases, APIs, or configuration.
+
+## Technical Decisions
+[Explain any non-obvious choices made during implementation.]
+
+- **Decision 1**: Rationale and trade-offs.
+- **Decision 2**: Rationale and trade-offs.
+
+## Verification Results
+
+### Automated Tests
+- [ ] Unit tests pass: `npm test`
+- [ ] Integration tests pass: `npm run test:integration`
+- [ ] Coverage: 95% line coverage on new modules.
+
+### Manual Verification
+1. [Step 1 of manual check]
+2. [Step 2 of manual check]
+- [ ] Results: [Description of observed behavior]
+
+## Future Work / Remaining Debt
+- [ ] [Unsolved edge case]
+- [ ] [Performance optimization for later]
+- [ ] [Feature extension ideas]
+
+## Sign-off
+- [ ] Ready for production
+- [ ] Human review required for [specific area]
+```
+
+## Red Flags
+
+- Creating a walkthrough before finishing all tasks.
+- Listing file changes without explaining the "why."
+- No verification results included.
+- Leaving `task.md` with uncompleted items.
+- Vague summaries like "Implemented the feature."
+
+## Verification
+
+Before finalizing the handover, confirm:
+- [ ] `walkthrough.md` is saved in the repository artifacts directory or project root.
+- [ ] All verification steps have been run, tested, and documented.
+- [ ] Non-obvious technical decisions and architectural changes are clearly explained.
+- [ ] `task.md` has been updated to reflect the final state.
+- [ ] Any "Future Work," "Remaining Debt," or "Known Issues" are noted.
+- [ ] All temporary scratch files, debug logs, and unfinished code blocks have been cleaned up.

package/skills/agent/idea-refine-skill/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: idea-refine-skill
+description: Refines raw ideas into sharp, actionable concepts through structured divergent and convergent thinking. Use when an idea is still vague, when you need to stress-test assumptions before committing to a plan, or when you want to expand options before converging on one.
+hints: |
+  - Anchor the ideation around a crisp "How Might We" problem statement.
+  - Ask 3-5 high-leverage sharpening questions to define the target user and success metrics.
+  - Generate 5-8 distinct idea variations using inversion, constraint removal, or 10x scale lenses.
+  - Explicitly stress-test directions against user value, feasibility, and differentiation.
+  - Produce a structured one-pager specifying MVP scope and a strict "Not Doing" list.
+---
+
+# Idea Refine
+
+## Overview
+
+Refines raw ideas into sharp, actionable concepts worth building through structured divergent and convergent thinking.
+
+## Workflow
+
+1.  **Understand & Expand (Divergent):** Restate the idea, ask sharpening questions, and generate variations.
+2.  **Evaluate & Converge:** Cluster ideas, stress-test them, and surface hidden assumptions.
+3.  **Sharpen & Ship:** Produce a concrete markdown one-pager moving work forward.
+
+## Usage
+
+This skill is primarily an interactive dialogue. Invoke it with an idea, and the agent will guide you through the process.
+
+```bash
+# Optional: Initialize the ideas directory
+mkdir -p ideas
+```
+
+**Trigger Phrases:**
+- "Help me refine this idea"
+- "Ideate on [concept]"
+- "Stress-test my plan"
+
+## Output
+
+The final output is a markdown one-pager saved to `ideas/[idea-name].md` (after user confirmation), containing:
+- Problem Statement
+- Recommended Direction
+- Key Assumptions
+- MVP Scope
+- Not Doing list
+
+## Detailed Instructions
+
+You are an ideation partner. Your job is to help refine raw ideas into sharp, actionable concepts worth building.
+
+### Philosophy
+
+- Simplicity is the ultimate sophistication. Push toward the simplest version that still solves the real problem.
+- Start with the user experience, work backwards to technology.
+- Say no to 1,000 things. Focus beats breadth.
+- Challenge every assumption. "How it's usually done" is not a reason.
+- Show people the future — don't just give them better horses.
+- The parts you can't see should be as beautiful as the parts you can.
+
+### Process
+
+When the user invokes this skill with an idea (`$ARGUMENTS`), guide them through three phases. Adapt your approach based on what they say — this is a conversation, not a template.
+
+#### Phase 1: Understand & Expand (Divergent)
+
+**Goal:** Take the raw idea and open it up.
+
+1. **Restate the idea** as a crisp "How Might We" problem statement. This forces clarity on what's actually being solved.
+
+2. **Ask 3-5 sharpening questions** — no more. Focus on:
+   - Who is this for, specifically?
+   - What does success look like?
+   - What are the real constraints (time, tech, resources)?
+   - What's been tried before?
+   - Why now?
+
+   Use the `AskUserQuestion` tool to gather this input. Do NOT proceed until you understand who this is for and what success looks like.
+
+3. **Generate 5-8 idea variations** using these lenses:
+   - **Inversion:** "What if we did the opposite?"
+   - **Constraint removal:** "What if budget/time/tech weren't factors?"
+   - **Audience shift:** "What if this were for [different user]?"
+   - **Combination:** "What if we merged this with [adjacent idea]?"
+   - **Simplification:** "What's the version that's 10x simpler?"
+   - **10x version:** "What would this look like at massive scale?"
+   - **Expert lens:** "What would [domain] experts find obvious that outsiders wouldn't?"
+
+   Push beyond what the user initially asked for. Create products people don't know they need yet.
+
+**If running inside a codebase:** Use `Glob`, `Grep`, and `Read` to scan for relevant context — existing architecture, patterns, constraints, prior art. Ground your variations in what actually exists. Reference specific files and patterns when relevant.
+
+Read `frameworks.md` in this skill directory for additional ideation frameworks you can draw from. Use them selectively — pick the lens that fits the idea, don't run every framework mechanically.
+
+#### Phase 2: Evaluate & Converge
+
+After the user reacts to Phase 1 (indicates which ideas resonate, pushes back, adds context), shift to convergent mode:
+
+1. **Cluster** the ideas that resonated into 2-3 distinct directions. Each direction should feel meaningfully different, not just variations on a theme.
+
+2. **Stress-test** each direction against three criteria:
+   - **User value:** Who benefits and how much? Is this a painkiller or a vitamin?
+   - **Feasibility:** What's the technical and resource cost? What's the hardest part?
+   - **Differentiation:** What makes this genuinely different? Would someone switch from their current solution?
+
+   Read `refinement-criteria.md` in this skill directory for the full evaluation rubric.
+
+3. **Surface hidden assumptions.** For each direction, explicitly name:
+   - What you're betting is true (but haven't validated)
+   - What could kill this idea
+   - What you're choosing to ignore (and why that's okay for now)
+
+   This is where most ideation fails. Don't skip it.
+
+**Be honest, not supportive.** If an idea is weak, say so with kindness. A good ideation partner is not a yes-machine. Push back on complexity, question real value, and point out when the emperor has no clothes.
+
+#### Phase 3: Sharpen & Ship
+
+Produce a concrete artifact — a markdown one-pager that moves work forward:
+
+```markdown
+# [Idea Name]
+
+## Problem Statement
+[One-sentence "How Might We" framing]
+
+## Recommended Direction
+[The chosen direction and why — 2-3 paragraphs max]
+
+## Key Assumptions to Validate
+- [ ] [Assumption 1 — how to test it]
+- [ ] [Assumption 2 — how to test it]
+- [ ] [Assumption 3 — how to test it]
+
+## MVP Scope
+[The minimum version that tests the core assumption. What's in, what's out.]
+
+## Not Doing (and Why)
+- [Thing 1] — [reason]
+- [Thing 2] — [reason]
+- [Thing 3] — [reason]
+
+## Open Questions
+- [Question that needs answering before building]
+```
+
+**The "Not Doing" list is arguably the most valuable part.** Focus is about saying no to good ideas. Make the trade-offs explicit.
+
+Ask the user if they'd like to save this to `ideas/[idea-name].md` (or a location of their choosing). Only save if they confirm.
+
+### Anti-patterns to Avoid
+
+- **Don't generate 20+ ideas.** Quality over quantity. 5-8 well-considered variations beat 20 shallow ones.
+- **Don't be a yes-machine.** Push back on weak ideas with specificity and kindness.
+- **Don't skip "who is this for."** Every good idea starts with a person and their problem.
+- **Don't produce a plan without surfacing assumptions.** Untested assumptions are the #1 killer of good ideas.
+- **Don't over-engineer the process.** Three phases, each doing one thing well. Resist adding steps.
+- **Don't just list ideas — tell a story.** Each variation should have a reason it exists, not just be a bullet point.
+- **Don't ignore the codebase.** If you're in a project, the existing architecture is a constraint and an opportunity. Use it.
+
+### Tone
+
+Direct, thoughtful, slightly provocative. You're a sharp thinking partner, not a facilitator reading from a script. Channel the energy of "that's interesting, but what if..." -- always pushing one step further without being exhausting.
+
+Read `examples.md` in this skill directory for examples of what great ideation sessions look like.
+
+## Red Flags
+
+- Generating 20+ shallow variations instead of 5-8 considered ones
+- Skipping the "who is this for" question
+- No assumptions surfaced before committing to a direction
+- Yes-machining weak ideas instead of pushing back with specificity
+- Producing a plan without a "Not Doing" list
+- Ignoring existing codebase constraints when ideating inside a project
+- Jumping straight to Phase 3 output without running Phases 1 and 2
+
+## Verification
+
+After completing an ideation session, confirm:
+- [ ] A clear "How Might We" problem statement exists.
+- [ ] The target user and success criteria are defined.
+- [ ] Multiple directions were explored, not just the first idea.
+- [ ] Hidden assumptions are explicitly listed with validation strategies.
+- [ ] A "Not Doing" list makes trade-offs explicit.
+- [ ] The output is a concrete artifact (markdown one-pager), not just conversation.
+- [ ] The user confirmed the final direction before any implementation work.