Production bar

Production Bar

Judge the named feature/system against best-in-class production, not against "works on my machine" or this repo's average. Be blunt. Flattery is a failure mode.

Leading words: production bar, peer set, production score, gap, fix-importance.

Two scales — never conflate them

This skill uses two different 1–10 numbers. They measure different things and both are mandatory in the report:

Scale	Question it answers	Where it appears
Production score N/10	"How close is this to top-tier production?" 10 = peer-grade, 1 = toy.	One overall score in the Verdict, one per axis.
Fix-importance N/10	"How much does closing this specific gap matter for respected production?"	On every listed gap (and every win).

A feature can be 4/10 overall while its biggest gap is only fix-importance 6 (many medium gaps), or 8/10 overall with one fix-importance 9 gap (one ship-blocker away from great). The overall score is a judgment of the whole, not an average of importances and not the importance of the top gap. If you output only one of the two scales, the report is wrong.

For an already-at-the-bar win, fix-importance means the production importance of retaining that capability. Keep the label unchanged so the report schema remains stable.

Process

1. Pin the subject

Identify exactly what is under review (feature, flow, subsystem). If unclear, ask once. Prefer reading the code over asking.

State the evidence boundary under Subject using the stable label **Evidence boundary:**: name the entrypoints/files inspected, runtime evidence observed, and any evidence that was unavailable. Distinguish absent from not verified.

If neither implementation nor runtime evidence is available, do not invent a score from plans or claims. Output only this blocker shape and stop:

## Evidence blocker
- **Subject:** …
- **Missing:** …
- **Needed:** …

Done when: subject, entrypoints, and evidence boundary are named.

2. Pick the peer set

Choose 2–4 real top players in this domain (e.g. billing → Stripe; realtime collab → Figma/Linear; feed ranking → TikTok/Netflix; DX → Vercel). Name them. Do not invent a vague "industry best practice" fog — name peers and what they are known for on this axis.

Compare against publicly documented or observable product behavior. Do not claim knowledge of a peer's private implementation.

Done when: peer set is listed with one line each on why they set the bar here.

3. Legwork

Read the actual implementation, tests, configs, and failure paths. Score only what exists in the tree (and observed runtime if evidence is present). No credit for intended-but-unbuilt work.

Check these axes (skip only if truly N/A, and say so):

Axis	Production bar means
Correctness	Edge cases, invariants, idempotency, concurrency
Algorithms / data	Right structure/complexity for the load; not accidental O(n²)
Failure modes	Timeouts, retries, partial failure, poison inputs, rollback
Observability	Signals that catch real breakage (not vanity logs)
UX / API shape	Clear contract; no footguns; matches how top products feel
Security / tenancy	Authz boundaries, injection, secret handling where relevant
Operability	Deploy, migrate, kill-switch, backfill, cost under load
Tests	Protect the real risks; not theater coverage

Done when: every non-N/A axis has evidence cited (file/symbol, observed runtime, "absent", or "not verified").

4. Score

Production score — assign one overall N/10 and one N/10 per axis (or n/a):

Score	Tier	Meaning
9–10	top-tier	Would not embarrass the peer set on the core path
7–8	solid	Production-credible; clear gaps vs peers, none fatal
4–6	junior	Ships, but patterns/algorithms/ops lag serious production
1–3	toy	Demo / happy-path; would fail under real load, abuse, or ops

Use domain-weighted judgment, not an arithmetic average. Identify which axes gate the subject's core promise. Any unresolved fix-importance 9–10 gap caps the overall production score at 6/10 because such a gap is, by definition, a ship-blocker or trust-killer.

Fix-importance — for every gap (and every "already at the bar" win worth calling out), assign 1–10: how much this matters for a normal, respected production system in this domain — not for a research demo, not for perfectionism:

Score	Meaning
9–10	Without this, you are not serious production. Ship-blocker / trust-killer.
7–8	Expected of any respected production; gap is visibly amateur under real use.
5–6	Solid teams have this; absence is noticeable but survivable short-term.
3–4	Nice polish / peer-grade nicety; deferrable if the core path holds.
1–2	Prestige / gold-plating relative to the current stage.

Rules:

• Default skeptical. "Looks fine" is not a finding.
• Separately call out what is already peer-grade — honesty cuts both ways.
• If the product stage is early, still use the same scores; add one line on acceptable for stage vs bar, never inflate the score or deflate importance for comfort.
• Fix-importance is about respected production, not about how hard the fix is. Hard ≠ important; easy ≠ unimportant.
• Sort Below the bar by fix-importance descending.

Done when: overall + per-axis production scores are set, and every listed item has a fix-importance score.

5. Report

Output exactly this shape:

## Subject
…
**Evidence boundary:** inspected …; runtime …; unavailable …

## Peer set
- …

## Production score: N/10 (<tier>)
One blunt paragraph: why this score, not one point higher.

| Axis | Score |
|------|-------|
| Correctness | N/10 |
| … | … or n/a |

## Already at the bar
- **[fix-importance N/10]** …
Or: none

## Below the bar
- **[fix-importance N/10] [axis]** … — evidence → what peers do instead

## Must-fix for respectable production
- **[fix-importance N/10] [axis]** …
Include every gap with fix-importance ≥ 7, ordered high → low. If none, say "none — already at respectable bar."

## Smallest gap to +1 point
3 or fewer concrete moves that would raise the overall production score by one point (prefer highest-importance gaps). No roadmap theater.

Example line, to make the two scales unmistakable:

[fix-importance 8/10] [Failure modes] Webhook handler has no retry/idempotency — server/api/payments/webhook.post.ts processes once, drops on 500 → Stripe-class systems dedupe by event id and retry with backoff.

Do not soften the verdict in a closing pep talk. Stop after the report unless the user asks to fix the gaps.