harness-engineeringlisted

# Harness Engineering Agent = Model + Harness. The model can't execute code, remember past sessions, or know the current state of anything — a raw model is not an agent. The harness is everything around the model that makes it one: the docs it reads, the tools it can call, the checks that catch its mistakes, the places it's allowed to write, and the record it leaves behind. If the model is the brain, the harness is the body. There are two layers of harness. The **builder harness** — the agent loop, tool schemas, context compaction, sandboxing — is implemented by whoever builds the agent (Anthropic, in Claude Code's case) and isn't yours to redesign. This skill is about the **user harness**: the repo-level scaffolding any team can build on top of that to get reliable results on their own codebase. Don't reach for a builder-level explanation ("the agent loop should really...") when the actual gap is a missing doc or check you can fix today. **Your job when this skill triggers is not to run a checklist top to bottom.** It's to look at the actual project — its size, language, risk profile, team, and where agents are currently failing — and decide which of the principles below are worth applying now, in what order, and at what weight. A 200-line CLI tool and a payments backend need very different harnesses. Recommend the minimum that closes the gap you actually observe; don't scaffold for problems the project doesn't have. ## How to use this skill 1. **Diagnose before prescri