production-readiness-review

Audits a repository for production readiness with parallel reviewers, secrets scanning, and a go/no-go verdict.

10|1|Updated Jul 7, 2026
One-click install
npx skills add https://github.com/catalystctl/catcode --skill production-readiness-review-catalystctl
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: production-readiness-review
Source: https://github.com/catalystctl/catcode/tree/main/.catalyst-code/skills/production-readiness-review
Command: npx skills add https://github.com/catalystctl/catcode --skill production-readiness-review-catalystctl

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Before making a repository public or cutting a release, teams need confidence that no secrets, PII, or broken builds slip through. This Skill orchestrates a structured pre-launch audit so nothing critical is missed. ## Core Features & Use Cases - Parallel Review Fan-Out: Spawns 3-4 subagents covering per-language code review, a repo-wide secrets/PII scan, and a build/test/lint gate. - Verified Secrets Audit: Re-runs the secrets scan directly with ripgrep patterns for tokens, private keys, personal paths, and tracked local-only files rather than trusting truncated subagent summaries. - Go/No-Go Synthesis: Deduplicates findings across reviewers, ranks them as P0 blockers, P1 should-fix, and P2 nice-to-have, and leads with an explicit verdict. - Use Case: Before flipping a private repo to public, ask for a production readiness review to catch a hardcoded API key, confirm CI gates pass, and receive a prioritized fix list. ## Quick Start Ask the agent to run a production readiness review of this repository before making it public.

Frequently Asked Questions about production-readiness-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if my repo is ready to go public?

Run a production readiness review that fans out parallel reviewers for code quality, a repo-wide secrets/PII scan, and a build/test/lint gate. The result is a go/no-go verdict with findings ranked as P0 blockers, P1 should-fix, and P2 nice-to-have.

How to scan a git repository for leaked secrets and API keys?

Use ripgrep with the --hidden flag to search for patterns like sk- tokens, AKIA keys, GitHub tokens, private key blocks, and personal file paths. Also check git ls-files for tracked .env, .pem, .key, and log files that should not be committed.

What is the difference between a production readiness review and a general code review?

A production readiness review adds three launch-specific checks beyond general code quality: a secrets/PII audit, a build and test gate matching CI, and an explicit go/no-go verdict. General reviews focus on bugs and code quality without the public-launch stakes.

Why should I re-verify secrets scan results from subagents?

Subagent detailed reports can be truncated to one-line summaries in parallel task results, losing critical evidence. For high-stakes claims like secrets being clean, re-run the scan yourself with ripgrep to confirm before reporting.

When should I not use a full production readiness review?

Skip it for targeted reviews of a single file or feature, which you can read directly, and for general bug hunts without a public-launch angle. A single component needs only one reviewer, not a multi-agent fan-out.