Product maturity stage management — defines quality gates for Prototype, Pilot, Candidate, and Production stages. Use when: starting a new project, during discovery phase, before deployment, when deciding what to test or secure, when promoting between environments, or when the user asks 'is this ready for production'.
From cksnpx claudepluginhub cardinalconseils/claude-starter --plugin cksThis skill is limited to using the following tools:
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Four maturity stages define what quality gates apply at each point in a product's lifecycle. This prevents both over-engineering prototypes and under-engineering production systems. Every project has a current stage — know it, enforce it, promote deliberately.
Ask the user or infer from project state. When uncertain, ask:
What stage is this project at? (Prototype / Pilot / Candidate / Production)
| Requirement | Status |
|---|---|
| Happy path works end-to-end | Required |
| Basic error handling (no crashes) | Required |
| Hardcoded configs | Acceptable |
| Authentication | Optional (basic if needed) |
| Deep testing | Skip |
| Monitoring, CI/CD | Skip |
| Security hardening | Skip |
Goal: Prove the idea works. Nothing else matters yet.
| Requirement | Status |
|---|---|
| Authentication (min email/password) | Required |
| Input validation on all forms | Required |
| Error pages (404, 500, generic) | Required |
| HTTPS, no secrets in code, parameterized queries | Required |
| Environment separation (dev + prod minimum) | Required |
| Full test suite | Skip |
| Performance optimization | Skip |
| Accessibility audit | Skip |
Goal: Safe enough for real humans. Not polished, but not dangerous.
| Requirement | Status |
|---|---|
| Full test suite (unit + integration + key E2E) | Required |
| Performance baseline (Core Web Vitals measured) | Required |
| Accessibility audit (WCAG 2.1 AA basics) | Required |
| CI/CD pipeline (build + test + deploy) | Required |
| Monitoring (error tracking + health endpoint) | Required |
| Database migrations tested | Required |
| API documentation | Required |
Goal: Could ship tomorrow. Gaps are known and tracked.
| Requirement | Status |
|---|---|
| Security hardening (OWASP Top 10, dependency audit, CSP) | Required |
| Observability (structured logging, error tracking, uptime, alerting) | Required |
| Backup and recovery plan | Required |
| Rollback procedure documented and tested | Required |
| Load testing results | Required |
| Documentation (README, API docs, ADRs) | Required |
| Incident response plan | Required |
Goal: Survives failure, scales under load, recoverable by anyone on the team.
To promote from one stage to the next:
| Rationalization | Reality |
|---|---|
| "We'll add tests before launch" | You will not. Test debt compounds. |
| "It's just a prototype, security doesn't matter" | Prototypes become pilots overnight. Build the habit early. |
| "Monitoring can wait" | You cannot fix what you cannot see. |
| "We don't need rollback for this" | Every deployment that cannot roll back is a bet against Murphy. |
| "Documentation is for later" | Later never comes. Document as you build. |