ab-method: Skill for Claude Code

Change Map (pre- and post-implementation)

The artifact that answers "where in the codebase does this task live?" — asked twice, on purpose:

• Planned — before a line is written, from the missions: which modules the task expects to add, change, or brush against.
• Actual — after the missions are green and the reviewers have passed, from the real diff: which modules it did.
• Drift — the difference between them. Drift is the deliverable; the two maps exist so it can be computed at all.

Where the other post-implementation skills judge the change — ../review-implementation/SKILL.md asks "is this good code?", ../sync-architecture/SKILL.md asks "do the docs know about it?" — this one only describes its shape. It never reviews code, never edits code, never edits the architecture docs.

Reduction is the point. A task that touched 40 files gets 6 rows; the cap is 10. A map that reads as an inventory of the diff has failed — the tracker's mission summaries already list the files. The map exists to be understood in seconds, months later, by someone who will not read the diff.

ALWAYS check .ab-method/structure/index.yaml FIRST for where tasks and the architecture/domain docs live — paths are user-configurable. The rendering rules, the line types, and a full worked file live in DIAGRAM-FORMAT.md; read it before drawing either pass.

What counts as a module here

Not "a directory". The map partitions the codebase the way this project partitions it, in this order:

1. CONTEXT.md / CONTEXT-MAP.md — the bounded contexts, named in the project's own ubiquitous language. Best source by far: the map then speaks the domain, and a row nobody predicted reads as a context boundary being crossed, not as "another folder changed".
2. docs/architecture/* — documented entry points, layers, and pattern groupings.
3. The source tree — top-level source directories, one level deeper where a directory is large.