Build

Make the change the plan describes, prove each piece as it lands, and leave a
history someone can follow commit by commit.

Done when: every unit you built has a check suited to it that you ran and
saw give the right answer (new behavior: it failed before the change and
passes after; cleanup: the same results before and after; configuration or
documents: they parse, build, or lint), the project's own suite passes, no
temporary debug code is left, and the work is committed.

Modes

Pick the mode the request describes. With no mode word and nothing in the
request to decide it, use work. Read only the reference for the mode you run.

How it works

1. Ground. Read the plan or ticket, memory/ when it exists, and the
   lessons for the paths you will touch:

   node "${CLAUDE_SKILL_DIR}/../../scripts/lessons.mjs" --paths <dir>,<dir>

   On the repository's default branch, create a feature branch before the first
   commit. When the working tree already holds edits, snapshot it before your
   first change, so the commit check can tell the user's edits from yours:

   node "${CLAUDE_SKILL_DIR}/../../scripts/changes.mjs" snapshot

   When the project has a verification skill (.claude/skills/verify-* or
   .agents/skills/verify-*), note it: verify uses it to prove user-facing
   changes.

2. Run the mode from its reference.

3. Keep the plan true. When the plan turns out wrong, fix the plan file and
   say what changed, rather than quietly building something else. A decision
   the plan records as the user's is not yours to change: when it proves
   unworkable, stop and ask.

4. Hand off. Run verify for user-facing changes and review before
   shipping. When the work crosses skills or sessions, keep the check results
   in a run record (../../references/artifacts.md) so the next stage reads
   them instead of re-running them blind; a one-sitting change does not need
   one.

The habits in ../../references/principles.md apply throughout, especially
building what was asked and proving it works.

Works with

• Reads: a plan or tickets from plan, lessons, a prototype's validated
  module, the project's verification skill.
• Hands off: commits to review and ship; finished tickets marked done;
  a lesson worth keeping to learn capture.
• Alone: given a plain request and no plan, write a short plan in the reply
  (units, each with a check) and build from that.

Paths in this skill and its references are relative to this skill's directory
(${CLAUDE_SKILL_DIR}). Outside Claude Code, that is the directory holding this
file, and $0 is the first word after the skill name.