critique

# Critique Command

Use this command to get a Distinguished Engineer level technical critique of the current approach and implementation.

<!-- recall:begin -->

## Step 0: Prior-art check (MANDATORY)

Before critiquing, recall prior learnings from the global knowledge base so we don't re-learn or re-decide something already captured:

```bash
uv run "{{HOME_TOOL_DIR}}/skills/recall/scripts/recall.py" \
  "<QUERY>" \
  --limit 5 --format markdown
```

**Query construction for `/critique`**: a short summary of the approach/code being critiqued + relevant domain keywords (e.g. `"event-sourced migration rollback strategy"`).

**What to do with results:**

- If a returned learning names a constraint, anti-pattern, or prior decision directly relevant to the task — surface it to the user BEFORE proceeding with this skill's main flow.
- If nothing relevant returns — proceed silently, no need to mention the check.
- Never block on recall failure. Empty output / non-zero exit is expected when the KB is absent or the subprocess errors — treat it as "no prior art found", not as an error.

<!-- recall:end -->

## Usage

```
/critique [type] "context"
```

## Types

- `general` - Overall technical review (default)
- `architecture` - System design and patterns review
- `performance` - Performance and scalability analysis
- `security` - Security implications assessment
- `cost` - Total cost of ownership analysis
- `complexity` - Overengineering assessment
- `all` - Comprehensive review covering all aspects

## Description

This command provides brutally honest, constructive critique with 25+ years of Distinguished Engineer experience perspective. The review prevents costly mistakes while not crushing innovation. The critique will be displayed in a clear <output> block for review and response.

## Examples

```
/critique architecture "Using microservices for a 3-user internal tool"
/critique cost "Kubernetes for a static website"
/critique all "Redux for state management in a todo app"
/critique "Using 5 different databases in a startup MVP"
```

## Output Format

The critique provides a structured JSON report containing:

- **Summary**: Verdict (APPROVE/CAUTION/RECONSIDER/REJECT), one-liner, confidence score
- **Strengths**: 2-3 genuine strengths of the approach
- **Concerns**: Critical, major, and minor issues with impact analysis
- **Alternatives**: Better approaches with pros/cons
- **Cost Analysis**: Initial, operational, hidden costs, and 3-year TCO
- **Complexity Assessment**: Overengineering score and simplification suggestions
- **Team Impact**: Learning curve, hiring difficulty, maintenance burden
- **Future Proofing**: Scalability limits, migration difficulty, tech debt
- **Recommendation**: Should proceed or not with conditions
- **Wisdom**: Pattern recognition, war stories, and principles

## Implementation

When this command is invoked:

1. **Context Extraction**:
   - Identify what needs critique from the current conversation
   - Gather recent technical decisions and implementation details
   - List files created or modified in this session
   - Extract relevant code snippets
   - Note any trade-offs or constraints mentioned

2. **Analysis Phase**:
   - Apply Distinguished Engineer perspective (25+ years experience)
   - Identify anti-patterns and overengineering
   - Assess complexity vs problem size
   - Consider simpler alternatives
   - Evaluate long-term implications

3. **Generate Critique** with structured output:
   - Verdict (APPROVE/CAUTION/RECONSIDER/REJECT)
   - Critical concerns with evidence
   - Alternative approaches with trade-offs
   - Overengineering score
   - Clear recommendations

4. **Display Output** in formatted <output> block:
   - Color-coded verdict
   - Highlighted critical concerns
   - Alternative recommendations table
   - Action items

5. **Save the critique** to `{{HOME_TOOL_DIR}}/critiques/critique_[TIMESTAMP]_[TYPE].json`

## Critique Perspective

The Distinguished Engineer perspective includes:
- 25+ years seeing technologies rise and fall
- Experience with architectures that succeeded and failed
- Understanding of team dynamics and organizational impact
- Battle scars from real-world production systems

The critique should be:
- Brutally honest but constructive
- Data-driven with real examples
- Focused on preventing expensive mistakes
- Balanced between innovation and pragmatism

## Response Protocol

After receiving the critique:
1. Review and acknowledge each critique point
2. Provide rationale or agreement with concerns
3. Propose adjustments based on valid points
4. Update implementation if significant issues identified

## Notes

- The critique is advisory, not prescriptive
- Consider context and constraints when evaluating recommendations
- Perfect is the enemy of good, but good enough today often becomes tomorrow's technical debt
- The goal is to make informed decisions, not to achieve perfection
- Each critique should challenge assumptions and prevent costly mistakes