Overview
Claude Coach reads organizational documentation, product specs, systems architecture, department notes, decision records, and transforms it into deterministic, department-scoped implementation guidance that a separate builder agent can execute against. It does not generate application code, and it does not make architectural decisions. Its entire job is synthesis: turning a documentation corpus that's grown organically across many conversations into something consistent enough to build from.
Problem
As AI-assisted projects grow, documentation accumulates across many separate conversations and many contributors, human and AI. Individually, each document is fine. Read together, they drift: two departments describe the same component slightly differently, an earlier decision gets contradicted by a later one and nobody notices, and a builder agent asked to implement directly from the raw corpus has to re-resolve those inconsistencies itself, inconsistently, every time it runs.
Philosophy
Claude Coach treats documentation as source material for compilation, not as instructions to follow directly. That distinction matters: a compiler doesn't improvise when it hits ambiguous source, it either resolves it against a fixed rule or refuses to proceed. Claude Coach is meant to behave the same way, favoring a smaller, internally consistent output over a larger one that quietly papers over contradictions in the source documentation.
When to Use It
- Documentation for a project or department has matured enough that it's stable, not still actively being debated.
- Multiple documents need to be reconciled into one consistent implementation guide before a builder agent starts work.
- You want an explicit, inspectable synthesis step between planning and execution, rather than having implementation agents interpret raw documentation on every run.
It is not the right tool for early-stage brainstorming, for writing the documentation itself, or for making product or architecture decisions those stay entirely upstream of it.
Expected Inputs
A documentation corpus organized by department or domain (product, systems, backend, UX, infrastructure, etc.), written in Markdown, accumulated across one or more conversations or contributors.
Expected Outputs
Deterministic, department-scoped implementation guidance files. Where the source documentation contains direct contradictions, Claude Coach surfaces them explicitly rather than silently resolving them in one direction.
Example Workflow
Installation
Limitations
- Compilation quality depends entirely on the quality and consistency of the source documentation it cannot invent context that was never written down.
- No formal enforcement layer exists yet to guarantee the compiled output stays faithful to the source; today that's checked by review, not by the skill itself.
- Experimental behavior on very large, multi-year documentation corpora is untested.