playbooks

home / skills / phrazzld / claude-config / critique

critique skill

/skills/critique

This skill channels adversarial feedback from a persona to critique your code and surface concrete, actionable fixes.

npx playbooks add skill phrazzld/claude-config --skill critique

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.6 KB
---
name: critique
description: |
  CRITIQUE
effort: high
---

---
description: Adversarial expert review from a specific persona
argument-hint: <persona> [context]
---

# CRITIQUE

Channel a specific expert for adversarial feedback.

## Argument

- `persona` — One of: grug, carmack, ousterhout, fowler, beck, jobs, torvalds

## Personas

| Persona | Lens | Challenges |
|---------|------|------------|
| **grug** | Complexity demon | Over-abstraction, unnecessary layers, big-brain patterns |
| **carmack** | Shippability | Scope creep, premature optimization, not focusing |
| **ousterhout** | Module depth | Shallow modules, pass-through layers, interface complexity |
| **fowler** | Code smells | Duplication, long methods, feature envy, inappropriate intimacy |
| **beck** | Test design | Untestable code, missing TDD, over-mocking |
| **jobs** | Simplicity | Feature bloat, unclear value, lack of craft |
| **torvalds** | Pragmatism | Over-engineering, not shipping, design astronauts |

## What This Does

1. **Load persona** — Channel the expert's perspective and values
2. **Analyze target** — Review code, design, or plan through their lens
3. **Challenge ruthlessly** — Find flaws the persona would hate
4. **Recommend** — What would they demand you change?

## Execution

Launch Task agent with persona instructions:
- Read the relevant code/design
- Apply persona's specific lens
- Produce adversarial critique
- Suggest concrete fixes

## Output

Structured critique:
- **This {persona} hates:** Specific issues found
- **{Persona} demands:** Required changes
- **{Persona} would approve if:** Conditions for acceptance

Overview

This skill provides adversarial expert reviews by channeling a chosen persona to critique code, designs, or plans. It focuses feedback through a sharply defined lens and delivers actionable, persona-driven recommendations. Use it to surface hard truths and prioritize concrete fixes.

How this skill works

You specify one of the supported personas and provide the target artifact (code, architecture, or plan). The skill adopts the persona’s values, inspects the artifact for faults that persona cares about, and generates a structured critique. Output highlights what the persona hates, what they demand, and conditions that would win their approval.

When to use it

  • Before major design reviews or releases to catch persona-specific blind spots
  • When you suspect subtle technical debt or culture-driven issues
  • To harden acceptance criteria for features or refactors
  • When preparing engineering teams for tough stakeholder scrutiny
  • To validate testability, simplicity, or shipping focus depending on persona

Best practices

  • Provide concrete inputs (code snippets, design docs, test plans) not vague descriptions
  • Pick the persona that matches the risk you want to mitigate
  • Ask for iteration after applying fixes to re-evaluate changes
  • Use the critique to form a short prioritized action list with owners
  • Treat the persona’s tone as a tool for focus, not literal instruction

Example use cases

  • Run the 'carmack' persona on a large feature branch to expose scope creep and shipping blockers
  • Use 'fowler' to surface code smells and refactoring hotspots in a legacy module
  • Apply 'beck' to a test suite and identify untestable code or over-mocking patterns
  • Invoke 'torvalds' on architecture proposals to weed out over-engineering and enforce pragmatism
  • Call 'jobs' when a product spec needs ruthless prioritization and clarity of value

FAQ

Which personas are available?

Available personas include grug, carmack, ousterhout, fowler, beck, jobs, and torvalds, each with a distinct evaluation lens.

What format should I supply the target in?

Prefer plain code snippets, links to design docs, or concise architecture summaries. For large inputs, supply focused excerpts or a short context paragraph.