✓ Shipped 2026-06-23 — all items landed (impl 1.0)

§1 temporarily renamed reckon-shipreckon-implement (kept the prefix; full sweep across the reckon repo + both symlink trees + ~/.agents + 9 imas-codex plans; 1092 tests). §2 granted the MCP tools in allowed-tools, corrected the impl-is-server-computed falsehood (the live skill, now reckon-ship, sets impl = shipped/total), added a dependency-precondition gate, and a fast-path atop every skill. §3 made reckon-status lead with the dependency DAG / ready-set + audit-as-source-of-truth, shrank reckon-sync to a thin CLI wrapper, and extracted a standalone reckon-sprint skill (six skills total). Commits: rename 0d666aa, §2 a397bd1, §3 017cbe5. Both decisions locked.

§0 — Why the skills go unused (diagnosis)

The lead reported not using the reckon skills and suspected they "could be improved." A holistic review of all five skills (create / edit / ship / status / sync) against the server source found four mechanical causes — none is "the skills are conceptually wrong" — plus a behavioral gap (dependency-order blindness).

Root causeEvidenceFix
Progress bars never move — every plan sits at 0%, so the board looks deadSkills + PLAN-FORMAT.md + AGENTS.md say plan-impl is "server-computed; do not author", but the server never computes it (_schema.py:247, _store.py:756-761 just clamps a settable scalar; no section counting anywhere). Agents dutifully don't set it.§2 — tell the truth (impl is set, not computed); reckon-ship sets impl=shipped/total each landing
Skills prescribe tools they don't grantcreate/edit/status drive read_plan/edit_plan/audit but none lists mcp__reckon___* in allowed-tools → permission prompt at the write moment§2 — add the MCP tools to allowed-tools
Redundancy with existing codestatus is an inferior text copy of the SPA dashboard; sync is a 300-line hand-rolled reimplementation of the reckon sync / install-skills / doctor CLI (and the SPA index.html template lives in two places → drift)§3 — status leads with what the SPA lacks (DAG + audit); sync becomes a thin CLI wrapper
High activation energyEvery skill front-loads theory (HTML-is-the-store, version-safe edit_plan, checkout_path, Tufte figure rules) before the first action; no fast-path recipe; reckon- is jargon§2 — fast-path recipe atop each skill; de-dupe the 3 divergent §05 templates
Dependency-order blindness (the lead's live pain)Critical-path/ready-set logic exists in graph.jsx but is invisible to the MCP payload and to ship/status — nothing stops recommending a successor plan before its prerequisites ship§2/§3 — dependency-order gate in reckon-ship + ready-set in reckon-status
/reckon-ship successor plan read depends_on; all prerequisites shipped? yes → implement + set impl=shipped/total no → STOP + surface "ship prerequisite X first"
The dependency-order gate now lives in reckon-ship; this plan originally specified it for the temporary reckon-implement rename. The live skill reads depends_on, refuses a plan whose prerequisites aren't shipped, and names the prerequisite instead — exactly the check that was missing when a successor plan was recommended before its prerequisite.

§1 — Historical rename rationale: reckon-shipreckon-implement (later reverted)

The full-family rename (drop reckon-, add -plan suffix) was considered and rejected: it creates collisions (edit-plan vs the edit_plan MCP tool), noun-ish awkwardness (status-plan, sync-plan), and carries all the migration risk while fixing none of the usability causes above. The reckon- prefix is namescoping that aids discovery and dodges every collision. Only ship is a bad noun ("implement" describes the skill's execute-and-record job better). Because reckon-implement kept the prefix, even the reckon-* directory glob in reckon-sync still matches — blast radius stays tiny.

Rename inventory (full sweep):

§2 — Systemic fixes (all five skills)

§3 — Structural redesigns

✓ landed 2026-08-12

§4 — Plan state is a living ledger, not a closing entry

Writeback is bound to reckon crew complete: nothing else may be promoted, merged, dispatched or opened before the plan write. impl advances per node landing over the orchestrator's executable-node denominator, carrying the commit and the gate's quantitative measure — a moved percentage is never the only new information — and a landing no longer pretends to close its section. 5 contract tests, suite green at 1,671; the four prescribed ops were checked against a real plan copy before integration. Full record: commit f6e2518, merged 005fc81.

§2 fixed what impl is — a settable scalar the executing skill writes, not a figure the server computes. It did not fix when. The skill writes plan state per section, and a section spans several nodes, so a plan with three landed nodes and two still in flight reads exactly like one nobody has started. The figure is stalest precisely while the work is most active, which is when every reader needs it: the next session deciding what is left, the roadmap deciding what is ready, and the lead looking at a board that appears dead.

The unit of advance is the node landing, not the section. A landing is already a discrete, evidenced event — a promoted run with a commit, a gate verdict and a measure. Writing plan state in the same beat as that promotion costs one call and removes the window in which the plan disagrees with the repository. Waiting for the section to close is what creates the window.

Detail advances with the number. A percentage that moves while the prose still describes unstarted work is a progress bar, not a record. Each landing writes what landed: the commit, the measure the gate produced, the artifact. A reader must be able to see what has been done without running anything, at any moment, not only after the last node.

A followup on the plan being shipped is a section, not a followup. Deferring same-plan work into a followup and then marking the plan complete hides it: lifecycle status is what the roadmap filters on, so a plan at shipped with impl 1.0 leaves pending_work and ready_now entirely, taking its open followup with it. Followups are for work belonging to a different plan, whose own lifecycle surfaces it.

Evidence gates

MeasureRequired evidence
The cadence is stated as per-landing The executing skill requires the plan-state write immediately after each run is promoted, and a contract test asserts that wording rather than trusting it.
The writer is named, once The skill and its orchestration reference agree that the orchestrator writes plan state and that workers return outcome data instead — no second candidate writer, and the existing ban on workers touching shared state left intact.
Landing detail is required, not just the number The skill requires the commit and the gate's measure in the same write that advances impl, so a moved percentage is never the only change.
Same-plan work cannot be deferred out of sight The skill states that follow-on work on the plan in hand becomes a section of it, and a contract test asserts the rule is present.
Suite green Full reckon suite passes; new-test count recorded.

§5 — A run does not end with a foldable followup open

§4 fixed the cadence of the plan write. It left the disposal of everything a run discovers. A followup created while shipping — by the orchestrator on a landing, or by a worker reporting work it was fenced out of — is currently written and left for a session that may never come. The plan accretes debt at exactly the rate the run generates insight, which is the worst possible coupling: the more the run learns, the more it defers.

Followups generated during a run are triage input for that run, not a handoff. The orchestrator classifies every open followup and folds each one that needs no decision it cannot make into the current plan as a section, with nodes on the DAG. It repeats after every wave, because landing work generates more followups, and stops when a pass turns up nothing foldable. That termination condition is the same shape as the loop-until-dry rule already used for discovery: a simple counter would stop while the tail is still arriving.

Most followups need no decision at all — they are work somebody noticed and was fenced out of. So folding is the default and leaving one open is the exception that must name itself. The exemption is narrow and enumerable: the followup needs authority the orchestrator does not hold (spend, an outward-facing effect, an irreversible action), or it asks to reopen a locked decision and belongs in the dissent flow, or its work is owned by a different plan or repository whose own lifecycle will surface it. Anything else is folded.

The enforcement point is terminal status. A plan may not be set shipped or done while a foldable followup against it is open — which is the same failure §4 already identified from the other side: a terminal status removes the plan from the ready set and takes its open work with it. An exempt followup may remain open precisely because it states why it cannot be folded, so a reader can tell a blocked promise from a forgotten one.

Evidence gates

MeasureRequired evidence
The loop is stated with its termination The executing skill requires re-triage after every wave and stops on a pass that finds nothing foldable, not on a fixed count; a contract test asserts the wording.
Folding is the default The skill states that a followup discovered during a run is folded unless it meets a named exemption, and the exemptions are enumerated rather than left to judgement.
Worker discoveries enter the same loop A manifest's follow_ons are triage input for the current run rather than deferred by default, and the skill says so where those candidates are handled.
Terminal status is gated on the drain The skill forbids a terminal status while a foldable followup is open, and requires an exempt one to record which exemption it claims.
Suite green Full reckon suite passes; new-test count recorded.

§ Decisions

Rename scheme for the skill family?

LOCKED. The prefix is namescoping (groups the family in autocomplete, dodges edit_plan/generic collisions). The full rename carries all the migration risk and fixes none of the usability causes. Only "ship" is a poor noun; "implement" fits the execute-and-record job and still autocompletes under /reckon-.

Extract sprint management out of reckon-edit?

Shipped a standalone reckon-sprint skill for sprint/milestone/roadmap state. Extracted from reckon-edit (which is now single-plan-edits only); wired into cli.py SKILLS, the doctor test, the ~/.claude + ~/.agents symlinks, and both AGENTS.md routing tables. reckon-sync's skill enumeration was made prefix-agnostic so the +1 skill is picked up automatically.

Where does dependency-order / ready-set logic live?

Shipped the skill-side dependency gate in reckon-ship (read depends_on; STOP if a prerequisite is not shipped/done; name blocks successors on completion). Server-side ready-set/computed-impl deferred as an optional follow-up.

Who writes plan state when a node lands?

A landing is evidenced at the moment a run is promoted, and both the worker that produced it and the orchestrator that promoted it could write the plan.

The orchestrator holds the full picture and has read the whole plan, so it is the only party that knows what one landing means for the rest — the denominator, which section it closes, and what is still in flight. A worker knows its own node and nothing else, so a worker-written advance would be a guess about a total it cannot see. It also keeps the existing rule intact rather than carving an exception into it: workers commit in detached worktrees and never touch shared reckon state, which is what stops concurrent nodes clobbering each other's writes.

What happens to a followup a shipping run generates?

A run discovers work at every landing: the orchestrator writes followups, and workers report follow-ons they were fenced out of.

Deferring by default couples debt to insight: the more a run learns, the more it leaves behind, and the promise is made to a session that may never come. Most followups need no decision at all — they are work somebody noticed and was fenced out of — so folding is the default and leaving one open is the exception that has to name itself. The orchestrator is the party that can do this: it holds the DAG, so it can add a section and its nodes, and it is already the sole writer of plan state. The loop repeats after every wave because landing work generates more followups, and terminates on a pass that finds nothing foldable rather than on a count.

§ Followups

§1 rename + §2 systemic fixes, then §3 structural

Execute §1 (rename reckon-ship→reckon-implement, full sweep, keep prefix) and §2 (systemic fixes) first — concrete, decision-free, high-value. Then §3 structural redesigns, honouring the sprint-extraction + dep-order-home decisions. Commit reckon repo and imas-codex separately; verify with reckon doctor.
Project: reckon
Plan:    reckon-skill-overhaul (http://localhost:8765/reckon/reckon-skill-overhaul.html)
Section: §1 (rename) then §2 (systemic) then §3 (structural)
Tier:    opus

Context
  The reckon skill family is under-used for four mechanical reasons (impl never
  advances, MCP tools ungranted, redundancy with SPA/CLI, high activation energy)
  + dependency-order blindness. Naming LOCKED: keep reckon- prefix, rename only
  reckon-ship→reckon-implement. Honour the sprint-extraction + dep-order-home
  decisions shown live above this brief.

State to read  (code/files, not the plan)
  ~/Code/reckon/skills/reckon-{create,edit,implement,status,sync}/SKILL.md
  ~/Code/reckon/reckon/cli.py (SKILLS list ~429; install_skills ~613; doctor ~415)
  ~/Code/reckon/PLAN-FORMAT.md (impl row ~85; §05 template)
  ~/Code/reckon/AGENTS.md (routing table) ; reckon/_store.py + serve.py (impl, depends_on)
  ~/.claude/skills/reckon-* + ~/.agents/skills/reckon-* (symlinks to re-point)
  imas-codex docs/*.html (recommends_skill="/reckon-ship …" to migrate, ~10 plans)

Scope locks / constraints  (non-decision)
  Keep the reckon- prefix on all five; rename ONLY reckon-ship→reckon-implement.
  reckon primary branch = main; commit reckon and imas-codex separately, push each.
  Skill edits (SKILL.md) are NOT docs/*.html — direct edits are fine.
  No co-author trailers; stage explicit paths only.

Done-when
  1. §1: reckon-implement everywhere; cli.py updated; symlinks re-pointed;
     recommends_skill migrated in both repos; `reckon doctor` clean.
  2. §2: impl truth fixed (docs+skills); allowed-tools grant MCP tools;
     fast-path atop each skill; §05 de-duped; dependency gate in implement.
  3. §3: status leads with DAG/ready-set + audit tool; sync→thin wrapper;
     sprint per decision.
  4. uv run pytest (reckon) clean if tests exist; followups written + this resolved.

§1 rename + §2 core systemic fixes landed. reckon: plan 49f76f3, rename 0d666aa (1092 tests pass), §2 a397bd1 (MCP allowed-tools + impl-truth + dependency gate). imas-codex: 5ff2b82d (recommends_skill migration, 9 plans). Symlinks re-pointed in ~/.claude + ~/.agents; ~/.agents/AGENTS.md routing table updated. Remaining (queued in f-rso-002): §2 fast-path recipes + §05 template dedup; §3 structural (status DAG, sync wrapper, sprint).

Finish §2 (fast-path + §05 dedup) and §3 structural redesigns

§1 + §2-core landed. Remaining §2: add a 4-6 line fast-path recipe atop each of the five skills; de-dupe the three divergent §05 templates to one canonical copy + fix the reckon-edit example that violates its own 'don't re-list decisions' rule. §3 structural: reckon-status leads with the dependency DAG/ready-set + calls the audit MCP tool; reckon-sync shrinks to a thin wrapper over reckon sync/install-skills/doctor; sprint management per the sprint-extraction decision (LOCK it first — new reckon-sprint skill vs delimited section).
Project: reckon
Plan:    reckon-skill-overhaul (http://localhost:8765/reckon/reckon-skill-overhaul.html)
Section: §2 (finish) + §3 (structural)
Tier:    opus

Context
  §1 rename + §2 core fixes (allowed-tools, impl-truth, dependency gate) landed.
  Finish the activation-energy fixes and the structural redesigns. The
  dep-order-home decision is LOCKED skill-only; the sprint-extraction decision
  is still OPEN — lock it before touching sprint code.

State to read  (code/files, not the plan)
  ~/Code/reckon/skills/reckon-{create,edit,implement,status,sync}/SKILL.md
  ~/Code/reckon/reckon/cli.py (sync ~69; install_skills ~613; doctor ~415)
  ~/Code/reckon/docs/ui/graph.jsx (critical-path/ready-set logic to mirror in status)
  ~/Code/reckon/reckon/mcp.py (audit tool the status skill should call)

Scope locks / constraints  (non-decision)
  Keep the reckon- prefix. One canonical §05 template; others reference it.
  reckon primary branch = main; commit + push; no co-author trailers.
  A new reckon-sprint skill (if chosen) needs cli.py SKILLS + doctor test +
  symlinks + AGENTS.md — same coordinated change as the rename.

Done-when
  1. Fast-path recipe atop all 5 skills; demote checkout_path/edit_plan(create) deep-dives.
  2. One canonical §05 template; reckon-edit self-contradicting example fixed.
  3. reckon-status leads with DAG/ready-set + audit tool; dangling/cyclic depends_on check.
  4. reckon-sync = thin wrapper over reckon sync/install-skills/doctor + ~/.agents leg.
  5. sprint per locked decision. uv run pytest clean. impl advanced; this followup resolved.

All items landed (commits 017cbe5 structural + 5df5d7f lint). §2 finish: fast-path recipe atop all six skills; §05 marked canonical in reckon-edit + self-contradicting example fixed. §3: reckon-status leads with dependency DAG/ready-set + audit-as-source-of-truth + dangling/cyclic checks; reckon-sync shrunk to a thin wrapper over the CLI (prefix-agnostic enumeration); NEW reckon-sprint skill extracted from reckon-edit. 1092 reckon tests pass; doctor verifies all six skills.

living-ledger landed — commit f6e2518; gate §4 passed on all five measures; measure 1,671 tests pass with 5 new contract tests, 523 s worker-time, 157 lines in scope; artifacts skills/reckon-ship/SKILL.md, references/sprint-orchestration.md, tests/test_skill_contracts.py. Writeback is now bound to reckon crew complete, impl advances per node landing over the orchestrator's executable-node denominator, the commit and gate measure travel with it, and same-plan follow-on work becomes a section. The four prescribed ops were checked against a real plan copy before integration — set impl, set commits, set artifacts and append comment all apply. Integration into main is queued behind a concurrent session's uncommitted edits to the same skill file; the commit is safe in the object store.