Self-Critique

---

name: self-critique description: Improve output quality through structured self-review before finalizing. Based on Constitutional AI and self-reflection research, this skill creates a feedback loop where you critique your own work against quality criteria, identify issues, and revise. Use for any output where quality matters—code, writing, analysis, decisions. Critical for catching errors, improving clarity, and ensuring completeness before shipping.

---

Self-Critique - Quality Through Reflection

Self-Critique implements structured self-review workflows inspired by Constitutional AI and self-reflection research.

The core insight: Outputs improve significantly when you pause, review against criteria, and revise—especially your own work.

The Analogy: Code Review (With Yourself)

| No Review | Self-Critique | |-----------|---------------| | Ship immediately | Pause and review | | Miss obvious issues | Catch your own mistakes | | Learn from failures later | Improve before shipping | | Variable quality | Consistently higher quality |

When to Use Self-Critique

Perfect for:

📝 Important writing (emails, docs, proposals)

💻 Code before commit (especially complex changes)

📊 Analysis and reports (where accuracy matters)

🎨 Design decisions (review trade-offs)

🤔 Any output with consequences (can't easily undo)

Skip for:

⚡ Drafts or quick notes (speed > quality)

🎯 Obvious answers ("What is 2+2?")

🔄 Pure exploration (brainstorming)

The Workflow

Step 1: Generate Initial Output

Create your first draft without self-censoring:

TASK: "Write project proposal for new feature"
[Generate complete first draft]

> ⚠️ Don't self-edit while generating. Get ideas out first.

Step 2: Switch to Critique Mode

Mentally switch roles. You are now the reviewer, not the creator:

ROLE CHANGE: I am now a critical reviewer examining this proposal.
CRITERIA FOR REVIEW:
[ ] Clear objective stated upfront
[ ] Problem well-defined
[ ] Solution described in detail
[ ] Scope clearly bounded
[ ] Timeline realistic
[ ] Risks identified
[ ] Success metrics defined
[ ] Stakeholders addressed
[ ] No typos or unclear language
[ ] Appropriate tone for audience

Step 3: Structured Critique

Review systematically against criteria. For each criterion:

CRITERION: "Clear objective stated upfront"
FINDING: ✓ PASS
First paragraph states: "Build X to solve Y"
Objective is specific and measurable
CRITERION: "Timeline realistic"
FINDING: ✗ FAIL
Proposes 2 weeks for database migration
Historical data: similar migrations took 6-8 weeks
Missing time for testing and rollback
SEVERITY: High (project will fail if timeline is wrong)
SUGGESTED FIX:
Revise timeline to 8 weeks
Include phases: migration (4w), testing (2w), buffer (2w)
Add milestone check-ins

Step 4: Aggregate Findings

Summarize all issues found:

CRITIQUE SUMMARY:
CRITICAL (Must fix before shipping):
1. Timeline unrealistic (8 weeks needed, not 2)
2. Missing risk: dependency on external team
MODERATE (Should fix):
3. Security section too vague—needs specific controls
4. No mention of monitoring plan
MINOR (Nice to have):
5. Typo in paragraph 3: "recieve" → "receive"
6. Could add diagram for architecture
POSITIVE (Keep doing):
✓ Clear problem statement
✓ Good stakeholder analysis
✓ Strong success metrics
OVERALL ASSESSMENT: Needs revision before submission
CONFIDENCE: High (clear issues identified)

Step 5: Revise

Address findings systematically:

REVISIONS:
[R1] Fix timeline (Critical #1)
Change: "2 weeks" → "8 weeks with phases"
Add: Detailed phase breakdown
Add: Milestone checkpoints
[R2] Add external dependency risk (Critical #2)
Add section: "External Dependencies"
Document: Team X API needed, contact established
Mitigation: Early integration testing
[R3] Expand security section (Moderate #3)
Add: Specific encryption requirements
Add: Access control details
Reference: Company security standards
[Continue for all findings...]

Step 6: Second-Pass Critique (Optional)

For critical work, critique again:

SECOND CRITIQUE (lighter):
Did revisions address issues? ✓
Any new problems introduced? ✗ (none found)
Ready to ship? ✓

Step 7: Final Output

Ship the revised version:

FINAL OUTPUT: [Revised proposal with all fixes applied]
QUALITY SCORE: 9/10 (up from 6/10)
REVISIONS MADE: 8
TIME SPENT ON CRITIQUE: 15 minutes
CONFIDENCE: High

Critique Frameworks by Domain

For Code

CODE REVIEW CRITERIA:
FUNCTIONALITY:
[ ] Does what it claims to do
[ ] Handles edge cases
[ ] Error handling complete
[ ] No obvious bugs
SECURITY:
[ ] Input validated
[ ] No injection vulnerabilities
[ ] Secrets not hardcoded
[ ] Principle of least privilege
PERFORMANCE:
[ ] No N+1 queries
[ ] Algorithm appropriate for scale
[ ] No unnecessary computation
[ ] Memory usage reasonable
MAINTAINABILITY:
[ ] Clear variable names
[ ] Functions are focused
[ ] Comments explain why, not what
[ ] Follows project conventions
TESTING:
[ ] Tests cover happy path
[ ] Tests cover error cases
[ ] Edge cases tested
[ ] Tests are readable
DOCUMENTATION:
[ ] Complex logic explained
[ ] API documented
[ ] Breaking changes noted

For Writing

WRITING REVIEW CRITERIA:
CLARITY:
[ ] Main point obvious in first 2 sentences
[ ] Each paragraph has one clear idea
[ ] No ambiguous pronouns
[ ] Technical terms defined
COMPLETENESS:
[ ] Answers reader's likely questions
[ ] Context provided
[ ] Next steps clear (if applicable)
[ ] Nothing assumed unstated
AUDIENCE:
[ ] Tone appropriate
[ ] Detail level matches audience
[ ] Jargon minimized or explained
[ ] Format appropriate
CORRECTNESS:
[ ] Facts checked
[ ] Numbers add up
[ ] Links work
[ ] No typos/grammar errors
IMPACT:
[ ] Opening grabs attention
[ ] Closing reinforces message
[ ] Call to action clear (if needed)
[ ] Length appropriate

For Analysis

ANALYSIS REVIEW CRITERIA:
DATA QUALITY:
[ ] Source credible
[ ] Sample size appropriate
[ ] Time period relevant
[ ] No obvious data errors
METHODOLOGY:
[ ] Approach sound
[ ] Assumptions stated
[ ] Limitations acknowledged
[ ] Alternative explanations considered
CONCLUSIONS:
[ ] Supported by evidence
[ ] Not overstated
[ ] Confidence level appropriate
[ ] Uncertainty quantified
VISUALIZATION:
[ ] Charts clear and honest
[ ] Axes labeled
[ ] No misleading scaling
[ ] Title explains takeaway
ACTIONABILITY:
[ ] Recommendations specific
[ ] Trade-offs explained
[ ] Implementation considerations noted
[ ] Next steps clear

For Decisions

DECISION REVIEW CRITERIA:
PROBLEM DEFINITION:
[ ] Actual problem identified (not symptoms)
[ ] Success criteria defined
[ ] Constraints listed
[ ] Stakeholders identified
OPTIONS CONSIDERED:
[ ] Multiple alternatives explored
[ ] No obvious option missed
[ ] Trade-offs clear
[ ] Each option evaluated against criteria
BIAS CHECK:
[ ] Confirmation bias countered
[ ] Sunk cost fallacy avoided
[ ] Status quo bias questioned
[ ] Groupthink avoided (if applicable)
RISKS:
[ ] Downsides of chosen option clear
[ ] Mitigation plans exist
[ ] Rollback possible if needed
[ ] Worst-case scenario acceptable
COMMUNICATION:
[ ] Rationale explainable
[ ] Dissenting views addressed
[ ] Decision documented
[ ] Review process defined

Severity Levels

When critiquing, classify each finding:

| Severity | Action | Example | |----------|--------|---------| | CRITICAL | Must fix before shipping | Security vulnerability, factual error | | MODERATE | Should fix if time permits | Missing documentation, unclear explanation | | MINOR | Nice to have | Typos, formatting, optional improvements | | POSITIVE | Keep doing | Good patterns worth reinforcing |

Common Critique Patterns

Pattern 1: The Fresh Eyes

Wait 10 minutes between generating and critiquing:

1. Generate output
2. Wait/coffee break
3. Return with fresh perspective
4. Critique
5. Revise

Pattern 2: The Role Play

Adopt a specific persona for critique:

CRITIQUE PERSONA: "Skeptical security engineer"
What would they look for?
Input validation gaps
Authentication bypasses
Information disclosure
Audit trail gaps

Other personas:

Junior developer (confused by jargon?)

Future maintainer (will this code make sense in 6 months?)

Adversarial user (how could this be abused?)

Pattern 3: The Red Team

Actively try to break your own work:

RED TEAM QUESTIONS:
What's the worst interpretation of this?
How could someone misuse this?
What assumptions am I making that might be wrong?
What would prove this wrong?

Pattern 4: The Checklist Method

Use domain-specific checklists (see frameworks above):

BEFORE SHIPPING, CHECK:
[ ] All critical criteria pass
[ ] At least 80% of moderate criteria pass
[ ] No new critical issues introduced in revision

Examples

Example 1: Code Self-Critique

Initial Code:

def process_payment(user_id, amount):
    user = db.get_user(user_id)
    if user.balance >= amount:
        user.balance -= amount
        db.update(user)
        return True
    return False

Self-Critique:

CRITIQUE:
CRITICAL:
1. No transaction isolation—race condition possible
   FIX: Use database transaction with FOR UPDATE
2. No audit logging—can't trace what happened
   FIX: Log payment to audit table
3. No input validation—negative amounts?
   FIX: Validate amount > 0
4. No error handling—database failure crashes
   FIX: Try/except with proper error handling
MODERATE:
5. Should return payment object, not bool
   FIX: Return Payment record with ID
6. Missing docstring
   FIX: Add docstring with args/returns/raises
REVISION:
[Updated code with all fixes]

Example 2: Email Self-Critique

Initial Email:

Subject: Meeting
Hey,
Need to talk about the thing. Tuesday?
-J

Self-Critique:

CRITIQUE:
CRITICAL:
1. No context—recipient doesn't know "the thing"
   FIX: Specify what meeting is about
2. Vague timing—"Tuesday" what time?
   FIX: Propose specific time or ask for availability
3. No purpose—why meeting vs email?
   FIX: State what decision/action needed
4. Too casual for likely audience
   FIX: Professional but friendly tone
MODERATE:
5. No duration estimate
   FIX: "30 minute meeting"
6. Missing call details
   FIX: Include Zoom link or location
REVISION:

Subject: Quick sync on Q3 roadmap - Tuesday 2pm?

Hi Sarah,

Hope you're doing well! I'd like to get your input on the Q3 roadmap priorities before finalizing next week.

Would you be available for a 30-minute call on Tuesday at 2pm PT? I'll send a calendar invite with Zoom details.

If that time doesn't work, I'm flexible Wednesday or Thursday afternoon.

Thanks! J

Example 3: Analysis Self-Critique
Initial Analysis:

Our API latency increased 50% after the v2 deployment. The new auth middleware is likely the cause. We should optimize it.

Self-Critique:

CRITIQUE:

CRITICAL: 1. 50% claim not verified—need actual numbers FIX: Include baseline (100ms) vs current (150ms) p99

2. "Likely" not rigorous—correlation ≠ causation FIX: Check other variables (traffic, dependencies) FIX: A/B test or profile before/after

3. "Optimize it" too vague FIX: Specific recommendation with trade-offs

4. No confidence interval or sample size FIX: Statistical significance check

5. Missing impact assessment FIX: User impact, revenue impact

6. No mitigation if optimization fails FIX: Rollback plan, alternatives

REVISION:

API latency (p99) increased from 100ms to 150ms (n=1M requests) 
after v2 deployment on March 1. This correlates with new auth 
middleware but other factors possible.
Evidence:
Profiling shows auth middleware +40ms
Traffic patterns unchanged
No dependency latency changes
Impact: 5% of requests now timeout for mobile users
Options:
1. Cache auth tokens (est. -30ms, 2 days work)
2. Async auth validation (est. -50ms, 1 week work)
3. Rollback to v1 (immediate, feature delay)
Recommendation: Option 1 first, if insufficient try Option 2.

Integration with Other Skills

Self-Critique + Plan First: 1. Plan the task 2. Execute step 3. Self-critique output 4. Revise 5. Next step

Self-Critique + Team Code: 1. Agent generates output 2. Same agent self-critiques 3. Revises 4. Submits 5. Manager integrates

Quick Start Template

## Original Output
[Your first draft]
Critique Persona
[Who am I being? e.g., "Skeptical security reviewer"]
Criteria
[ ] Criterion 1
[ ] Criterion 2
...
Findings
Critical
1. [Issue] → [Fix]
Moderate
1. [Issue] → [Fix]
Minor
1. [Issue] → [Fix]
Summary
[What needs revision]
Revised Output
[Final version with fixes]

References

Research: "Constitutional AI: Harmlessness from AI Feedback" (Anthropic, 2022)

Related: Self-reflection, Chain-of-Verification, Self-Consistency

See references/examples.md for more detailed examples

Example 1: Code Self-Critique

Initial Code:

def process_payment(user_id, amount):
    user = db.get_user(user_id)
    if user.balance >= amount:
        user.balance -= amount
        db.update(user)
        return True
    return False

Self-Critique:

CRITIQUE:
CRITICAL:
1. No transaction isolation—race condition possible
   FIX: Use database transaction with FOR UPDATE
2. No audit logging—can't trace what happened
   FIX: Log payment to audit table
3. No input validation—negative amounts?
   FIX: Validate amount > 0
4. No error handling—database failure crashes
   FIX: Try/except with proper error handling
MODERATE:
5. Should return payment object, not bool
   FIX: Return Payment record with ID
6. Missing docstring
   FIX: Add docstring with args/returns/raises
REVISION:
[Updated code with all fixes]

Example 2: Email Self-Critique

Initial Email:

Subject: Meeting
Hey,
Need to talk about the thing. Tuesday?
-J

Self-Critique:

CRITIQUE:
CRITICAL:
1. No context—recipient doesn't know "the thing"
   FIX: Specify what meeting is about
2. Vague timing—"Tuesday" what time?
   FIX: Propose specific time or ask for availability
3. No purpose—why meeting vs email?
   FIX: State what decision/action needed
4. Too casual for likely audience
   FIX: Professional but friendly tone
MODERATE:
5. No duration estimate
   FIX: "30 minute meeting"
6. Missing call details
   FIX: Include Zoom link or location
REVISION:

Subject: Quick sync on Q3 roadmap - Tuesday 2pm?

Hi Sarah,

Hope you're doing well! I'd like to get your input on the Q3 roadmap priorities before finalizing next week.

Would you be available for a 30-minute call on Tuesday at 2pm PT? I'll send a calendar invite with Zoom details.

If that time doesn't work, I'm flexible Wednesday or Thursday afternoon.

Thanks! J

Example 3: Analysis Self-Critique
Initial Analysis:

Our API latency increased 50% after the v2 deployment. The new auth middleware is likely the cause. We should optimize it.

Self-Critique:

CRITIQUE:

CRITICAL: 1. 50% claim not verified—need actual numbers FIX: Include baseline (100ms) vs current (150ms) p99

2. "Likely" not rigorous—correlation ≠ causation FIX: Check other variables (traffic, dependencies) FIX: A/B test or profile before/after

3. "Optimize it" too vague FIX: Specific recommendation with trade-offs

4. No confidence interval or sample size FIX: Statistical significance check

5. Missing impact assessment FIX: User impact, revenue impact

6. No mitigation if optimization fails FIX: Rollback plan, alternatives

REVISION:

API latency (p99) increased from 100ms to 150ms (n=1M requests) 
after v2 deployment on March 1. This correlates with new auth 
middleware but other factors possible.
Evidence:
Profiling shows auth middleware +40ms
Traffic patterns unchanged
No dependency latency changes
Impact: 5% of requests now timeout for mobile users
Options:
1. Cache auth tokens (est. -30ms, 2 days work)
2. Async auth validation (est. -50ms, 1 week work)
3. Rollback to v1 (immediate, feature delay)
Recommendation: Option 1 first, if insufficient try Option 2.