✓ Shipped 2026-06-23 — all items landed (impl 1.0)
§1 temporarily renamed reckon-ship → reckon-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 cause
Evidence
Fix
Progress bars never move — every plan sits at 0%, so the board looks dead
Skills + 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 grant
create/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 code
status 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 energy
Every 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
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.
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):
Skill dir skills/reckon-ship/ → skills/reckon-implement/ during the temporary rename; the live repo now restores skills/reckon-ship/.
Cross-references in the other four skills (create/edit/status all point at reckon-ship).
reckon/cli.py:432SKILLS list entry (doctor/install-skills).
Re-point symlinks in ~/.claude/skills/ and ~/.agents/skills/.
Reckon repo AGENTS.md routing table + all /reckon-ship mentions.
Migrate recommends_skill="/reckon-ship …" in reckon docs + the ~10 imas-codex plan HTML files (so queued followups stay live).
User-global ~/.agents/AGENTS.md + imas-codex AGENTS.md Plan System tables.
§2 — Systemic fixes (all five skills)
impl truth. Correct the "server-computes-impl" falsehood in PLAN-FORMAT.md, AGENTS.md, and the skills; reckon-ship sets impl = shipped_sections / total on every landing (monotonic, meaningful). Leave version/modified as genuinely server-owned.
allowed-tools. Add mcp__reckon___read_plan / edit_plan (and audit for status) to create/edit/status/implement.
Fast-path. A 4–6 line "to do X, do Y" recipe atop each skill; demote checkout_path / edit_plan(create=True) deep-dives below the everyday steps.
§05 dedup. One canonical §05 template; the others reference it. Fix reckon-edit:149's example that violates its own "don't re-list decisions" rule.
Dependency gate.reckon-ship Step 1 reads depends_on; STOP+surface if a prerequisite isn't shipped/done; name the blocks successors on completion.
§3 — Structural redesigns
reckon-status leads with the DAG. A "dependency order / ready-set / what-to-ship-next" section computed from depends_on (ready = active plans whose prereqs are all shipped); never recommend a plan ahead of its prerequisites. Call the audit MCP tool instead of the hand-coded checklist that drifts; add dangling/cyclic depends_on checks.
reckon-sync → thin wrapper. Delegate CSS/index/mounts/state to reckon sync + install-skills; keep only the genuinely-unique ~/.agents/skills/ leg + legacy migration; finish with reckon doctor. Kills the two-copies-of-index.html drift hazard.
Sprint management. ~78 lines of sprint orchestration in reckon-edit has a distinct trigger surface from plan-text editing — see decision.
✓ 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 implis — 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
Measure
Required 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
Measure
Required 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.
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.