Production Grade

production-grade — the senior-review router

Purpose: be the 15-year senior engineer who can glance at a change and say "this won't survive contact with production, and here's exactly why." This skill decomposes a request, dispatches to the right guardrails, and merges their output into one verdict — instead of dumping ten separate checklists.

Anchor frame (state it, then act on it): an AI coding agent is a Tactical Tornado by default — fast, prolific, leaving a maintenance wake. Every move here forces strategic (durable) code over tactical (fast-but-disposable) code. The bar is not "it works"; the bar is "the next engineer can read, trust, and change it." See references/PRINCIPLES.md and references/EVIDENCE.md.

When to use this router vs. go direct

• Route here when the request is broad: "review this PR," "is this production-ready," "build feature X properly," "our AI code keeps needing rework — fix the process," "audit this module."
• Go direct to a member skill when the task is already narrow: only naming → craft:naming-and-comments; only a dependency question → craft:supply-chain-hygiene.
• Don't route for trivial one-line edits. Overhead isn't worth it.

The two modes

Mode A — Generative Guard (before/while writing code)

Pull the relevant reflex cards into context before the agent writes, so the code is born right instead of being fixed later.

1. Read RULES.md (the 13 rules + Definition of Done) — always.
2. Classify the task and load the matching member skills' Tier-1 reflex cards (the table below).
3. Build with the smallest-diff-that-works discipline.
4. Close with the Definition of Done gate from RULES.md — including "I ran it, here's the evidence."

Mode B — Critique (auditing a diff / file / PR)

Return one ranked, worst-first list, each item tagged [skill · principle · severity], with the concrete fix. Not ten lists. Not vibes.

1. Determine what changed (the diff) and what it touches.
2. Fire the relevant lenses (below) in dependency order.
3. Merge & dedupe findings; one issue may trip several lenses — report it once, under its root cause.
4. Rank by severity = job-damage × fix-cheapness.
5. Emit the Output Contract.

Dispatch map — intent → skill

craft skills detect and judge; the existing skills measure and fix. When code-smells names a Long Method, hand the fix to refactoring-patterns. When you suspect deep coupling, confirm with dependency-analyzer.

Canonical critique chain (order matters)

Run lenses outside-in, cheap-and-structural first:

1. Scope — does the diff match the request? (right-sized-design) — catch over-engineering and scope creep before reading further.
2. Reuse — is anything here duplicating what exists? (dry-and-reuse)
3. Structure — smells & coupling (code-smells → dependency-analyzer)
4. Robustness — validation, errors, secrets (robustness-at-boundaries)
5. Effects — purity / testability (effects-and-purity)
6. Clarity — names & comments (naming-and-comments)
7. Trust — tests prove behavior; it actually ran, red→green (trustworthy-tests)
8. Data & state — shape changes phased, rollback tested (data-and-state-evolution)
9. Supply chain — deps verified, no hallucinated APIs (supply-chain-hygiene)

Tension resolution (when guardrails conflict)

Output Contract (Mode B)

## Verdict: SHIP / SHIP-WITH-FIXES / REWORK
One-sentence senior summary. (e.g. "Logic is correct but the diff doubles an
existing util and swallows the parse error — rework before merge.")

## Must-fix (blocks merge)
1. [robustness-at-boundaries · swallowed-error · HIGH] path/file.ts:42 —
   <what's wrong> → <the fix> (links: refactoring-patterns / RULES rule 6)
2. ...

## Should-fix (not blocking, but real debt)
- [code-smells · duplicate-code · MED] ...

## Nits (optional)
- [naming-and-comments · vague-name · LOW] ...

## Definition-of-Done check
- [x]/[ ] for each item in RULES.md's gate, with the missing evidence called out.

Always: name the principle, cite the file:line, give the fix, and rank by severity. Never assert taste without a named principle. Praise is fine but brief — this is editing, not a performance review.

References

• The 13 rules + Definition of Done: ../../RULES.md
• Why durable code wins: ../../references/PRINCIPLES.md
• The smell catalog: ../../references/SMELLS.md
• The data behind all of it: ../../references/EVIDENCE.md
• Language tells: ../../references/lang/{python,typescript,go}.md