---
name: phased-build-harness
description: House rules that make AI-written code safe to ship when many people in one company build with Claude Code. One approved stack, a PRD split into phases, a test for every feature, a checkpoint after every phase, and deploys only to the company's own cloud account. Use before anyone on a team starts building an internal tool with an AI coding agent.
---

# Phased Build Harness

> **Where this came from.** Distilled by Calvin (Colton Mulligan's Claude) from Jeff Schneider's demo of his team's harness, Salt Air, at AI Open House, Session 002, 15:46 in the recording: https://aiopenhouse.co/sessions/002/?t=946
> This is a reconstruction of the pattern Jeff explained on the call, not Jeff's own rule files. Credit Jeff if you use it. Shared under CC BY 4.0.

## Why this exists

Coding agents are built for speed. Ask for 50 features and one may build 30, then tell you it's done, and you won't know which 30. When everyone in a company builds with AI, you also get one person on one database and another on a different one, and tools living on a laptop that disappears when that person leaves. A harness fixes all three by making the rules the agent's job, not the human's memory.

## The rules (put these in the project's CLAUDE.md or AGENTS.md)

### 1. One approved stack
- Use only the database, language, framework, and hosting listed in `STACK.md`. Do not introduce anything else without a human approving it.
- If a requirement can't be met with the approved stack, stop and say so.

### 2. The company owns everything
- Everything deploys to the company's own cloud account (Jeff's team uses Azure). Never a personal account, never a free host.
- Code lives in the company's repository, never only on this machine.
- Deploying is limited to the people allowed to deploy.

### 3. Start from a PRD, then phase it
- Read the product requirements document first.
- Break the build into numbered phases, each with a short list of features and a definition of done. Show the plan and wait for a yes.

### 4. Every feature gets a test
- No feature is written without a test that proves it works.
- Keep a feature ledger (`FEATURES.md`): feature, test name, status (planned, built, tested, verified). "Done" means verified, never "I wrote it."

### 5. A checkpoint after every phase
- At the end of each phase, run the full test suite and report what passed, what failed, and what is still planned.
- The human can test the phase or say "keep going." Never skip the report.

### 6. Secrets come from a human
- If an API key or credential is needed (Jeff's example: a US Census API key), stop and ask for it. Never invent one, never hard-code one, never commit one.

## What it bought Jeff

A ten-phase build runs about six to eight hours with testing at every phase, and up to thirty people in the company can build real software instead of one or two developers. His first build on it: a benchmarking tool that pulls public Census data to compare nearby rural hospitals.