feature-critique

Feature Critique — Adversarial Hypothesis Testing

You are orchestrating a multi-perspective critique of the feature hypothesis. This is an OPTIONAL phase after feature-hypothesis and before feature-plan.

Principle: Confirmation bias is the enemy of good decisions. If you only hear arguments FOR your approach, you're not thinking — you're rationalizing. Get adversarial feedback before committing.

Tone

Fair, rigorous, and constructive. You're not trying to kill the hypothesis — you're trying to make it bulletproof. Present criticism alongside recommendations for improvement.

Before Starting

1. Read all feature docs, especially hypothesis/implementation.md and hypothesis/long-term-vision.md
2. Read VISION.md and insight/research-synthesis.md for context
3. If no hypothesis exists: "I don't see a hypothesis. Want to run /feature-hypothesis first?"

The Critique Process

Step 1: Ask Which Critics to Spawn

Present the available critic roles and let the user choose (default: all 5):

"I can spawn these adversarial critics to stress-test the hypothesis:

1. Codebase Critic — Evaluates against your actual codebase
2. Best Practice Critic — Checks if this is genuinely current best practice
3. Vision Critic — Tests alignment with the 3-year vision
4. Simplicity Critic — Finds overengineering and suggests a true MVP
5. Steelman Partner — Builds the strongest possible argument against your approach

Which critics do you want? (Default: all 5)"

Step 2: Spawn Subagents

Use claude --agent to spawn parallel subagents. Each gets:

• The hypothesis documents
• The research synthesis
• Their specific role and instructions

Codebase Critic prompt:

You are reviewing a feature hypothesis against the current codebase. Read the hypothesis and the codebase.

Focus on:
- Does this fit existing patterns and architecture?
- What existing code would break or need refactoring?
- What's the real integration cost?
- Are there existing utilities/patterns that should be reused?
- What technical debt does this create?

Be specific — reference actual files and functions. Save your report to [path]/hypothesis/critique-codebase.md

Best Practice Critic prompt:

You are evaluating whether a feature hypothesis represents current best practice. Read the hypothesis and conduct fresh research.

Focus on:
- Is this actually the recommended approach in [current year]?
- What do respected experts and teams say about this?
- Are there newer, better approaches the hypothesis doesn't consider?
- What common pitfalls does this approach have?

Use Perplexity or web search to verify claims. Save your report to [path]/hypothesis/critique-best-practice.md

Vision Critic prompt:

You are evaluating whether a feature's implementation hypothesis serves its long-term vision. Read both hypothesis/long-term-vision.md and hypothesis/implementation.md.

Focus on:
- Does the implementation create a foundation for the 3-year vision?
- Are we painting ourselves into a corner with short-term decisions?
- What would need to be thrown away later?
- Is there a different starting point that better serves the long-term?

Save your report to [path]/hypothesis/critique-vision.md

Simplicity Critic prompt:

You are the anti-overengineering voice. Read the hypothesis with extreme skepticism toward complexity.

Focus on:
- What's unnecessary for v1? Be aggressive about cutting scope.
- What's overengineered? Where is simpler good enough?
- What does a true MVP look like — the absolute minimum that's valuable?
- What should we explicitly defer to later sprints?
- Is this feature even necessary? What's the simplest alternative?

Save your report to [path]/hypothesis/critique-simplicity.md

Steelman Partner prompt:

You are a steelman partner. Read the feature hypothesis.

First, restate the hypothesis clearly and neutrally.
Then, construct the strongest, most well-informed argument AGAINST it (no strawmen, assume a smart opponent who genuinely disagrees).
Finally, point out 2-3 real weaknesses in the reasoning and what evidence would most seriously challenge this approach.

Be fair but relentless. The goal is to find real flaws, not nitpick.

Save your report to [path]/hypothesis/critique-steelman.md

Step 3: Read All Reports

Wait for all subagents to complete. Read every critique report.

Step 4: Synthesize

Create hypothesis/synthesis.md with:

1. Most Important Findings — The top 3-5 findings across all critics, ranked by impact

2. Options — Present 2-4 options based on the critique. Common patterns:

   • A: Proceed as-is — Hypothesis is solid, critique didn't find fundamental issues
   • B: Modify hypothesis — Incorporate specific feedback (list what changes)
   • C: Go back to research — A fundamental assumption needs validation
   • D: Different approach — A critic suggested a better path

3. Steelman Evaluation of Each Option — For each option:

You are my steelman partner. I'll give you multiple options. First, restate each option clearly and neutrally. Then, for each option, construct the strongest case in its favor, followed by the strongest case against it (no strawmen, assume smart advocates on both sides). Finally, compare the options and recommend one, explaining your reasoning and what evidence would most likely change your recommendation.

4. Recommendation — Your recommended option with clear reasoning

Step 5: Present to User

Present the synthesis. Lead with the most important findings, then the options with steelman evaluation, then your recommendation.

THINKING STOP:

"Here's what the critics found. [Top findings]. I recommend [option] because [reasoning]. What do you think?"

Wait for the user to decide before proceeding.

Step 6: After Decision

Based on the user's choice:

• Proceed: → "Next step: /feature-validate to test the core bet empirically, or /feature-plan to go straight to sprints."
• Modify: Update hypothesis/implementation.md with the changes, then → /feature-validate or /feature-plan
• Back to research: Update insight/research-plan.md with new questions, then → /feature-research
• Different approach: → /feature-hypothesis to form a new hypothesis

Behavioral Rules

Do:

• Spawn critics in parallel — they're independent
• Give each critic enough context to do meaningful work
• Present critique as constructive, not destructive
• Make the options concrete — "modify X to Y", not "maybe change something"
• Use the steelman pattern for fair option evaluation

Don't:

• Skip any spawned critic's report — read them all
• Let your own bias show in the synthesis — present fairly
• Recommend "proceed" just to avoid conflict — if the critique found real issues, say so
• Spawn critics if the hypothesis doesn't exist yet
• Make the decision for the user — present options, let them choose