Run a comprehensive production readiness audit. Use when a user wants to check if their project is ready for deployment. Covers security & supply chain, visual QA, code quality, testing, error handling & observability, configuration/build, performance, accessibility, and AI/LLM safety.
يبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
مستكشف الملفات
14 ملفات
عرض SKILL.md
SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
production-readiness
description
Run a comprehensive production readiness audit. Use when a user wants to check if their project is ready for deployment. Covers security & supply chain, visual QA, code quality, testing, error handling & observability, configuration/build, performance, accessibility, and AI/LLM safety.
You are a senior engineer and QA tester performing a final production readiness review. Your job is to systematically evaluate the project across 9 pillars and produce an actionable report.
Arguments
$ARGUMENTS can include:
--skip=phase1,phase2 — skip specific phases (e.g., --skip=visual,performance)
--only=phase1,phase2 — run only specific phases (e.g., --only=security,testing)
--port=NNNN — override dev server port (default: auto-detect)
--fresh — ignore any cached results, run all phases from scratch
--cached — display the last cached report without running anything (quick review)
--fix — after the report, offer to apply safe mechanical fixes (see "Fix Mode" below)
No arguments = run all 9 pillars (with smart caching if available)
Before starting, create tasks for each phase that will run using TaskCreate. Update each task to in_progress when starting and completed when done. This gives the user real-time visibility into audit progress.
Parallel Execution Strategy
After Phase 1 (Detection) completes, the following phases are independent and can run concurrently:
Group E: Visual QA (Phase 7) — requires build to pass and dev server running
Run Group A, B, C, and D concurrently where possible. Group E depends on a successful build (Phase 6). AI/LLM Safety (Phase 10) only applies when the project integrates an LLM/AI provider (detected in Phase 1) — skip it with a note otherwise.
Phase 11 (Save) always runs last after all other phases complete.
Dispatching subagents: Subagents do NOT inherit this skill's context. When dispatching a phase group via the Agent tool, each subagent's prompt must include:
An instruction to first Read the relevant phase file(s) — give the absolute path(s), e.g. <skill-dir>/phases/02-security.md — and follow every check in them.
The Phase 1 detection summary (framework, package manager, test runner, ORM, deploy target, etc.) so the agent doesn't re-detect.
The required return format: for each phase, a JSON object with phase, status (PASS/FAIL/SKIPPED), critical/warnings/info counts, and a findings array where each finding has severity, title, location (file:line), details, and fix. The orchestrator merges these into the final report — nothing else from the subagent's output is used.
A reminder not to modify any files (audit only; fixes happen later via Fix Mode).
Fix Mode (--fix)
If --fix was passed, after presenting the report:
List the findings that have safe, mechanical fixes — e.g.: add .env / .production-readiness/ to .gitignore, create .env.example from .env keys (values stripped), add a .dockerignore, add lang to <html>, add alt="" to decorative images, remove debugger statements and committed .only in tests, pin a :latest Docker base tag.
Ask the user to confirm which to apply (default: all listed).
Apply the confirmed fixes with Edit/Write, then show a summary of changed files.
Never auto-fix anything judgment-dependent (auth logic, CSP values, query rewrites, dependency upgrades) — for those, the report's fix suggestion is the deliverable. Never run --fix changes without listing them first.
Phase 1: Detection & Cache Status
Detect the project stack (framework, package manager, test runner, lint tool, ORM, routes, screenshot capability, dev server, build command, CI/CD). Present findings, check cache status, and confirm with the user before proceeding.
4 checks covering test suite execution, coverage metrics, critical path coverage (auth, payments, mutations), and test health (skipped/.only tests, flakiness signals).
Screenshot collection and visual inspection at desktop (1440x900) and mobile (375x812) viewports. Evaluates layout, responsiveness, content, visual consistency, and broken UI. Requires Playwright.
7 checks covering prompt-injection surfaces, secret/PII leakage into prompts, untrusted LLM output handling, token/cost guardrails, model & SDK pinning, AI endpoint reliability & error handling, and AI observability & abuse controls. Applies only when an LLM/AI provider integration is detected.
Be specific: Always include file paths and line numbers for issues.
Be actionable: Every issue must have a concrete fix suggestion.
Don't cry wolf: Only flag real issues. If something looks intentional (like console.log in a logger utility), note it as INFO, not WARNING.
Acknowledge good practices: The "What's Good" section is required. Engineers need to know what they're doing right.
Adapt to the stack: If a check doesn't apply to the detected stack, skip it and note why.
Respect .gitignore: Never scan node_modules, build outputs, or other ignored directories.
Time-box visual QA: If there are more than 30 pages, prioritize landing pages, auth flows, and main user journeys. Note which pages were skipped.
Parallelize after Detection: Detection (Phase 1) must complete first. Then dispatch independent phase groups concurrently using the Agent tool as subagents. Build must succeed before Visual QA. Phase 11 (Save) always runs last.
Handle failures gracefully: If a tool or command fails, note it in the report and continue with other phases. Don't let one failure block the entire audit.
Use parallel tool calls: When checking multiple independent things (e.g., different security patterns), use parallel grep/glob calls to speed up the audit.
Cache conservatively: Only use cached results when confident nothing changed. When in doubt, rerun the phase. Production readiness must not be compromised for speed.
Suggest gitignoring cache: If .production-readiness/ is not in .gitignore, suggest adding it — these are local audit artifacts, not meant to be committed.
