菜单
Use when a product needs a whole-product production-readiness assessment, module-by-module scoring, completeness or parity checks, tenancy and seed-data verification, exhaustive frontend/backend Playwright coverage, or an evidence-backed answer about what remains before shipping.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/boparaiamrit/superdev --skill production-readiness-audit命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Multi-agent orchestration for full-stack monorepo builds. Audits a PRD against a design handoff (HTML, screenshots, claude.ai/design output) to find gaps, writes an execution plan, and dispatches parallel subagents through 4 phases. Coordinates ALL 16 superdev skills — design-preservation (when source is a prototype, not Claude Design), design-to-nextjs (shadcn translation when source is Claude Design), nestjs-enterprise-backend, security-review-and-fix, prototype-to-saas, exploratory-qa, systematic-debugging (on any bug found mid-build), product-completeness-audit (between QA and ship), brutal-exhaustive-audit (final pass before declaring done). Reads `.claude/memory/superdev-learned/` before every subagent dispatch and threads project-specific lessons into agent prompts so the system avoids repeating past mistakes (self-learning loop via superdev-self-learning skill).
Run superdev's machine-checkable Definition-of-Done gate on demand. Reads COMPLETION_LEDGER.json (build/typecheck/lint/integration/completeness/security/qa/brutal verdicts) plus live no-suppressions and demo/placeholder sweeps, and reports PASS/FAIL with the exact failing checks. Use when asked "are we done", "is it production ready", "run the done gate / completeness gate", or BEFORE declaring any superdev build complete. The same gate runs automatically as a Stop hook during superdev builds, so a "done" claim cannot be made while any check is red.
The meta-skill that makes superdev self-improving. Captures user-frustration signals (explicit corrections, code reverts, regression-verifier failures, design-drift above 1%, re-prompts with frustration markers) and writes structured **feedback** memory entries to `.claude/memory/superdev-learned/`. Future orchestrator dispatches read this memory first so the system learns what NOT to do in this project, what skills to call (or never call) in which context, and which defaults to pre-apply. Project-scoped only; never global. Triggered automatically by the `UserPromptSubmit` hook on frustration patterns and by `SubagentStop` after fix-applier or design-fidelity-auditor.
正在显示 SKILL.md
基于 SOC 职业分类
| name | production-readiness-audit |
| description | Use when a product needs a whole-product production-readiness assessment, module-by-module scoring, completeness or parity checks, tenancy and seed-data verification, exhaustive frontend/backend Playwright coverage, or an evidence-backed answer about what remains before shipping. |
The skill that answers the only question that matters before shipping: "Is every module actually production-ready — scored, proven, and fixed — or does it just look done?"
Real builds stall at ~70% because "done" is self-asserted. This skill replaces the assertion with a scored, looping, evidence-backed process: every module is rated 1–10 across five passes, every gap becomes a checklist item, agents fix the items, and the audit re-runs until every module scores 9+. Nothing is taken on faith — data is proven real, tenancy is proven isolated, every route/form/data-shape is proven working in a real browser against a real backend.
EVERY MODULE SCORED 1–10. NOTHING SHIPS BELOW 9.
LOOP fix → re-audit UNTIL EVERY MODULE IS 9+.
NO LINT/TYPE SUPPRESSIONS — fix the root cause, never disable.
REAL SEED DATA + AN INITIAL PRODUCT USER. TENANCY PROVEN ISOLATED.
EVERY ROUTE, EVERY FORM, EVERY DATA SHAPE EXERCISED IN PLAYWRIGHT (FE + BE).
A 9 means: a paying user could rely on this module today. An 8 is not "almost there" — it is "not done", and it goes back into the loop.
frontend-modular-architecture / design-review)systematic-debugging)This runs after integration-tester, security-review-and-fix, and exploratory-qa have each produced their artifacts, and it subsumes and finalizes product-completeness-audit + brutal-exhaustive-audit into a single scored loop. The orchestrator (the main session) drives the loop; it reads .claude/memory/superdev-learned/ first and threads relevant lessons into every dispatch.
Preconditions the orchestrator verifies before scoring (a build cannot be rated if these are absent):
NEXT_PUBLIC_API_MODE=production / MAIL_PROVIDER/BILLING_PROVIDER set to real-or-env-switched), not demo mode.seed-data-architect first if not. The product must be usable on a fresh DB with a real owner/admin login, realistic volumes, and zero hardcoded fallbacks.Each pass scores every module 0–10 on one dimension and emits findings. The passes reuse superdev's existing specialist agents plus three readiness-specific agents. Run the scanning passes (1, 2, 5-static) in parallel; the browser passes (3, 4) need the stack up.
| # | Pass | Dimension | Agents |
|---|---|---|---|
| 1 | Completeness & wiring | Every route renders real data; every button/form/menu hits a real API; no placeholders, stubs, alert(), or demo-fallbacks on success paths | placeholder-hunter, route-completeness-checker, wiring-auditor, data-flow-real-vs-mock |
| 2 | Data realism & seed | Real seed data at realistic scale; an initial product (owner/admin) user that can log in; aggregate counts computed from the DB (never hardcoded 0); product works with demo mode OFF | seed-data-architect, data-flow-real-vs-mock |
| 3 | Tenancy isolation | With ≥2 seeded tenants, tenant A cannot read / list / search / export / mutate / enumerate tenant B's data via API or UI (IDOR on every :id, list scoping, search, webhooks). Any leak caps the module at ≤3. | tenancy-isolation-tester |
| 4 | End-to-end (Playwright) | Every route loads; every form validates → submits → persists (DB-verified) → re-renders; data-shape parity FE↔BE (no undefined in any view; contract == API == UI); happy + 13 edge categories | route-walker, qa-flow-tester, journey-walker, edge-case-prober, data-flow-tracer |
| 5 | Code quality & security | Zero lint errors and zero type errors with no suppressions (eslint-disable/@ts-ignore/as any/@phpstan-ignore); authz enforced (CASL/Policies), input validated, no secrets in code, no god-files. Any P0 security/data-loss caps the module at ≤3. | static-auditor, dependency-auditor, ui-auditor, module-structure-auditor |
See references/five-pass-audit.md for the exact dispatch prompts per pass.
module_score = min(pass1, pass2, pass3, pass4, pass5)
A module is only as production-ready as its weakest dimension — a beautiful, fully-wired UI with a tenancy leak is not an 8, it is a 3. Hard caps make disqualifying findings impossible to average away: a tenancy leak (Pass 3) or a P0 security/data-loss bug (Pass 5) caps the module at ≤3 no matter how good everything else is.
module-readiness-rater reads all five pass reports for a module and emits its score + the consolidated, fix-ordered checklist. The full rubric (what 9–10 vs 7–8 vs ≤6 means per dimension) is in references/rubric.md. The rubric defines 9–10 as "production-ready, at most cosmetic nits" so min is honest, not trivia-driven.
round = 0
do:
round += 1
1. Run the five passes across all modules → per-module pass scores
2. module-readiness-rater → READINESS.md (per-module score + verdict)
and READINESS_CHECKLIST.md (every finding as a one-line, owned ticket)
3. Update COMPLETION_LEDGER.json: features.<module>.readiness_score, gates.readiness
4. If every module ≥ 9 → DONE, break.
5. For each module < 9: dispatch the matching fixer (backend/frontend/laravel/
inertia-module-builder, security-fixer) on THAT module's checklist items.
Fix the ROOT CAUSE. No suppressions. No new demo data.
6. Re-run ONLY the passes that scored < 9 for the fixed modules.
while (any module < 9 AND round < 5)
if any module still < 9 after round 5:
STOP. Surface READINESS_CHECKLIST.md with the blocking items to the user —
do not loop forever, and do not lower the bar.
The orchestrator dispatches; builders/fixers never chain. State lives in READINESS.md, READINESS_CHECKLIST.md, and COMPLETION_LEDGER.json — all on disk, so the loop survives context compaction. See references/readiness-checklist-format.md.
eslint-disable / @ts-ignore / @ts-expect-error / as any / as unknown as / @phpstan-ignore. The fix is the root cause, every time. A module with suppressions cannot exceed 7.*_count, totals) is hardcoded.This skill is how the completeness, qa, security, brutal, and readiness gates in COMPLETION_LEDGER.json reach pass. The Stop-hook done-gate (hooks/scripts/done-gate.sh) requires gates.readiness == pass and every features.<module>.readiness_score ≥ 9 before any completion claim is allowed. So this loop is not optional politeness — it is the only path to a legitimate "done". See ../prd-design-build-orchestrator/references/done-gate.md.
READINESS.md + READINESS_CHECKLIST.md producedCOMPLETION_LEDGER.json: gates.readiness == pass, all readiness_score ≥ 9If any box is unchecked, the product is not ready and the done-gate will block the claim.
references/rubric.md — the 1–10 scoring rubric per dimensionreferences/five-pass-audit.md — exact dispatch prompts for each passreferences/readiness-checklist-format.md — READINESS.md + READINESS_CHECKLIST.md formats and the ledger updatereferences/agent-definitions.md — the three readiness-specific agents