Skip to main content
We don’t have too few skills. We have too many that overlap, so every session re-litigates “which verification skill?” / “which review skill?” / “do I need a plan?”. This page removes the choice.

​
The rule

Each skill owns exactly one (tier × step) cell. If a skill isn’t the named owner of a cell, you don’t run it — it’s either retired or it’s an auto-firing gate you never invoke by hand. There is never a menu. Two questions decide everything:
  1. Which tier is this change? (Quick / Standard / Large)
  2. What’s the next step in that tier’s row? Run the one skill in that cell. Done.

​
Step 1 — Classify the task (do this first, every time)

Pick the tier by uncertainty × blast radius, NOT by line count. A 1-line change to auth is Large. A 20-file mechanical rename is Quick.
Dangerous-surface override: anything touching auth, RLS, permissions, migrations, billing/money, or the RAG/embedding pipeline is Large regardless of size.

​
Step 2 — Follow your tier’s row. One skill per cell.

Steps run left to right. A blank cell means that step is skipped at this tier — not “use judgment,” just skip it.

​
The Build-skill picker (Step 3)

You never choose between build skills — the surface chooses: Gates (DESIGN-SYSTEM-GATE, DETAIL-PAGE-GATE, TABLE-PAGE-GATE, FORM-FK-VALIDATION-GATE, RAG-DOCS-GATE, FILE-ORGANIZATION-GATE) are not skills you invoke — they fire on commit. Don’t think about them; they think about you.

​
The three skills that kept colliding — now disambiguated

These three competed because nobody assigned them altitudes. They are not redundant; they live at different heights and now own different cells:

code-review

Verify (Step 4). “Did the diff build what we said, correctly?” Reads code, no browser. The only review skill. Runs at every tier ≥ Standard.

verify-feature

Test/Validate (Step 5–6, Large only). “Does the real user flow work and is the outcome good?” Drives the browser, checks the DB, takes screenshots. Heavy.

verification-before-completion

Ship gate (Step 7, all tiers). “Show the passing output before you claim done.” The one skill that runs on every task — because declaring victory without evidence happens at every tier.
They never compete again because they’re in different rows/columns.

​
Retire these (stop reaching for them)

When you’re about to invoke one of these, use its canonical replacement. The table above is the only menu.
One review skill. One deep-QA skill. One UI-validation skill. One universal closer. One planning skill per weight class. Everything else is an auto-firing gate or retired.

​
Models per step

Fresh context > different vendor. The review payoff comes from a reviewer that didn’t write the code and only sees requirements + diff — not from switching to a non-Claude model. Use a fresh Claude context with a reviewer role prompt; only go cross-vendor if you’ve measured a gap.

​
The one-paragraph version

Classify the task Quick / Standard / Large by uncertainty × blast radius (auth, RLS, migrations, money, RAG → always Large). Then walk that tier’s row: Frame → Plan → Build → Verify → Test → Validate → Ship, running the one skill named in each cell and skipping blank cells. Review = code-review. Deep QA = verify-feature. UI judgment = impeccable-alleato. Always close with verification-before-completion. Never pick from a menu of overlapping skills again.