The Claude Code Engineering Playbook

The common mistake is layer selection

Most teams that struggle with Claude Code are not misconfiguring it. They are reaching for the wrong layer. A workflow the agent keeps forgetting gets written as a longer prompt when it should be a skill. A policy that must hold every time gets written as a skill when it should be a hook. A task that pollutes the main session gets run inline when it should be a subagent.

The layers are not interchangeable and they are not a hierarchy of sophistication. They differ on one axis that matters more than any other: enforceability. A skill is a suggestion the model may follow. A hook is a gate it cannot see and cannot argue with. Confusing those two is where most production agent failures come from, because it produces a system whose safety guarantees are probabilistic while everyone believes they are absolute.

This playbook works through each layer, what it is genuinely for, and how to tell which one your problem needs.

Operating model, not configuration

The other half of the series is about running the thing. Context engineering determines whether the agent can do the task at all — prompt engineering tells the model what to do, context engineering decides whether it is equipped to. Subagents let you parallelise inside a session without poisoning the parent’s context. Observability is how you find out what actually happened, since most Claude Code failures leave no trace by default. Testing tells you whether your setup produces consistently good output, which skill-level evals cannot.

And when the human leaves the loop entirely — headless runs in CI — every safety net that depends on a person is gone: no approval, no rewind, nobody reading the output. What is left is exactly what you enforced in advance. That is the sharpest possible statement of the series’ argument, which is why it comes last.