critique

Critique: Document Pressure Testing

Systematically challenge any document for logic, assumptions, completeness, and blind spots. The goal is to make the document stronger, not to tear it down.

When to Activate

• User says "critique this", "pressure test", "poke holes in this"
• User says "what am I missing?", "devil's advocate"
• User asks for review of a PRD, brief, strategy doc, or proposal
• Proactively after prd skill produces a Full PRD or RFC

Input

Accept any document: PRD, brief, RFC, strategy doc, proposal, pitch, research synthesis, OKRs.

Accept via paste, file path, or workspace reference.

Process

Step 1: Understand Intent

Before critiquing, identify:

1. Document type: PRD, RFC, strategy, proposal, etc.
2. Audience: Who will read this? (engineers, execs, stakeholders, investors)
3. Stage: Early exploration or ready to ship?
4. Stakes: Low-risk experiment or bet-the-company decision?

Calibrate critique intensity to stage and stakes. An early one-pager gets lighter scrutiny than a Full PRD about to be shipped.

Step 2: Evaluate Across 6 Dimensions

Dimension	What to Check
Logic	Does the argument flow? Are conclusions supported by premises? Any circular reasoning?
Assumptions	What is taken for granted? Which assumptions are validated vs hoped?
Evidence	Are claims backed by data, research, or citations? Any [Assumption] tags unresolved?
Completeness	What is missing? Stakeholders not consulted? Edge cases ignored? Risks unaddressed?
Feasibility	Can this actually be built/shipped? Technical constraints? Resource reality?
Alternatives	Were other approaches considered? Is there a simpler solution?

Step 3: Produce Critique

# Critique: {Document Title}

**Reviewed:** {date}
**Document stage:** {early/mid/late}
**Overall assessment:** {Strong / Needs work / Major gaps}

## Strengths
- {What is well done and should be preserved}
- {Strong evidence, clear logic, good scoping}

## Issues

### Critical (blocks shipping)
1. **{Issue title}**
   - **Problem:** {What's wrong}
   - **Evidence:** {Where in the doc}
   - **Suggestion:** {How to fix}

### Important (should fix before finalizing)
2. **{Issue title}**
   - **Problem:** {What's wrong}
   - **Suggestion:** {How to fix}

### Minor (nice to fix)
3. **{Issue title}**
   - **Suggestion:** {Quick fix}

## Missing Perspectives
- {Stakeholder or user group not represented}
- {Technical constraint not addressed}
- {Market reality not considered}

## Unvalidated Assumptions
| # | Assumption | Risk if Wrong | How to Validate |
|---|-----------|---------------|-----------------|
| 1 | {assumption} | {consequence} | {experiment or data source} |

## Questions the Document Should Answer
- {Question that a skeptical reader would ask}
- {Question that an engineer would ask}
- {Question that an exec would ask}

## Recommended Next Steps
1. {Most important fix}
2. {Second priority}
3. {Third priority}