Capability map

Drafts docs/capability-map.md, a single page that maps the domain of a project. It lists every capability the system has, what each one owns, which words it uses, and what it is not. People and agents read it to answer "what lives here, and what do we call it?" before opening the code.

An agent doesn't know the client's words. It fills the gap with the most common name it has seen, such as Cart, Asset or User, and that name spreads through the code, the API and the screens. The map gives every session the client's words, and the boundaries between the parts of the system.

This skill drafts; people decide

The two most important things in a capability map come from people, not from the code:

• the language: the words the client uses for its own business;
• the "Is not" lines: where one capability ends and the next begins, as the team understands it.

So the skill does not hand over a finished map. It hands over a draft and a list of questions. Every word the code and the documents disagree on, and every boundary the code doesn't make clear, goes into the questions instead of being settled by the agent.

The skill also:

• fixes nothing. Gaps found while mapping (permissions nobody checks, wrong glossary entries) are recorded, not fixed;
• doesn't commit.