Living Product Specification

Use this capability to keep a project's own description of its product — what it is, the language its domain speaks, how it currently behaves, and the decisions that constrain it — true as the code changes, and to read that description before planning a change rather than discovering it afterwards.

The weight is on upkeep. Documentation that is only ever created is a liability: it accumulates claims nobody re-checks, and a reader cannot tell which of them still hold. What makes it worth keeping is a mechanism that corrects it, tied to the change that invalidated it. That mechanism is the whole subject here; creating documents is the small part.

Two claims this capability does not make. It does not promise to make an agent better at its task — the evidence for context files improving task success is weak, and the design below assumes a body is read only when a task needs it, rather than loaded on every turn. And it does not drive development from a specification: the plan drives the change, and what becomes true is recorded here once it lands.