# Code Production Process

> Production-readiness process checklist covering the code-production pipeline — research, architecture, implementation, tests, critic review, and security gates

- Skill: `bobmatnyc/code-production-process-3` (Agent Skill)
- Install (CLI): `npx skillmds@latest add bobmatnyc/code-production-process-3`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bobmatnyc/code-production-process-3/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- License: MIT
- Author: bobmatnyc (https://skillmd.com/u/bobmatnyc)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/bobmatnyc/code-production-process-3

---


# Code Production Process

## Overview

A six-stage quality-gate pipeline that every non-trivial implementation passes through before
being declared complete. Each stage produces a concrete artifact and must clear a defined gate
before the next begins. The pipeline exists because quality must be enforced by automated gates
inside the agent pipeline, not by human review after the fact. The critic operates in isolated
context to prevent anchoring bias from the implementer's framing.

## Trigger Conditions

Triggers when the task will produce >50 lines of source, touch >1 source file, or contains
implementation verbs ("implement", "build", "refactor", "fix bug in ..."). Also triggers
post-dispatch if `git diff --stat` shows source changes. Does NOT trigger for documentation,
commit messages, config-only changes, or dependency bumps. When in doubt, trigger — a false
positive costs one critic dispatch; a false negative ships broken code.

## The Six Stages

| Stage | Agent | Artifact | Gate |
|-------|-------|----------|------|
| 1. Research | research | Spec citing existing code | Spec exists, references prior code, NO implementation |
| 2. Architect | engineer (design mode) | Interface spec (signatures, types, error model) | Interface exists, ZERO implementation logic |
| 3. Implement | engineer | Source + tests | Type checker and tests output provided, zero errors |
| 3.5 Tests gate | PM | (evaluation) | Tests pass green — failing tests return to Stage 3, skip critic |
| 4. Critic | code-critic | Verdict + finding table | Verdict returned (see `code-review-standards`) |
| 5. Security | security | Finding list | Zero CRITICAL/HIGH security findings |

## Critic Isolation Rule

The critic dispatch MUST contain only the spec, the interface, the implementation, and the
test output. It MUST NOT contain the engineer's commit message, stated rationale, or any PM
summary of what the engineer did. An engineer who pre-argues ("I chose this because the
alternative is slower") subtly disarms the critic. The critic must encounter the code cold.

## Verdict Protocol

- **APPROVE** (no CRITICAL/HIGH): proceed to security; pass MEDIUM/LOW notes to docs handoff.
- **WARN** (HIGH, no CRITICAL): proceed to security, but append finding table to handoff and
  log it — never silently drop HIGH findings.
- **BLOCK** (any CRITICAL): halt, surface findings verbatim to the user, await direction. Do
  NOT auto-re-dispatch the engineer without user input.

## Skip Rules

- **Standard path:** all 6 stages (required for features, refactors, auth, data models).
- **Hotfix path:** stages 1-2 skippable only when the bug is confirmed in production, the fix
  is <=20 lines across <=2 files, and it does not touch auth/crypto/serialization. Stages 3-5
  remain mandatory.
- **Docs/config-only path:** all stages skipped when `git diff --stat` shows no source changes.