Production grade
Router and orchestrator for the craft code-quality guardrails. Use FIRST on any broad "is this production-ready?", "review this code/diff/PR", "build this properly", "why does our AI-generated code keep needing rework", or "make this maintainable" request. Two modes: GENERATIVE GUARD (load the right senior heuristics before writing code) and CRITIQUE (audit a diff/file and return one worst-first ranked list of findings). Decomposes the request, fires the relevant craft member skills plus the existing complexity/refactoring/dependency/test skills in the right order, resolves their conflicts, and returns a single merged verdict. Defer to a single member skill only when the task is already narrow.From its SKILL.md
npx -y skills add manutej/craft --skill production-gradeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
7.6 KB, as published. Nobody here has run it
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.
- Read
RULES.md(the 13 rules + Definition of Done) — always. - Classify the task and load the matching member skills' Tier-1 reflex cards (the table below).
- Build with the smallest-diff-that-works discipline.
- 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.
- Determine what changed (the diff) and what it touches.
- Fire the relevant lenses (below) in dependency order.
- Merge & dedupe findings; one issue may trip several lenses — report it once, under its root cause.
- Rank by severity = job-damage × fix-cheapness.
- Emit the Output Contract.
Dispatch map — intent → skill
| The change involves… | Fire | Layer |
|---|---|---|
| New class / interface / factory / config / abstraction | craft:right-sized-design | craft |
| Error handling, input validation, secrets, boundaries | craft:robustness-at-boundaries | craft |
| A helper that may already exist; copy-paste; duplication | craft:dry-and-reuse | craft |
| Smelly structure (long method, god class, feature envy…) | craft:code-smells | craft |
| Logic tangled with I/O / mutation / nondeterminism | craft:effects-and-purity | craft |
| Names, comments, readability | craft:naming-and-comments | craft |
| Tests (writing or judging them); "is it actually done?" | craft:trustworthy-tests | craft |
| Schema / migration / payload / event-shape change | craft:data-and-state-evolution | craft |
| New dependency / external API call | craft:supply-chain-hygiene | craft |
| Quantified complexity metrics (cyclomatic/cognitive) | complexity-analysis | existing |
| The concrete refactoring to apply once a smell is found | refactoring-patterns | existing |
| Coupling / circular deps / god modules | dependency-analyzer | existing |
| Coverage gaps, risk-ranked | test-coverage-analyzer | existing |
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:
- Scope — does the diff match the request? (
right-sized-design) — catch over-engineering and scope creep before reading further. - Reuse — is anything here duplicating what exists? (
dry-and-reuse) - Structure — smells & coupling (
code-smells→dependency-analyzer) - Robustness — validation, errors, secrets (
robustness-at-boundaries) - Effects — purity / testability (
effects-and-purity) - Clarity — names & comments (
naming-and-comments) - Trust — tests prove behavior; it actually ran, red→green (
trustworthy-tests) - Data & state — shape changes phased, rollback tested (
data-and-state-evolution) - Supply chain — deps verified, no hallucinated APIs (
supply-chain-hygiene)
Tension resolution (when guardrails conflict)
| Tension | Resolution |
|---|---|
| "Add validation/robustness" vs. "smallest diff / don't over-engineer" | Robustness at boundaries always wins; over-engineering is internal structure, not edge safety. Validate the edge; keep the core simple. |
| "Make it pure/testable" vs. "don't add abstraction" | Extracting a pure function is not speculative generality — it pays off immediately in testability. Allow it. A new interface/factory needs ≥2–3 call sites; a pure helper does not. |
| "DRY / consolidate" vs. "a little duplication is fine" | DRY applies to knowledge (one rule, one place). Two look-alike blocks encoding different decisions may stay. Don't abstract incidental similarity. |
| "Match the codebase" vs. "the codebase is wrong" | Match it for this diff; raise the systemic fix as a separate, visible item — don't smuggle a refactor into an unrelated change (Broken Windows ticketed, not silently rewritten). |
| Severity disagreements between lenses | Router decides by job-damage × fix-cheapness; a Change Preventer outranks a cosmetic smell. |
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