/vanity-engineering-review

name: vanity-engineering-review
description: >
  Reviews codebases, architectures, PRs, and technical plans for vanity engineering — code
  and systems built for the developer's ego, resume, or intellectual pleasure rather than
  delivering user or business value. Triggers on: "review this code", "is this over-engineered",
  "code review", "architecture review", "complexity audit", "vanity check", "is this necessary",
  "simplify this", "tech debt review", or any request to evaluate whether code or architecture
  is justified by actual requirements. Also trigger when the user shares a codebase and asks
  for feedback, when discussing framework/library choices, when reviewing PRs, or when someone
  is debating whether to refactor or rebuild. Nudge activation when you detect patterns of
  unnecessary abstraction, premature optimization, or resume-driven technology choices in code
  the user shares — even if they haven't asked for a vanity review.

Vanity Engineering Review

A diagnostic skill that identifies code, architecture, and technical decisions built to impress rather than to ship. Vanity engineering is entropy disguised as craftsmanship — it increases complexity without proportional capability gain, and it compounds maintenance cost while delivering zero additional user value.

Core Premise

**The only legitimate purpose of engineering is to solve a problem someone actually has.**

Everything else — elegant abstractions nobody traverses, microservices that serve one endpoint, custom frameworks that replicate existing tools, type systems more complex than the domain they model — is vanity. It may feel productive. It is not.

This skill does not oppose quality, rigour, or good engineering. It opposes engineering that exists to satisfy the builder rather than the user.

When to Apply This Skill

Apply this review to any of:

• Codebase audits (full repo or specific modules)
• Pull request reviews
• Architecture proposals or RFCs
• Technology selection decisions
• Refactoring plans
• "Should we rebuild this?" discussions
• Post-mortems where complexity contributed to failure

The Review Process

Phase 1: Establish the Requirement Anchor

Before examining any code, establish what the system actually needs to do. Without this anchor, you cannot distinguish necessary complexity from vanity complexity.

Ask (or determine from context): 1. **Who uses this?** (End users, internal team, API consumers, nobody yet) 2. **What must it do?** (Core user stories / jobs-to-be-done — max 5) 3. **What scale does it actually operate at?** (Not projected. Actual.) 4. **What are the real constraints?** (Regulatory, latency SLAs, integration requirements) 5. **What is the team size maintaining this?** (Solo dev? 3-person startup? 50-person org?)

If the user cannot answer these, that is itself a vanity signal — building without defined requirements.

Phase 2: Detection Scan

Scan the codebase or architecture against the detection patterns in `references/detection-patterns.md`. Read that file before proceeding.

Score each finding using the Vanity Severity scale:

• **V0 — Cosmetic**: Unnecessary but harmless. Adds no maintenance burden. Note and move on.
• **V1 — Drag**: Adds ongoing cognitive or maintenance cost without user value. Flag for simplification.
• **V2 — Structural**: Shapes architecture around vanity rather than requirements. Flag for redesign.
• **V3 — Compounding**: Actively forces other code to be more complex to accommodate it. Flag as urgent — this metastasizes.

Phase 3: The Vanity Score

Produce a structured assessment:

## Vanity Engineering Assessment

### Summary
[One paragraph: What this codebase does vs what it is engineered to do.
The gap between these two is the vanity surface area.]

### Requirement-to-Complexity Ratio (RCR)
[Scale 1-10. 1 = minimal viable solution. 10 = PhD thesis disguised as a CRUD app.
Most production systems should score 2-4.]

### Top Findings (max 7)
For each finding:
- What: The specific pattern detected
- Where: File/module/component
- Severity: V0-V3
- Why it is vanity: How it fails the "does a user need this?" test
- What it should be instead: The simpler alternative
- Kill cost: Effort to remove or simplify (hours/days)

### Vanity Debt Estimate
[Total accumulated complexity cost from vanity engineering.
Express as: person-hours of maintenance per month attributable to
vanity patterns rather than actual requirements.]

### The Hard Question
[One direct, uncomfortable question the team needs to answer honestly.
Example: "If you deleted the entire plugin system and hardcoded the
three integrations you actually use, what would you lose?"]

Phase 4: Kill Criteria Generation

For every system or feature reviewed, generate a kill criteria framework. This is the most important deliverable — it prevents vanity engineering from recurring.

Read `references/kill-criteria-template.md` for the full template, then generate a project-specific version.

---

Kill Criteria Philosophy

Kill criteria exist because humans are bad at stopping things. We are wired to continue what we started (sunk cost), to add rather than remove (addition bias), and to interpret complexity as value (effort justification). Kill criteria counteract all three by making the stop decision automatic, pre-committed, and ego-independent.

Tier 1 — Hard Kill (Automatic, Non-Negotiable)

These trigger immediate shutdown with no debate. They exist for situations where continuing causes escalating damage. No human approval needed — if the condition is met, the thing dies.

Examples:

• Security breach traced to the component
• Production incident caused by the component with severity >= P1
• Cost exceeds budget cap for 3 consecutive days
• The component has zero usage for 30 days (no API calls, no page views, nothing)
• The sole maintainer leaves and no one volunteers to own it within 2 weeks

Tier 2 — Review Trigger (Automatic Flag, Human Decisio