implementing-batch

Invoke the implementing-batch skill with the decided change. It orients by reading only the ranges to edit, orders edits by dependency edges, builds them idempotently, proves the result with tests or type checks, reviews the diff in a fresh context, and commits in Conventional Commits.

The test-first route runs one behavior per cycle at any file count. The user confirms observable boundaries first, then each cycle quotes the new test's failing output before the production edit and the passing output after it, writing only the least code that turns the test green.

The loop runs when one or more risk facts hold: more than two files change, a dependency is added, a public signature changes, a persisted format or security boundary is crossed, or a required file was not inspected. Zero facts means direct edits with a check, then stop.

Yes. When work changes a schema, persisted format, backfill, or destructive DDL, it loads the data-migration reference, which enforces a compatibility matrix and an expand, migrate, verify, contract phase order with a named rollback boundary.

The loop stops: the edit in progress is finished at a green state, the task list with remaining edits is written to implement-next.md under the git directory, and the session reports that a context clear comes next. A later context reads that file to resume.

Skip it for a plan file, a change of at most two files with no risk facts, a version bump, or an unproven failure. Unproven failures belong to the debug skill until their cause is established, and repairs crossing a second owner also go to debug.