A self-contained, file-based delivery loop: Epic → Stories → Sprint → Implement → Done.

No external PM tool required. All ledger state lives in the repo under . This is opt-in, project-local planning, not a synchronized project-management authority and never canonical ECC execution state — see Authority and Boundary with GitHub-backed coordination.

is an opt-in planning projection. It is never canonical ECC Task, Evidence, Completion, or Integration state. Where ECC execution-capsule contracts, an issue tracker, or another external task/evidence system is configured, that system stays authoritative: the ledger only mirrors outcomes that system has already recorded, and it never asserts completion or integration on its own.

follows the checkout. Another branch shows that branch's ledger, and stories created on an unmerged branch are not visible elsewhere until that branch is merged.

ECC's commands own issue-backed coordination: GitHub issues are the authority, labels and issue bodies carry state, and multiple agents can claim work. is deliberately smaller: a local, single-repo planning ledger with no synchronization. Never run both systems as parallel authorities for the same work.

Handoff path: if an initiative outgrows (multiple contributors, external visibility, dependency tracking across repos), export it once — create GitHub issues from the epic and its remaining stories (manually or via ), note in the epic file, set the epic's status to , and stop updating for that initiative.

All identifiers are validated before they are used in any file path:

Reject anything else — including IDs containing , , , whitespace, or uppercase — with a clear error. After joining, the resolved path must stay inside ; if it does not, stop and report instead of reading or writing.

Two more rules apply to every sub-command:

Every write to goes through in this skill's directory (). Never write ledger files directly with editor or shell tools: direct writes bypass the lock, ID allocation, and rollback. The helper is plain Node.js with no dependencies and runs on Windows, macOS, and Linux. If is not available, use the ledger read-only and tell the user.

Storage requirement: and its subdirectories must stay on the same writable, hardlink-capable filesystem. FAT32 and exFAT do not support hardlinks. Before any write command, the helper probes , or its nearest existing ancestor before initialization, and cleans up only its own probe files. If the probe fails, initialization, ID allocation, locking, publication and recovery are refused before ledger mutation. There is no copy fallback: it would weaken exclusive ownership and crash recovery. A successful probe cannot guarantee that storage remains available or unchanged during a later write.

stays read-only, including on unsupported storage. An existing interrupted transaction still reports and suppresses projection; this is pending work, not a promise that automatic recovery can run on the current storage. If storage changed while was pending, preserve the journal and files and use reviewed manual recovery. Do not discard the transaction or retry writes on unsupported storage. Automatic rollback requires unchanged hardlink-capable storage.

init

.stories/

epics/

sprints/

.stories/.gitignore

allocate --epic <slug> --count <n>

n

{ "ids": [...] }

apply --input <file.json>

{ "create": { path: content }, "update": { path: content } }

status

drift

recoveryPending

reconcile

recover

Paths in are relative to (, , ). Write the input JSON outside (for example in the harness's scratch or temp directory) and delete it afterwards.

Guarantees the helper enforces:

Invoke this skill with one of these sub-commands:

create-epic <title>

create-stories <epic-slug>

plan-sprint <n>

implement <story-id>

status

status --fix

If no sub-command is given, run first and ask which action to take.

Within the ledger, the story file is the single source of a story's planning status. The stories tables in epic and sprint files are derived summaries — convenient to read, never a source. Every regenerates the matching epic and sprint rows from the story files in the same batch. Plain is read-only: on any disagreement, the story file wins, but show the proposed table diff and require explicit approval (or plus confirmation) before running .

Story status moves strictly forward, one step at a time:

todo → in-progress → review → done

todo → in-progress

implement

in-progress → review

review → done

A story is never marked while its Definition of Done ("merged to main") is unverified — it stays in . If a review or verification fails, the story remains (or ) with a note; there are no backward transitions to . These statuses are planning records: they mirror the merge and verification results, they do not replace them (see Authority).

Slug: <slug> Status: draft | ready | in-progress | done Created: YYYY-MM-DD

ID: <epic-slug>-<n> Epic: <epic-slug> Sprint: <n or unassigned> Status: todo | in-progress | review | done Points: <1 | 2 | 3 | 5 | 8>

<Constraints, edge cases, dependencies on other stories. Omit if none.>

Start: YYYY-MM-DD End: YYYY-MM-DD Goal: <one sentence>

first runs . All other sub-commands check for first and fail with a clear message if it is missing: "Run first to initialise the .stories/ layout."

If the batch fails, nothing is written. Gaps in story numbers after a failed batch are expected; do not reuse a reserved ID.

When decomposing:

Epic: <title> [<status>]
  ✓ <story-id> <title>            ← done
  » <story-id> <title>            ← review
  → <story-id> <title>            ← in-progress
  · <story-id> <title>            ← todo

Show sprint assignment when relevant.