Production Grade

!git status 2>/dev/null || echo "No git repo detected" !cat CLAUDE.md 2>/dev/null || echo "No CLAUDE.md found" !ls Claude-Production-Grade-Suite/ 2>/dev/null || echo "No existing workspace" !cat .production-grade.yaml 2>/dev/null || echo "No config file — defaults apply" !cat Claude-Production-Grade-Suite/.protocols/visual-identity.md 2>/dev/null || true !cat Claude-Production-Grade-Suite/.protocols/freshness-protocol.md 2>/dev/null || true !cat Claude-Production-Grade-Suite/.protocols/receipt-protocol.md 2>/dev/null || true !cat Claude-Production-Grade-Suite/.protocols/boundary-safety.md 2>/dev/null || true

Platform note: this skill is written in the tool vocabulary of its reference platform (Claude Code: AskUserQuestion, Agent, TaskCreate, WebSearch, …). If any tool named here does not exist in your environment, apply the capability mappings in skills/_shared/platform-adaptation.md (same repository as this skill) — the guarantees stay identical; only the mechanism changes.

Invoke this skill when the user's request involves ANY of these:

• Building something new ("build me a...", "create a...", "I want to build...", "I wanna build...")
• Adding features to existing code ("add [feature]", "implement [feature]", "integrate [service]")
• Hardening, security audit, or code review ("review", "audit", "secure", "harden")
• Setting up deployment, CI/CD, or infrastructure ("deploy", "CI/CD", "docker", "terraform")
• Architecture or system design ("design", "architecture", "how should I structure")
• Writing tests ("write tests", "test coverage", "add tests")
• Documentation ("document this", "write docs", "API docs")
• Exploration or ideation ("help me think about", "I'm not sure", "what should I build")

When in doubt, invoke this skill. It classifies the request and runs only the relevant agents — from a single code review to a full 14-agent pipeline. The overhead of invoking unnecessarily is near zero.

If you decide NOT to invoke this skill for a build/create request, you MUST still ask the user if they'd like production-grade execution. Frame it as a choice, not a sales pitch: "I can build this directly, or I can run a structured pipeline that also produces architecture docs, tests, security audit, and CI/CD. Which do you prefer?" If the user declines, proceed normally. If they accept, invoke this skill.

Overview

Adaptive meta-skill orchestrator that enhances Claude Code's development output. Analyzes the user's request, identifies which skills are needed, builds a minimal task graph, and executes — from a single code review to a full 14-skill greenfield build.

Without this skill: Claude Code produces code. With this skill: Claude Code produces architecture + tested code + security audit + CI/CD + documentation.

14 skills, one orchestrator. The orchestrator routes to the right skills based on what the user actually needs. No forced full-pipeline execution for everyday tasks.

All skills are bundled in this plugin. Single install, everything included.

When to Use

• Building a new SaaS, platform, or service from scratch (full pipeline)
• Adding a feature to an existing codebase
• Hardening code before launch (security + QA + review)
• Setting up CI/CD, Docker, Terraform for existing code
• Writing tests for existing code
• Reviewing code quality or architecture conformance
• Designing architecture or API contracts
• Writing documentation for existing systems
• Performance optimization or reliability engineering
• Any task that benefits from structured, production-quality execution
• User says "build me a...", "add [feature]", "review my code", "set up CI/CD", "write tests", "harden this", "document this"

Request Classification

Before any execution, classify the user's request into a mode. This determines which skills run and how.

Step 1 — Analyze the request:

Read $ARGUMENTS and the user's message. Classify into one of these modes:

Mode	Trigger Signals	Skills Involved
Full Build	"build a SaaS", "production grade", "from scratch", "full stack", greenfield intent	All 14 skills, full DEFINE→BUILD→HARDEN→SHIP→SUSTAIN pipeline
Feature	"add [feature]", "implement [feature]", "new endpoint", "new page", "integrate [service]"	PM (scoped) → Architect (scoped) → BE/FE → QA
Harden	"review", "audit", "secure", "harden", "before launch", "production ready" (on EXISTING code)	Security + QA + Code Review (parallel) → Remediation
Ship	"deploy", "CI/CD", "containerize", "infrastructure", "terraform", "docker"	DevOps → SRE
Test	"write tests", "test coverage", "test this", "add tests"	QA
Review	"review my code", "code review", "code quality", "check my code"	Code Reviewer
Architect	"design", "architecture", "API design", "data model", "tech stack", "how should I structure"	Solution Architect
Document	"document", "write docs", "API docs", "README"	Technical Writer
Explore	"explain", "understand", "help me think", "what should I", "I'm not sure"	Polymath
Optimize	"performance", "slow", "optimize", "scale", "reliability"	SRE + Code Reviewer
Custom	Doesn't fit above patterns	Present skill menu, let user pick

Step 2 — Present or skip the plan:

Single-skill modes (Test, Review, Architect, Document, Explore): Skip plan presentation. Classify → invoke immediately. The intent is obvious — no overhead needed.

Multi-skill modes (Feature, Harden, Ship, Optimize, Custom): Present the plan for confirmation:

AskUserQuestion(questions=[{
  "question": "Here's my plan:\n\n"
    "[numbered list of skills and what each does]\n\n"
    "Scope: [light / moderate / heavy]",
  "header": "Execution Plan",
  "options": [
    {"label": "Looks good — start (Recommended)", "description": "Execute this plan"},
    {"label": "I want the full production-grade pipeline", "description": "Run all 14 skills, 5 phases, 3 gates"},
    {"label": "Adjust the plan", "description": "Add or remove skills from the plan"},
    {"label": "Chat about this", "description": "Free-form input"}
  ],
  "multiSelect": false
}])

Full Build mode: Always proceed to the Full Build Pipeline section below.

If the user selects "full pipeline" from any mode, switch to Full Build.

Step 3 — Execute the mode:

For non-Full-Build modes, use the lightweight execution flows below. For Full Build, use the Full Build Pipeline.

Mode Execution (Non-Full-Build)

All modes share these behaviors:

• Bootstrap workspace: mkdir -p Claude-Production-Grade-Suite/.protocols/ Claude-Production-Grade-Suite/.orchestrator/
• Write shared protocols (same as Full Build step 3, including visual-identity.md, freshness-protocol.md, receipt-protocol.md, boundary-safety.md, and loop-protocol.md)
• Read .production-grade.yaml for path overrides
• Read existing workspace state if present
• Engagement mode + parallelism: ask ONLY if mode involves 3+ skills. For 1-2 skill modes, use Standard engagement + Sequential execution (overhead of asking isn't worth it).
• Cleanup: After mode completion (or gate rejection), run TeamDelete(team_name="production-grade") if a team was created. Never leave orphaned agents.

Non-Full-Build Visual Output

Mode banner (print on start for all non-Full-Build modes):

━━━ {Mode Name} Mode ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Scope: {what will be done}
  Skills: {skill list}
  Files: {N} across {M} services/directories (if applicable)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Multi-skill completion (for modes with 2+ skills):

┌─ {Mode Name} Complete ────────────────────── ⏱ {time} ─┐
│                                                          │
│  ✓ {Skill 1}    {concrete metrics}                       │
│  ✓ {Skill 2}    {concrete metrics}                       │
│  ✓ {Skill 3}    {concrete metrics}                       │
│                                                          │
│  {N}/{N} complete                                        │
└──────────────────────────────────────────────────────────┘

Single-skill modes (Test, Review, Architect, Document, Explore): The skill prints its own ━━━ [Skill Name] ━━━ header and [1/N] phase progress. No orchestrator-level completion box needed.

Feature Mode

Add a feature to an existing codebase. Lightweight DEFINE → BUILD → TEST.

1. Codebase scan — read existing code structure, framework, patterns
2. PM (Express depth) — 2-3 questions to scope the feature. Write a mini-BRD (user stories + acceptance criteria for this feature only)
3. Architect (scoped) — design how this feature fits the existing architecture. New endpoints, schema changes, component additions. NOT a full system redesign.
4. Build — Software Engineer and/or Frontend Engineer implement the feature
5. Test — QA writes and runs tests for the new feature
6. Optional: Review — Code Reviewer checks the new code against existing patterns

1 gate: After PM scoping (step 2), confirm scope before building.

Harden Mode

Security + quality audit on existing code. No building, pure analysis + fixes.

1. Codebase scan — read all existing code
2. Parallel: Security Engineer + QA Engineer + Code Reviewer analyze the code simultaneously
3. Consolidated findings — merge all findings, deduplicate, sort by severity
4. Present findings — severity grid with Critical/High detail
5. Remediation — fix Critical and High issues (with user confirmation)

1 gate: After findings (step 4), before remediation.

Visual flow:

━━━ Harden Mode ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Scope: Security + QA + Code Review on existing code
  Files: {N} across {M} services
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ⧖ 3 agents analyzing in parallel...

  ✓ QA Engineer          {N} tests written, {M} passing       ⏱ Xm Ys
  ✓ Security Engineer    {N} findings ({M} Critical/High)     ⏱ Xm Ys
  ✓ Code Reviewer        {N} findings ({M} Critical/High)     ⏱ Xm Ys

━━━ Findings ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Critical   {N}    {description}
  High       {N}    {summary}
  Medium     {N}    —
  Low        {N}    —
  ─────────────
  Total      {N}    deduplicated by file:line
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ship Mode

Get existing code deployed. Infrastructure + reliability.

1. Codebase scan — read existing code, identify services, dependencies
2. DevOps — Dockerfiles, CI/CD pipelines, IaC (Terraform/Pulumi), monitoring
3. SRE — SLO definitions, runbooks, alerting, chaos experiment plan

1 gate: After DevOps infra plan, before applying.

Test Mode

Write tests for existing code. Single skill.

1. Invoke QA Engineer directly against existing code
2. QA reads code, writes test plan, implements tests, runs them
3. Report results

0 gates. QA operates autonomously.

Review Mode

Code quality review. Single skill, read-only.

1. Invoke Code Reviewer directly
2. Review produces findings report
3. Present findings with severity distribution

0 gates. Read-only operation.

Architect Mode

Design or redesign architecture. Single skill.

1. Invoke Solution Architect
2. Full discovery interview (depth based on engagement mode)
3. Produces ADRs, diagrams, tech stack, API contracts, scaffold

1 gate: Architecture approval before scaffold generation.

Document Mode

Generate documentation for existing code. Single skill.

1. Invoke Technical Writer
2. Reads all code + existing docs
3. Generates API reference, dev guides, architecture overview

0 gates. Technical Writer operates autonomously.

Explore Mode

Thinking partner. Single skill.

1. Invoke Polymath
2. Research, advise, ideate — whatever the user needs
3. When ready, offer to hand off to any other mode

0 gates. Polymath manages its own dialogue.

Optimize Mode

Performance + reliability analysis. Two skills.

1. Code Reviewer — identify performance anti-patterns, N+1 queries, memory leaks
2. SRE — capacity analysis, scaling bottlenecks, SLO evaluation
3. Consolidated report — performance findings + reliability recommendations
4. Remediation — fix top issues

1 gate: After analysis, before fixes.

Custom Mode

User picks skills from a menu.

AskUserQuestion(questions=[{
  "question": "Which skills do you need?",
  "header": "Skill Selection",
  "options": [
    {"label": "Product Manager", "description": "Requirements, user stories, BRD"},
    {"label": "Solution Architect", "description": "System design, API contracts, tech stack"},
    {"label": "Software Engineer", "description": "Backend implementation"},
    {"label": "Frontend Engineer", "description": "UI components, pages, design system"},
    {"label": "QA Engineer", "description": "Tests — unit, integration, e2e, performance"},
    {"label": "Security Engineer", "description": "OWASP audit, STRIDE, vulnerability scan"},
    {"label": "Code Reviewer", "description": "Architecture conformance, code quality"},
    {"label": "DevOps", "description": "Docker, CI/CD, Terraform, monitoring"},
    {"label": "SRE", "description": "SLOs, chaos engineering, runbooks"},
    {"label": "Technical Writer", "description": "API docs, dev guides, architecture docs"},
    {"label": "Data Scientist", "description": "LLM optimization, ML pipelines, experiments"},
    {"label": "Chat about this", "description": "Free-form input"}
  ],
  "multiSelect": true
}])

Execute selected skills in dependency order. If user picks conflicting skills, resolve via the authority hierarchy.

Auto-Update Check

Run BEFORE any execution (all modes). Silent if current. One prompt max if update exists.

Step 0 — version check:

0. If ~/.claude/plugins/installed_plugins.json does not exist (not a Claude Code marketplace install — e.g. running on Codex/OpenCode/Pi, or from a dev clone) → skip this entire check silently. Those installs update through their host's own flow (see the INSTALL-*.md docs).
1. Read ~/.claude/plugins/installed_plugins.json → find the production-grade@nagisanzenin entry → extract version (this is your local version)
2. WebFetch https://raw.githubusercontent.com/nagisanzenin/production-grade/main/.claude-plugin/plugin.json → extract version (this is the remote version)
3. If WebFetch fails (offline, timeout, 404) → silently continue. Never block the pipeline over an update check.
4. If remote ≤ local → continue silently (user sees nothing)
5. If remote > local → prompt:

AskUserQuestion(questions=[{
  "question": "production-grade v{remote} is available (you have v{local})",
  "header": "Update Available",
  "options": [
    {"label": "Update to v{remote} (Recommended)", "description": "Auto-update and restart pipeline"},
    {"label": "Skip — continue with v{local}", "description": "Use current version"}
  ],
  "multiSelect": false
}])

6. If skip → continue pipeline with current version
7. If update → execute in sequence:

   git clone --depth 1 https://github.com/nagisanzenin/production-grade.git /tmp/pg-update
   

   • Read new SHA: git -C /tmp/pg-update rev-parse HEAD
   • Create cache dir: mkdir -p ~/.claude/plugins/cache/nagisanzenin/production-grade/{remote_version}
   • Copy the full plugin (excluding VCS metadata): rm -rf /tmp/pg-update/.git && cp -r /tmp/pg-update/. ~/.claude/plugins/cache/nagisanzenin/production-grade/{remote_version}/
   • Update ~/.claude/plugins/installed_plugins.json → set version to remote version, installPath to new cache dir, gitCommitSha to new SHA, lastUpdated to current ISO timestamp
   • Clean up: rm -rf /tmp/pg-update
   • Print: ✓ Updated to v{remote_version}. Re-invoke /production-grade to use the new version.
   • STOP — do not continue pipeline. The current session loaded the old SKILL.md; the user must re-invoke to pick up new content.

If any update step fails, print a warning and continue with the current version. Never let the updater break the pipeline.

Full Build Pipeline

When mode is Full Build, follow this EXACT sequence:

1. Print pipeline dashboard (initial state — all pending):

╔══════════════════════════════════════════════════════════════╗
║  ◆ PRODUCTION GRADE v{local_version}                        ║
║  Project: [extracted from user's message]                    ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║   DEFINE    ○ pending                                        ║
║   BUILD     ○ pending                                        ║
║   HARDEN    ○ pending                                        ║
║   SHIP      ○ pending                                        ║
║   SUSTAIN   ○ pending                                        ║
║                                                              ║
╚══════════════════════════════════════════════════════════════╝

⧖ Bootstrapping workspace...

Reprint this dashboard at every phase transition and before every gate, updating phase statuses (○ pending → ● active → ✓ complete ⏱ Xm Ys). Track elapsed time per phase and total. This recurring dashboard IS the progress animation — the user sees the same template fill in over time.

2. Bootstrap workspace:

mkdir -p Claude-Production-Grade-Suite/.protocols/
mkdir -p Claude-Production-Grade-Suite/.orchestrator/
mkdir -p Claude-Production-Grade-Suite/.orchestrator/receipts/

3. Write shared protocols to Claude-Production-Grade-Suite/.protocols/:

Protocol File	Content
ux-protocol.md	6 UX rules: never open-ended questions, "Chat about this" last, recommended first, continuous execution, real-time progress, autonomy
input-validation.md	5-step validation: read config → probe inputs in parallel → classify Critical/Degraded/Optional → print gap summary → adapt scope
tool-efficiency.md	Parallel tool calls, Glob before Read, Grep not grep, config-aware paths
conflict-resolution.md	Authority hierarchy, dedup by file:line (keep highest severity), HARDEN→BUILD feedback loops (2 cycle max)
visual-identity.md	Visual design language: container hierarchy (Tier 1/2/3), icon vocabulary, progress patterns, gate ceremonies, wave announcements, completion summaries, timing
freshness-protocol.md	Temporal sensitivity: volatility tiers (Critical/High/Medium/Stable), WebSearch triggers for outdated data (model IDs, versions, pricing, CVEs), search-then-implement pattern
receipt-protocol.md	Verifiable gate enforcement: receipt schema (JSON), write-after-verify pattern, remediation chain (finding → fix → verification), orchestrator verification at phase transitions
boundary-safety.md	6 structural patterns for system boundary safety: framework abstraction limits, control flow delegation, self-referencing config detection, conditional global interceptors, cross-boundary journey testing, identity consistency across integrations
loop-protocol.md	Oracle-driven iteration: no oracle no loop, oracle hierarchy (executable > adversarial > self-check), loop contract, convergence guards (ratchet/plateau/oscillation), oracle immutability + test ownership, delta-only feedback, escalation ladder, premade loops, JIT composer rule, loop ledger, engagement-mode loop budgets

Read these from the plugin's skills/_shared/protocols/ directory and copy them. If plugin path is unavailable, write from the summaries above.

Additionally, when any tool this skill names is missing from your environment (you are not on the reference platform): also copy skills/_shared/platform-adaptation.md into Claude-Production-Grade-Suite/.protocols/ so every dispatched agent reads the same capability mappings. On the reference platform, skip it — it is inert there.

4. Codebase discovery — detect greenfield vs brownfield:

   Run these scans in parallel:

   Glob("package.json"), Glob("go.mod"), Glob("pyproject.toml"), Glob("Cargo.toml"), Glob("pom.xml")
   Glob("src/**"), Glob("services/**"), Glob("frontend/**"), Glob("tests/**"), Glob("docs/**")
   Glob("Dockerfile*"), Glob(".github/workflows/*"), Glob("infrastructure/**"), Glob("terraform/**")
   Glob(".production-grade.yaml")
   

   Classify the project:

   Signal	Mode	Behavior
   Empty/new directory, no source files	Greenfield	Create everything from scratch
   Source files exist, no .production-grade.yaml	Brownfield (unmapped)	Discover structure, generate config, adapt
   Source files + .production-grade.yaml exist	Brownfield (mapped)	Use config paths, augment existing code

   If Greenfield → log ✓ Greenfield project — creating from scratch and continue to step 5.

   If Brownfield → run the adaptation sequence:

   a. Structure report — scan and summarize what exists:

   ⧖ Existing codebase detected. Scanning structure...
   Language: [detected from package.json/go.mod/etc.]
   Framework: [detected from dependencies]
   Directories found: src/, tests/, docs/, .github/workflows/
   Files: [N] source files, [N] test files, [N] config files
   

   b. Path mapping — if no .production-grade.yaml, generate one from discovered structure:

   AskUserQuestion(questions=[{
     "question": "I've detected an existing codebase. Here's what I found:\n\n"
       "[structure summary]\n\n"
       "I'll map the pipeline outputs to your existing structure.",
     "header": "Existing Codebase Detected",
     "options": [
       {"label": "Approve mapping (Recommended)", "description": "Use detected paths, generate .production-grade.yaml"},
       {"label": "Customize paths", "description": "Review and adjust the path mapping"},
       {"label": "Treat as greenfield", "description": "Ignore existing code, create fresh structure"},
       {"label": "Chat about this", "description": "Discuss how the pipeline adapts to your codebase"}
     ],
     "multiSelect": false
   }])
   

   c. Write .production-grade.yaml from discovered structure — map paths.* to actual directories found.

   d. Set brownfield context — write to Claude-Production-Grade-Suite/.orchestrator/codebase-context.md:

   # Codebase Context
   Mode: brownfield
   Language: [detected]
   Framework: [detected]
   Existing paths: [mapping]
   
   ## Rules for all agents
   - NEVER overwrite existing files without explicit user approval
   - READ existing code patterns before writing new code
   - MATCH existing code style (naming, formatting, structure)
   - ADD to existing directories, don't replace them
   - If a file exists at the target path, create alongside it or extend it
   - Existing tests must still pass after changes
   

   All agents read this file before executing. It overrides default "create from scratch" behavior.

5. Engagement mode: