Orchestrate Skill — Testing skill for Claude Code

Orchestrate — a ledger skill for Claude Code

A [Claude Code](https://claude.com/claude-code) skill for running multi-batch code changes off a **file-based ledger** that lives in the repo, survives crashes, and can be driven by any future session — including one that has never seen this skill.

The problem it solves: a change too big for one session. Context runs out, the session dies, a new one picks up with no memory of what was done, and status notes in chat lie about what actually shipped. Orchestrate writes the plan, the scope fence, and the progress table into committed files, then treats **git as the source of truth** whenever those files and reality disagree.

How it works

Every change gets one directory, committed to the repo:

.agents/changes/-YYYYMMDD-/
├── 00-request.md        the user's verbatim ask + decisions + item→batch map
├── 00-READBEFORE.md     the contract: boot, git model, checkpoints, validations, recovery, algorithm
├── 01-plan.md           locked scope: batch table, wave map + checkpoints, per-batch specs, coverage
├── 02-batches-NN-*.md   one per batch: wave, file fence, spec, checklist, acceptance, smoke steps
└── PROGRESS.md          live status + checkpoint tables, smoke verdicts, coverage audit, session log

The work then runs in **waves**: file-disjoint batches implemented concurrently, one implementer per batch, each on its own branch in an isolated git worktree, stacking serially onto an **integration branch**. Four gates hold throughout:

1. A locked plan. Scope is agreed up front and written down. Every request item maps to exactly one batch, or to an exclusion you signed off on — nothing silently dropped. The plan also locks the wave map — which batches may run concurrently, and why that's safe — and the checkpoint placement; your plan approval is the standing authorization for that concurrency.
2. A file fence. Each batch declares the only files it may touch. An implementer