Auditing a service's production readiness against Ring engineering standards across base dimensions plus a conditional multi-tenant dimension, then emitting a scored report and an HTML dashboard. Use before production deploy, periodic review, onboarding, or a major release. Skip for prototypes, libraries, or single-dimension checks.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Auditing a service's production readiness against Ring engineering standards across base dimensions plus a conditional multi-tenant dimension, then emitting a scored report and an HTML dashboard. Use before production deploy, periodic review, onboarding, or a major release. Skip for prototypes, libraries, or single-dimension checks.
Production Readiness Audit
When to use
Preparing a service for production deployment
Conducting periodic security or quality review of a codebase
Onboarding to assess codebase health and maturity
Evaluating technical debt before a major release
Validating compliance with Ring engineering standards
Skip when
Project is a prototype or throwaway proof-of-concept not heading to production
Codebase is a library or SDK with no deployable service component
User only needs a single-dimension check (use targeted review instead)
A multi-agent audit system evaluating 43 base dimensions + 1 conditional (multi-tenant) = up to 44 dimensions across 5 categories, aligned with Ring development standards. Detects project stack, loads relevant standards via WebFetch, runs explorers in batches of 10, appending results incrementally to a single report file.
Announce at start: "Using ring:auditing-production-readiness to audit {N} dimensions in 5 batches."
*Conditional on MULTI_TENANT detection. Max score: 430 base + 10 conditional = 440.
Execution Protocol
Step 0: Stack Detection
Glob("**/go.mod") → GO=true
Glob("**/package.json") → parse for React/Next (FRONTEND) or Express/Fastify (TS_BACKEND)
Glob("**/Dockerfile*") → DOCKER=true
Glob("**/Makefile") → MAKEFILE=true
Glob("**/LICENSE*") → LICENSE=true
Grep("MULTI_TENANT") → if found in env/config files: MULTI_TENANT=true
Step 0.5: Load Ring Standards
WebFetch based on detected stack. On failure, note and proceed with generic patterns.
Go stack: core.md, bootstrap.md, security.md, domain.md, api-patterns.md, quality.md, architecture.md, messaging.md, domain-modeling.md, idempotency.md from https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/golang/
If MULTI_TENANT: Also fetch multi-tenant.md from same base URL.
Always: devops.md and sre.md from https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/
Store fetched content for injection between ---BEGIN STANDARDS--- / ---END STANDARDS--- markers in each explorer prompt.
Step 1: Initialize Report File
Write header to docs/audits/production-readiness-{YYYY-MM-DDTHH:MM:SS}.md with detected stack, standards loaded, dimension count, and dynamic max score.
Step 2–6: Batch Execution
Read the dimension-specific prompts from dimensions/ subdirectory before dispatching each batch.
*Agent 33 (Multi-Tenant) only if MULTI_TENANT=true.
After each batch: Append all results to report file before launching next batch.
CRITICAL: Each batch dispatches in a SINGLE turn with N parallel Task calls.
⛔ STOP-CHECK BEFORE DISPATCH (each batch)
Before emitting any Task call in a batch, count the explorers you intend to launch in this turn.
Count MUST equal the batch size declared in the batch table above for the current batch.
If your dispatch count diverges from the batch size → STOP and reconcile against the batch row.
No substitutions, no omissions within a batch.
⛔ MUST NOT trickle-dispatch within a batch
All explorers in a batch leave in the SAME TURN, before reading any explorer output.
Forbidden sequences:
Dispatch explorer 1 → read result → dispatch explorer 2
Dispatch a subset of the batch → wait → dispatch the rest
Dispatch follow-up explorers conditioned on partial output
Loop sequentially over the batch's explorer list
If you find yourself about to dispatch an explorer in a turn AFTER any explorer in the SAME batch has already returned a result → STOP. You violated parallel dispatch. Report the violation and mark the batch INCOMPLETE rather than completing the trickle. (Sequential batch ordering is intentional; trickle within a batch is not.)
Self-verify after dispatch
After each batch's dispatch turn, verify all batched Task calls were emitted in that single turn. If fewer went out than the batch size, the batch did NOT execute correctly. Mark INCOMPLETE and surface the dispatch failure — do NOT silently continue with a partial batch.
Parallel dispatch — atomic batch (within this batch)
Emit all Task calls for THIS BATCH in a SINGLE TURN, as one atomic batch. (Batches themselves remain sequential — do not dispatch batch N+1 until batch N has fully returned.)
If your runtime exposes a multi_tool_use.parallel wrapper, use it to dispatch the complete batch in one wrapped invocation. This is the canonical fan-out mechanism on OpenAI-style tool envelopes and on certain Anthropic SDK consumers — naming it explicitly activates parallel emission on runtimes where trickle-dispatch is the default behavior.
If your runtime emits parallel tool_use blocks natively (Claude Code with Claude models), multi_tool_use.parallel may not be needed — but naming it is harmless and serves as an enforcement anchor.
The STOP-CHECK, anti-trickle, and self-verify guards above remain binding regardless of which mechanism your runtime uses.
Step 7: Consolidate Report
Read dimensions/scoring.md for scoring rules
Calculate scores per dimension (0-10), category totals, overall score
Summarize: stack detected, standards loaded, overall score/classification, critical/high counts, HARD GATE violations, top 3 recommendations, links to report and dashboard.
