@erclx/aitk 0.107.2 → 0.109.0

package/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "aitk",
   "description": "Automated governance, versioning, and discovery tools for Claude Code.",
-  "version": "0.107.2",
+  "version": "0.109.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/claude-orchestrate/REQUIREMENT.md

@@ -45,7 +45,6 @@ The session also records nothing of what it learns. Both other callers of memory
 - List a candidate's file set against every track in flight, and serialize when the sets are not disjoint
 - Place every finding a merged pull request produced against the surface that owns it
 - Place what the return leg carries by what it changes, sending an answer that settles a finding onto the pull request and one that corrects this session's model of the world to the task owning that surface, since neither becomes a record by being read
-- Date the roadmap line from that file's last commit, so an old sequence reads as old
 - Keep one planned, non-conflicting task in reserve beyond what is running
 - Refill the queue while a wave is still building, rather than on a merge and a thinning list alone, since neither of those fires across the window planning costs nothing
 - Carry a constraint naming each in-flight track's file set in every plan written from here, stating per set which of the two acts it forbids, since a bare path list leaves a broken citation in place
@@ -86,8 +85,7 @@ The session also records nothing of what it learns. Both other callers of memory
 ## Guards
 
 - Priority file absent: report the queue and say the order is unrecorded rather than inferring it from the index
-- Roadmap absent: omit the roadmap line rather than asserting a version the file does not state
-- Roadmap present but never committed: report the date as uncommitted, since a blank reads as a formatting slip
+- Cross-version sequencing asked for: say no surface carries it, rather than asserting an active version the tree does not state
 - This body dropped from a long session approaching a compaction: name the re-invocation and the runbook paths, since the routing lives in the body and a user-invoked skill routes nothing once it is gone
 - Blocker only an operator can clear: record the row as untestable this pass and name the action owed, rather than re-measuring what no session can move
 

package/claude/skills/claude-orchestrate/SKILL.md

@@ -28,7 +28,6 @@ Read the board in parallel, resolving the paths at the main worktree root per Wo
 - `.claude/tasks/backlog.md`: what is not being scheduled, when the file exists
 - `.claude/tasks/index.md`: what is queued
 - `.claude/plans/*.md`: features already planned and ready to hand off
-- `.claude/ROADMAP.md`: sequencing rationale, when the file exists
 - open PRs via `gh pr list --json number,title,headRefName,isDraft`
 
 Then output the state of play so the human knows what to launch, review, and merge.
@@ -37,7 +36,7 @@ Then output the state of play so the human knows what to launch, review, and mer
 
 Row position under `## Needs a plan` is what gets planned next, top first, per `.claude/standards/tasks.md`. `backlog.md` carries what nobody is scheduling and is explicitly unordered, so read it for what exists and never as a queue. Report a backlog count rather than its rows, since listing them puts the length back in front of the reader the cut took it away from.
 
-The roadmap is optional and this skill does not require it. It carries why a sequence is what it is, changes only when strategy changes, and is absent in a project whose scope has already shipped. Report what it says and name it as the source. Never assert an active version the file does not state, and say nothing about one when the file is missing.
+No surface carries cross-version sequencing, so report none. A row's `Waiting on` cell states why that row sits where it does, and reasoning spanning several rows reaches this session only through whoever remembers it. Say nothing about an active version, since nothing in the tree states one and a version asserted from the board is the unsourced claim this omission exists against.
 
 A compaction is a moment this skill cannot detect, so the human asks for each side of it and this skill reads the matching runbook when they do.
 
@@ -56,8 +55,6 @@ That routing lives in this body and this skill is user-invoked, so a session tha
 ```plaintext
 Orchestrator ready.
 
-Roadmap: vX.Y, <the Now row's outcome>, as of <date>.
-
 Ready to build (hand each to its own worker):
 
 <feature>
@@ -80,9 +77,7 @@ Next: <the single most useful action>
 
 Omit any section with nothing in it. Recommend a handoff only for a plan whose file set is disjoint from every track already in flight, per Parallelism below.
 
-Omit the `Roadmap` line when `.claude/ROADMAP.md` is absent. Quote the `Now` row rather than restating it, and date the line from `git log -1 --format=%ad --date=short -- .claude/ROADMAP.md` so an old sequence reads as old instead of as the state of play.
-
-That command returns nothing for a roadmap that exists but has never been committed, which is the state `claude-roadmap` leaves behind when it writes the file and declines to stage it. Write `uncommitted` as the date in that case. A blank there would read as a formatting slip rather than as the newest possible sequence.
+The block opens on the board rather than on a version, because no committed file states one. Adding a version line here would restate what a reader can already see on the rows, dated by nothing, which is how the retired sequencing surface produced an unsourced claim on every run.
 
 ### Every later turn
 
@@ -103,18 +98,15 @@ Write no shape for a correction. A correction is a sentence, and a format for ad
 
 ## The loop
 
-1. Own the roadmap while a scope exists to sequence.
-   - Capture a needed draft or resequence of `.claude/ROADMAP.md` in the plan or a task file, naming the MVP list in `.claude/REQUIREMENTS.md` as the source, so a worker runs `claude-roadmap` in its branch and the tracked edit ships in a PR rather than dirtying main
-   - Stop owning it once that list has shipped, since later work then arrives as discrete items rather than as versions
-2. Plan the next feature. Run `claude-feature` here, with the cross-feature context, to write a plan to `.claude/plans/`. Planning stays in this warm session so the plan front-loads reasoning a cold worker would otherwise re-derive. Every plan written from here also carries a constraint per track in flight, which the paragraph below this list states.
-3. Decide parallelism and merge order. Note which plans touch a shared wiring seam so their PRs merge in sequence, not at once.
-4. Verify the plan against the tree. Reading it is not enough, since a plan goes stale from whatever merged after it was written. Grep for each construct it names and count the sites against the count it claims. Check that every phase label it cites is still open. Open each file it describes rather than trusting its account of the contents. Correct the plan before handing it over.
-5. Hand off. The human opens a worker worktree with `claude-worktree` and runs `claude-autoship` against the plan. The orchestrator does not spawn workers.
-6. Review the PR. When a worker opens a PR, run `claude-pr-review` to post findings to it. This is the deep, independent pass. The worker's autoship self-review was only the green gate.
+1. Plan the next feature. Run `claude-feature` here, with the cross-feature context, to write a plan to `.claude/plans/`. Planning stays in this warm session so the plan front-loads reasoning a cold worker would otherwise re-derive. Every plan written from here also carries a constraint per track in flight, which the paragraph below this list states.
+2. Decide parallelism and merge order. Note which plans touch a shared wiring seam so their PRs merge in sequence, not at once.
+3. Verify the plan against the tree. Reading it is not enough, since a plan goes stale from whatever merged after it was written. Grep for each construct it names and count the sites against the count it claims. Check that every phase label it cites is still open. Open each file it describes rather than trusting its account of the contents. Correct the plan before handing it over.
+4. Hand off. The human opens a worker worktree with `claude-worktree` and runs `claude-autoship` against the plan. The orchestrator does not spawn workers.
+5. Review the PR. When a worker opens a PR, run `claude-pr-review` to post findings to it. This is the deep, independent pass. The worker's autoship self-review was only the green gate.
    - Learning that a PR moved is the mechanical half, so read `${CLAUDE_SKILL_DIR}/references/orchestrator-poll.md` and start the poll it carries on the first dispatch rather than checking the board by hand. That runbook holds the routing, and a summary of it here is a second source that drifts from it.
-7. Dispatch the handback. A pass posting a finding at any severity tells the session holding that branch to run `claude-address-review`, rather than waiting for a person to relay it. Re-review when the answer lands, then the human merges. Tell the trailing worker to rebase when its branch shares a seam with the merged one.
+6. Dispatch the handback. A pass posting a finding at any severity tells the session holding that branch to run `claude-address-review`, rather than waiting for a person to relay it. Re-review when the answer lands, then the human merges. Tell the trailing worker to rebase when its branch shares a seam with the merged one.
    - Read the threshold off `claude-pr-review`, which states it once and governs the heading with it, so an open heading and an owed dispatch answer the same question and either one is enough to send
-   - Resolve the target at the moment of sending with `aitk sessions list --branch`, never from a mapping written down earlier, since names rotate as sessions end and one recorded earlier in a session has failed inside the hour. The runbook read at step 6 routes on the count and the confidence it answers with
+   - Resolve the target at the moment of sending with `aitk sessions list --branch`, never from a mapping written down earlier, since names rotate as sessions end and one recorded earlier in a session has failed inside the hour. The runbook read at step 5 routes on the count and the confidence it answers with
    - Open the message with the worktree and branch the sender believes the reader holds, asking to be corrected, whenever that mapping is inferred rather than confirmed
    - Name the skill for the reader to run rather than writing an invocation, which arrives as text
    - Read the pull request's own draft flag rather than the state a worker reports, since two reported a draft that read ready inside ninety seconds
@@ -134,7 +126,7 @@ Stamp the block with the commit this session read the tree at, which the same se
 - Run one orchestrator at a time. The board is gitignored, so a second session sees none of this one's writes: two task files land minutes apart under different labels for the same work, one session archives a task mid-sweep in the other, and each archives a plan the other had retargeted. An Owner column does not fix this, since neither session can read the other's rows.
 - Do not implement features in this session. Hand the plan to a worker.
 - Do not merge. Recommend merge or changes. The human merges.
-- Do not spawn worker sessions with agents. The human launches each worktree so every build is an independent, steerable stream with its own PR. The handback dispatch in step 7 reaches a session the human already launched, so it leaves this boundary where it is.
+- Do not spawn worker sessions with agents. The human launches each worktree so every build is an independent, steerable stream with its own PR. The handback dispatch in step 6 reaches a session the human already launched, so it leaves this boundary where it is.
 - Do not edit tracked files from this session, at any size. The boundary offers no proportionality exception and nothing enforces it.
 - Do not hand a worker anything but a plan, since scope lives there. A plan carries exact diffs only when they are already known, otherwise it states the scope and the open questions and lets the worker write the diff.
 

package/claude/skills/claude-pr-review/REQUIREMENT.md

@@ -7,7 +7,7 @@ description: What the independent pull request review is for, the gaps it closes
 
 ## Gap
 
-Without this skill, a pull request is reviewed only by the session that wrote it, which cannot see the roadmap sequence or a sibling branch in flight. Findings land in chat, where they are read once and leave the thread with no record. A review that opens and never closes is worse than none, since a reader scanning the thread cannot tell an unanswered review from a confirmed one, and the author's claim that findings are fixed is the only evidence they are.
+Without this skill, a pull request is reviewed only by the session that wrote it, which cannot see the board's order or a sibling branch in flight. Findings land in chat, where they are read once and leave the thread with no record. A review that opens and never closes is worse than none, since a reader scanning the thread cannot tell an unanswered review from a confirmed one, and the author's claim that findings are fixed is the only evidence they are.
 
 A finding also stops being true by argument rather than by a fix. A worker naming the plan question that already declined it, or a constraint the pass could not see, settles it in the exchange that carried the answer, and the pass that accepts the argument drops the finding from its next body. A reader then sees a finding raised once and never mentioned again, which is indistinguishable from one everyone forgot.
 

package/claude/skills/claude-pr-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: claude-pr-review
-description: Reviews an open pull request from an independent session and posts findings as a review comment on the PR. Posts a first pass against the whole change and every later pass against only the commits added since, under `## Review` while any finding is open and `## Review closed` once a pass carries none. Reads project docs and the roadmap for cross-feature context a self-review lacks. Use when asked to "review the PR", "review this feature's PR", "post a PR review", "re-review the PR", "close out the review", "confirm the findings are fixed", or acting as the orchestrator reviewing a worker's PR. Do NOT use to review local uncommitted changes. That is `claude-review`.
+description: Reviews an open pull request from an independent session and posts findings as a review comment on the PR. Posts a first pass against the whole change and every later pass against only the commits added since, under `## Review` while any finding is open and `## Review closed` once a pass carries none. Reads project docs and the task board for cross-feature context a self-review lacks. Use when asked to "review the PR", "review this feature's PR", "post a PR review", "re-review the PR", "close out the review", "confirm the findings are fixed", or acting as the orchestrator reviewing a worker's PR. Do NOT use to review local uncommitted changes. That is `claude-review`.
 ---
 
 # Claude PR review
@@ -32,7 +32,7 @@ Read these in parallel from the project root, skipping any that do not exist:
 - `CLAUDE.md`: project type, conventions, and commands
 - `.claude/REQUIREMENTS.md`: feature scope and non-goals
 - `.claude/ARCHITECTURE.md`: technical design decisions
-- `.claude/ROADMAP.md`: where this feature sits and what depends on it
+- `.claude/tasks/priority.md`: where this feature sits on the board and what each neighboring row waits on. Resolve this one at the main worktree root per Worktrees in `CLAUDE.md`, since the board is gitignored and a linked worktree holds no copy of it
 - `.claude/plans/feature-<slug>.md` for the branch, when present: the intent the PR should satisfy
 
 Coding standards from `.claude/rules/` are auto-loaded by Claude Code.
@@ -79,7 +79,7 @@ Read each changed file in scope. Skip deleted files. Run reads in parallel.
 
 Review the diff and files for the same axes as `claude-review` (bugs, edge cases, error handling, logic flaws, security, rule violations), then add the three lenses a self-review structurally cannot apply:
 
-- Integration: does this fit the roadmap sequence, the shared wiring seam, and any sibling PR in flight?
+- Integration: does this fit the board's order, the shared wiring seam, and any sibling PR in flight?
 - Contract: does a contract downstream features depend on land correctly, and should the plan itself be questioned?
 - Consumers: when the change touches a resource with more than one consumer, enumerate them and check the rule against each. A rule written for the consumer the change targets can be wrong for a sibling that writes.
 
@@ -116,7 +116,7 @@ The comment is a rendered-for-human GitHub surface, so load the `write-human` sk
 ```markdown
 ## Review
 
-X critical, Y should-fix, Z minor. Reviewed against project docs and roadmap.
+X critical, Y should-fix, Z minor. Reviewed against project docs and the board.
 
 **`path/to/file.ext`**
 
@@ -172,14 +172,14 @@ Before posting, run the scan in `.claude/standards/publish.md` against the body,
 gh pr review <number> --comment --body-file .claude/.tmp/pr-review/body-<number>-<short-sha>.md
 ```
 
-A pass carrying nothing at all takes `## Review closed` and a short body, with the footer line included either way. On a first pass, post `✅ No findings. Reviewed against project docs and roadmap.` On a later pass, post `✅ Prior findings addressed. Re-reviewed <short-sha>, N commits since the prior pass.`
+A pass carrying nothing at all takes `## Review closed` and a short body, with the footer line included either way. On a first pass, post `✅ No findings. Reviewed against project docs and the board.` On a later pass, post `✅ Prior findings addressed. Re-reviewed <short-sha>, N commits since the prior pass.`
 
 A pass carrying only minors is an ordinary finding-carrying pass, so it takes the open heading and the full shape rather than either short line, since the minors have to be readable and neither line reports them. Keep whichever scope sentence the pass owes on the summary line:
 
 ```markdown
 ## Review
 
-0 critical, 0 should-fix, Z minor. Reviewed against project docs and roadmap.
+0 critical, 0 should-fix, Z minor. Reviewed against project docs and the board.
 
 **`path/to/file.ext`**
 

package/claude/skills/migration-superseded/REQUIREMENT.md

@@ -11,7 +11,7 @@ Without this skill, a target holding a retired `.claude/` file is told what repl
 
 A second failure comes from the ordering nobody gets right unaided. A retired file committed before its ignore entry was written is tracked and ignored at once, and removing the entry first leaves the file tracked with nothing naming it. No report catches that state, so the mistake is discovered by whoever next wonders why a gitignored path keeps appearing in diffs.
 
-Two more follow from where a session looks when the report is thin. An uppercase stem under `.claude/` is not the test for a superseded file, so a session substituting a folder listing reaches `ARCHITECTURE.md`, `REQUIREMENTS.md`, `ROADMAP.md`, and `DESIGN.md`, each a single file the layout intends to stay one, and proposes shredding four documents. A session falling back to the plugin's own copy of the destination standard proposes a shape the project never adopted, against content only the user can place.
+Two more follow from where a session looks when the report is thin. An uppercase stem under `.claude/` is not the test for a superseded file, so a session substituting a folder listing reaches `ARCHITECTURE.md`, `REQUIREMENTS.md`, and `DESIGN.md`, each a single file the layout intends to stay one, and proposes shredding three documents. A session falling back to the plugin's own copy of the destination standard proposes a shape the project never adopted, against content only the user can place.
 
 The last is the two-speed release skew arriving as a confident wrong answer. `superseded` reached a release in `0.46.0`, and an older CLI exits zero with a well-formed report that never mentions the field. A session reading that absent key as an empty array reports a clean layout to exactly the population holding the retired files.
 

package/claude/skills/migration-superseded/SKILL.md

@@ -27,7 +27,7 @@ Stop on any of three conditions, naming which one fired:
 
 Test for the key rather than for emptiness. A current CLI reporting `"superseded": []` has looked and found nothing, which is the pass above, and reading an absent key as an empty answer reports a clean layout to the projects this skill exists for.
 
-No listing substitutes for the field. The pairing runs against the seed folder names the toolkit ships, and an uppercase stem is not the test, so a listing of `.claude/*.md` also reaches `ARCHITECTURE.md`, `REQUIREMENTS.md`, `ROADMAP.md`, and `DESIGN.md`. Each of those is a single file the layout intends to stay one. A fallback that proposed splitting them would shred four documents to avoid reporting a stale CLI, which is why this skill stops where its siblings degrade.
+No listing substitutes for the field. The pairing runs against the seed folder names the toolkit ships, and an uppercase stem is not the test, so a listing of `.claude/*.md` also reaches `ARCHITECTURE.md`, `REQUIREMENTS.md`, and `DESIGN.md`. Each of those is a single file the layout intends to stay one. A fallback that proposed splitting them would shred three documents to avoid reporting a stale CLI, which is why this skill stops where its siblings degrade.
 
 ## Step 2: resolve the destination standard
 

package/docs/agents/markdown-audit.md

@@ -27,7 +27,9 @@ A bare run measures every markdown file git lists, tracked plus untracked-and-no
 
 ## Where the rules come from
 
-The three ban sets and all six checkpoints ship with the `aitk` package as data, in `src/markdown/bans.ts` and `src/markdown/structure.ts`. Every project is measured against the same sets whether or not it installed any standards, and no file has to resolve for a run to mean something.
+The three ban sets and all nine checkpoints ship with the `aitk` package as data, in `src/markdown/bans.ts` and `src/markdown/structure.ts`. Every project is measured against the same sets whether or not it installed any standards, and no file has to resolve for a run to mean something.
+
+Six of the nine are stated in `markdown.md` and the three cadence numbers are stated in the `write-human` skill. That split is the content boundary rather than an accident: `markdown.md` carries the enforced rules a scan can decide, and the skill carries the rhythm rules a ban list cannot express. A cadence number moved in the skill and left in the code drifts the same way, so move both.
 
 Reading them out of the standards per run was the original design. It put a parser contract on a document authored for people, and the standard had to carry a paragraph of its own warning an author that a one-word backticked example in a `- Do not use ` bullet would be lifted into a literal ban set and ban that word everywhere. A rule existing to protect a parser from the prose it parses is the argument for separating them.
 
@@ -98,9 +100,29 @@ That re-sample ran once the scan stopped counting link syntax as prose. Findings
 
 A bullet, a heading, a table row, a blockquote, a blank line, and a fence each end a paragraph, so a heavy bullet is reported by the bullet check alone and never counted twice.
 
+### Cadence
+
+Uniform cadence is the failure a ban list cannot express. A ban set states negatives, and fragments, verbless clauses, and sentences that all run one length are each the absence of something, so no addition to the thirteen banned words reaches any of them. The shape layer already measured a bullet, a paragraph, and a run, and stopped one level above where that failure lives.
+
+Cadence measures a paragraph on two numbers. The spread is the words between its longest and shortest sentence, and the opener count is the times one word opens a sentence in it. A spread of five words or under reads as one cadence, and a word opening more than two sentences is a pattern rather than a coincidence. Both come from `## Rhythm` in the `write-human` skill, which states them about prose a person reads, and this measures against that statement rather than setting a threshold of its own.
+
+Words are counted off the text a reader is shown. A link contributes its anchor text, an autolink contributes nothing, and the sentence boundaries do not move under that masking, since the boundary pattern requires whitespace after the terminal punctuation and no destination carries any. An opening word is lowercased and stripped of punctuation, so a sentence opening on a backticked command name reports the command.
+
+A paragraph carrying fewer than three sentences is skipped rather than scored. A two-sentence configuration note has no spread worth reading, and the opener rule is written about a third sentence turning a coincidence into a pattern, so neither number says anything before the floor. That is the cheap form of a wider exemption: a shape-aware one, exempting a short reference block by what it is rather than by how many sentences it holds, waits on a second case.
+
+The unit is the paragraph and each file names its worst on each measure, which follows the depth check rather than setting a precedent. A file's flattest paragraph and its most repetitive one are named only when each crosses its checkpoint, so a file reading healthy names nothing rather than offering its least healthy paragraph as a finding.
+
+Neither number gates and neither names a file wrong. This is a weaker claim than the one the weight checkpoints make, because a healthy range differs by surface: a catalog entry is several short sentences carrying one fact each, and a page arguing a decision is not, so one range applied across the corpus would report the surfaces that are correct. The run therefore states where the numbers came from beside them, and the counts are what a reader compares against.
+
+Measured at `6c273324` across the corpus, 2119 paragraphs reached the floor, 165 sat at or under the spread checkpoint and 50 past the opener checkpoint. Over the 60 files carrying at least ten measured paragraphs the flat rate runs from zero to 21 percent with a median near 6, which is the spread that makes the measure worth reading. Two wiki pages sit at either end of it: a server catalog reports 19 percent, its flattest paragraph five sentences within four words of each other and three of them verbless, while a page arguing where the prose rules came from reports none.
+
+That reading travels with the command rather than staying here. `BASELINE` in `src/markdown/structure.ts` carries the overall share, the per-file range, and the ten-paragraph floor beneath which a file's own rate says nothing, and the run prints all four in the legend beside the rate it measured. A count with no range beside it reads as a finding, and naming that a healthy range differs by surface states that a range exists rather than what it looks like. This page is toolkit-internal, so a reader running the command in a project that installed no standards would otherwise have two counts and nothing to place them against.
+
+Two of the rules `write-human` states are deliberately not implemented. A sentence's grammatical shape and whether it carries a finite verb each need a parse rather than a match, and an imperative or a heading fragment would read as a defect under a pattern that approximated either. The verbless share is the measure closest to the reported symptom, which is exactly why shipping it wrong would discredit the two that hold. It ships when something can identify a finite verb rather than guess at one.
+
 ## Exit codes
 
-Exit codes are `0` for a completed run with no gating finding, `1` for a refusal, `2` for a ban hit, and `3` for a shipped ban set that arrived empty. A banned character, word, or spelling fails the run. Bullet, paragraph, and depth weight are judgments a reader settles, so all three report under every code.
+Exit codes are `0` for a completed run with no gating finding, `1` for a refusal, `2` for a ban hit, and `3` for a shipped ban set that arrived empty. A banned character, word, or spelling fails the run. Bullet, paragraph, and depth weight are judgments a reader settles, and cadence is a distribution whose healthy range moves with the surface, so all four report under every code.
 
 `3` is separate from `1` because the two want different responses from a caller. A refusal means no corpus was built, and the `Markdown bans` stage in `scripts/core/verify.sh` is right to warn and skip. An empty set means the corpus was walked and nothing was looked for, so that stage fails the push on `3` rather than skipping.
 

package/docs/agents/skills-audit.md

@@ -67,7 +67,11 @@ aitk claude skills drift 02d7b265 --json
 | -------- | ---------------------------------------------------------- |
 | `--json` | Add a machine-readable record on stdout, keeping the frame |
 
-A skill body enters a session once and stays. Re-invoking the skill replays the copy the session already holds rather than re-reading the file, so a session that outlives a merge touching a body it loaded keeps applying what it loaded and nothing compares the two. A compaction carries the held copy forward with the summary it writes, which makes the exposure the age of the oldest load rather than the age of the session.
+A skill body enters a session once and stays. Re-invoking the skill does not re-read the file, so an edit made this session is not picked up and nothing compares the two. A session that outlives a merge touching a body it loaded keeps applying what it loaded, and a compaction carries the held copy forward with the summary it writes, which makes that exposure the age of the oldest load rather than the age of the session.
+
+Age is one route and not the only one. A session that edits a body and then invokes that same skill later in the same run replays the pre-edit text, which is what a ship chain does whenever a branch touches a body the chain runs at the end. This verb does not reach that route, because it reads history and the edit is still uncommitted when the replay happens. Re-read a body after editing it, and do not wait for a report to name it.
+
+Which shape the staleness takes decides whether anyone notices. A held body naming a file the branch deleted fails loudly by having nothing to read. One naming a file that still exists while saying something different resolves and reads current, so the session applies the stale rule and reports success.
 
 The ref is required and carries no default. `HEAD` is the only value the command could supply for itself, and it answers every run with nothing moved, which is the silence this verb exists to break. A session passes the commit it started from.
 
@@ -83,6 +87,8 @@ The report names the newest commit that rewrote each body rather than the first,
 
 The report says a file moved, not that a session holds a stale copy. A session cannot read its own loaded body as bytes, so the comparison runs against history and a ref older than the oldest load over-reports. That is the safe direction, since confirming a name costs one read of the body while the failure being answered is silence. Every run states the bound, including the run that names nothing.
 
+The verb answers only when someone runs it, and a report read is not a report acted on. A session that sees a moved body in the result and does not re-read that body stands where it started. One session reached that outcome after running the verb at session start, then followed the held copy for the rest of the day.
+
 Two cases fall outside the range. An uncommitted edit in the working tree is not history yet, so a body changed and left unstaged reports as unmoved. A target project loads the plugin from a marketplace cache with no repository behind it, where the verb refuses and names the absent history rather than reporting a clean tree.
 
 Exit codes are `0` when history was read, whether or not a body moved, and `1` when the question could not be answered. An absent shipped corpus, an absent repository, and a ref matching no commit each refuse with their own reason on stderr. A command exiting zero on a question it never answered is the failure `.claude/ARCHITECTURE.md` already records against two skills, which is why no path here reports an empty result in place of a refusal.

package/docs/ai-workflow.md

@@ -75,9 +75,9 @@ When features are independent, run them in parallel instead of sequentially. Use
 - Ship each worktree separately with `aitk:git-ship`
 - For full autonomy per worktree, invoke `aitk:claude-autoship` instead of the manual chain. Approve the plan, walk away, come back to draft PRs.
 
-To run several worktrees as a coordinated flow rather than ad hoc, assert the orchestrator role in one warm session with `aitk:claude-orchestrate`. It owns the roadmap, handing a needed draft or resequence to a worker that runs `aitk:claude-roadmap` in its branch, plans each feature, refills the ready queue so a free worker never waits, and reviews each worker's PR with `aitk:claude-pr-review`, then tells the session holding that branch to run `aitk:claude-address-review` whenever the pass posted a finding at any severity, which is the same threshold `aitk:claude-pr-review` states and posts its open heading under. The human launches workers and merges. See [operating model](operating-model.md) for the full loop.
+To run several worktrees as a coordinated flow rather than ad hoc, assert the orchestrator role in one warm session with `aitk:claude-orchestrate`. It plans each feature, refills the ready queue so a free worker never waits, and reviews each worker's PR with `aitk:claude-pr-review`, then tells the session holding that branch to run `aitk:claude-address-review` whenever the pass posted a finding at any severity, which is the same threshold `aitk:claude-pr-review` states and posts its open heading under. The human launches workers and merges. See [operating model](operating-model.md) for the full loop.
 
-Roadmap ownership holds while a scope exists to sequence. Once the MVP list in `.claude/REQUIREMENTS.md` has shipped, later work arrives as discrete items and the orchestrator reads `.claude/tasks/priority.md` for execution order instead.
+Execution order comes off `.claude/tasks/priority.md` and nothing sequences work into versions. Scope stays in `.claude/REQUIREMENTS.md` as a statement of what is wanted, and it reaches the board as discrete tasks the orchestrator orders by readiness.
 
 Run one orchestrator at a time. The board is gitignored, so a second session reads none of the first one's writes and the two collide on labels and archives. No fixed number caps the worker tracks underneath it. Collision between file sets is what binds, so a candidate opens only when its files are disjoint from every track in flight, and the ceiling in practice is how many outputs one session can still review properly.
 
@@ -193,7 +193,6 @@ This section is the corpus the coverage claim is measured against: every name `a
 | `aitk:claude-intake-answer` | When an intake folder holds unread slots waiting on your decision               |
 | `aitk:claude-groundwork`    | When the state is unmeasured and more than one approach is live                 |
 | `aitk:decision-escalate`    | When open decisions turn on your preference and want batching into one set      |
-| `aitk:claude-roadmap`       | When MVP scope needs sequencing into ordered versions                           |
 | `aitk:claude-tasks`         | When a decided item needs a file on the board, or a shipped one needs archiving |
 | `aitk:claude-feature`       | When the approach is settled and the next step is a plan                        |
 

package/docs/operating-model.md

@@ -17,10 +17,10 @@ order, port collisions), see [Claude Code and git worktrees](../wiki/claude/clau
 
 The split is by vantage, not by capability. Both are Claude Code sessions.
 
-| Role         | Session                               | Owns                                           | Does not                      |
-| ------------ | ------------------------------------- | ---------------------------------------------- | ----------------------------- |
-| Orchestrator | One warm, long-lived session          | Roadmap, planning, deep PR review, merge order | Edit tracked files, merge PRs |
-| Worker       | One cold worktree session per feature | Implement, self-check, open PR                 | Question the plan, merge      |
+| Role         | Session                               | Owns                                  | Does not                      |
+| ------------ | ------------------------------------- | ------------------------------------- | ----------------------------- |
+| Orchestrator | One warm, long-lived session          | Planning, deep PR review, merge order | Edit tracked files, merge PRs |
+| Worker       | One cold worktree session per feature | Implement, self-check, open PR        | Question the plan, merge      |
 
 The orchestrator is worth asserting explicitly at the start of a session with
 `claude-orchestrate`, which loads the loop and its boundaries. It is framing and
@@ -36,13 +36,12 @@ and no later session recovers that vantage.
 
 One feature travels this path end to end.
 
-1. Orchestrator captures a needed roadmap draft or resequence in the plan or a task file, naming `.claude/REQUIREMENTS.md` as the scope source, and a worker runs `claude-roadmap` in its branch so the tracked edit ships in a PR. The skill stops when that file carries a later scope section, since the MVP list it sequences has shipped and a fresh requirements pass owns what follows.
-2. Orchestrator plans the next feature with `claude-feature`, writing a plan to `.claude/plans/`. Planning stays in the warm session because good planning is cross-feature. It needs the contract other features consume and the shared wiring seam. A cold session would re-derive or guess.
-3. The human opens a worker worktree with `claude-worktree` and runs `claude-autoship` against the plan. The worker builds, self-checks, opens a PR, and stops at the PR boundary.
-4. Orchestrator reviews the PR with `claude-pr-review` and posts findings to it.
-5. Orchestrator tells the session holding that branch to run `claude-address-review` once the pass posted a finding at any severity, resolving the target then with `aitk sessions list --branch` and reporting the invocation for the human when no live session holds it. The worker addresses the findings, rebases onto `origin/main` when a sibling landed first and left the branch unable to merge, then pushes a follow-up. A pass carrying only minor findings dispatches too, since the grade runs low often enough that a floor at should-fix loses fixes a worker would have made. `claude-pr-review` states that threshold and the heading follows it, so an open heading is itself the signal to send.
-6. Orchestrator closes the review out with `claude-pr-review` again. The second pass reads only the commits the follow-up added, or the worker's response alone when the follow-up added none, and posts under `## Review` when it finds anything and under `## Review closed` when it finds nothing, so a reader learns from the heading whether work is still owed and takes the merge decision from the counts on the line under it. Repeat from step 5 until a pass closes the review.
-7. The human reads the result and merges. The orchestrator tells any trailing worker whose branch shares a seam with the merged one to run `claude-address-review`, which rebases whether or not the review left anything open.
+1. Orchestrator plans the next feature with `claude-feature`, writing a plan to `.claude/plans/`. Planning stays in the warm session because good planning is cross-feature. It needs the contract other features consume and the shared wiring seam. A cold session would re-derive or guess.
+2. The human opens a worker worktree with `claude-worktree` and runs `claude-autoship` against the plan. The worker builds, self-checks, opens a PR, and stops at the PR boundary.
+3. Orchestrator reviews the PR with `claude-pr-review` and posts findings to it.
+4. Orchestrator tells the session holding that branch to run `claude-address-review` once the pass posted a finding at any severity, resolving the target then with `aitk sessions list --branch` and reporting the invocation for the human when no live session holds it. The worker addresses the findings, rebases onto `origin/main` when a sibling landed first and left the branch unable to merge, then pushes a follow-up. A pass carrying only minor findings dispatches too, since the grade runs low often enough that a floor at should-fix loses fixes a worker would have made. `claude-pr-review` states that threshold and the heading follows it, so an open heading is itself the signal to send.
+5. Orchestrator closes the review out with `claude-pr-review` again. The second pass reads only the commits the follow-up added, or the worker's response alone when the follow-up added none, and posts under `## Review` when it finds anything and under `## Review closed` when it finds nothing, so a reader learns from the heading whether work is still owed and takes the merge decision from the counts on the line under it. Repeat from step 4 until a pass closes the review.
+6. The human reads the result and merges. The orchestrator tells any trailing worker whose branch shares a seam with the merged one to run `claude-address-review`, which rebases whether or not the review left anything open.
 
 There is no loop construct here. Each worker is a single build that halts at the
 PR. The merge stays a manual human gate. Reliability comes from the plan being
@@ -55,7 +54,7 @@ The worker's self-review and the orchestrator's review are not the same pass run
 twice. They differ by vantage.
 
 - Worker self-review, inside `claude-autoship`: the session that wrote the code. Its job is "did I build the plan and does it pass?" Mechanical, and structurally blind to its own misreadings, because the same misreading wrote both the code and the review. This is the green gate that decides whether the PR opens.
-- Orchestrator review, via `claude-pr-review`: a fresh session with cross-feature context (the roadmap, a sibling PR in flight, a downstream contract). Its job is "is this right and does it fit?" It can question the plan itself. This is the merge gate.
+- Orchestrator review, via `claude-pr-review`: a fresh session with cross-feature context (the board, a sibling PR in flight, a downstream contract). Its job is "is this right and does it fit?" It can question the plan itself. This is the merge gate.
 
 They collide only if the worker also runs a deep pass. Keep the worker's review
 light and let the orchestrator own the deep, independent one. The human read at
@@ -127,19 +126,19 @@ coordination costs more than the change it was too small.
 
 ## Where work comes from
 
-Three tiers hold work at different altitudes.
+Two tiers hold work at different altitudes.
 
-- Roadmap (`.claude/ROADMAP.md`): versions as themes, sequenced. Committed, low churn. Shape governed by `standards/bundled/roadmap.md`.
-- Tasks (`.claude/tasks/`): the active few pulled into the current turn, one file each. Gitignored, high churn. Shape governed by `standards/tasks.md`.
+- Tasks (`.claude/tasks/`): the active few pulled into the current turn, one file each. Gitignored, high churn. Shape governed by `standards/tasks.md`. `priority.md` beside them carries execution order, and `backlog.md` carries what nobody is scheduling.
 - Edits: a few lines, done immediately with no ceremony.
 
-Pre-MVP the roadmap is the backlog, because the scope is finite and known.
-Post-MVP the backlog moves to tracked issues, per item, and the roadmap thins to
-occasional theme-setting.
+Nothing above these sequences work into versions. Scope is stated in
+`.claude/REQUIREMENTS.md` and reaches the board as discrete tasks, so why one
+task runs before its neighbors is on its row and why one group of work runs
+before another is carried nowhere at all.
 
 ## Parallelism
 
-The binding constraint is the human and the shared files, not the roadmap. Cap
+The binding constraint is the human and the shared files, not the board. Cap
 at two or three worker tracks and split them across the stack so they do not
 collide on the same files.
 

package/governance/rules/claude/570-skill.md

@@ -13,6 +13,11 @@ paths:
 
 - Read the skill's sibling `REQUIREMENT.md` when one exists. If the change closes no gap it states, change the requirement first or drop the change.
 
+## After editing
+
+- Re-read a skill body this session edited before invoking that skill again in the same session
+- Do not read a resolved file path in a held body as evidence the body is current
+
 ## Authority
 
 - Follow `.claude/standards/skill.md` for skill structure, frontmatter fields, invocation rules, and the shape a `REQUIREMENT.md` states. It is the single source.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/aitk",
   "type": "module",
-  "version": "0.107.2",
+  "version": "0.109.0",
   "description": "Infrastructure and quality tooling for developer workflows",
   "license": "MIT",
   "bin": {

package/src/commands/markdown.ts

@@ -11,6 +11,7 @@ import {
   scanBans,
 } from '@/markdown/scan'
 import {
+  BASELINE,
   CHECKPOINTS,
   type Checkpoints,
   measureStructure,
@@ -58,7 +59,7 @@ export function register(program: Command): void {
   markdown
     .command('audit')
     .description(
-      'Fail on a banned character, word, or spelling, and report bullet, paragraph, and depth weight',
+      'Fail on a banned character, word, or spelling, and report bullet, paragraph, cadence, and depth',
     )
     .argument(
       '[path...]',
@@ -80,6 +81,10 @@ export function register(program: Command): void {
         'depth weight are judgments a reader settles, so all three report and',
         'none of them fails a run.',
         '',
+        'Cadence reports the same way and carries one more caveat. Its range is',
+        'drawn from prose a person reads, so terse reference prose sits below',
+        'it correctly and a flat paragraph there is not a defect.',
+        '',
         'Rewrite the sentence carrying a hit rather than swapping the token for',
         'a near-synonym. A code span clears the report and is the answer only',
         'where the token is genuinely an identifier under discussion, which is',
@@ -146,6 +151,7 @@ async function runAudit(
   reportBans(reports, bans, empty)
   reportBullets(reports, checkpoints)
   reportParagraphs(reports, checkpoints)
+  reportCadence(reports, checkpoints)
   reportDepth(reports, checkpoints)
   outro()
 
@@ -168,6 +174,9 @@ async function runAudit(
           paragraph: checkpoints.paragraph,
           sentences: checkpoints.sentences,
           renderWidth: checkpoints.renderWidth,
+          cadence: checkpoints.cadence,
+          spread: checkpoints.spread,
+          opener: checkpoints.opener,
         },
         entries: reports.map((report) => ({
           path: report.rel,
@@ -176,6 +185,7 @@ async function runAudit(
           longestRunLine: report.structure.longestRunLine,
           heavyBullets: report.structure.heavyBullets,
           heavyParagraphs: report.structure.heavyParagraphs,
+          cadence: report.structure.cadence,
         })),
       })}\n`,
     )
@@ -377,6 +387,99 @@ function reportParagraphs(
   )
 }
 
+/**
+ * Reports the distribution rather than a verdict, which is what separates this
+ * step from the three above it.
+ *
+ * Bullet, paragraph, and depth weight each report a count against a checkpoint
+ * a reader settles. Cadence reports a count as well, and the range behind it is
+ * drawn from one surface class rather than from the corpus, so the step states
+ * where the numbers came from beside them. A reader whose file is terse
+ * reference prose is meant to read a flat paragraph as correct, and a number
+ * printed with no comparison beside it reads as a finding whatever the step is
+ * called.
+ */
+function reportCadence(
+  reports: readonly FileReport[],
+  checkpoints: Checkpoints,
+): void {
+  logStep('Cadence')
+  logInfo(
+    `Paragraphs of ${checkpoints.cadence} sentences or more measure the words between their longest and shortest sentence, and the times one word opens a sentence.`,
+  )
+  logInfo(
+    `A spread of ${checkpoints.spread} words or under reads as one cadence, and a word opening more than ${checkpoints.opener} sentences is a pattern rather than a coincidence.`,
+  )
+  logInfo(
+    'Both numbers are stated under Rhythm in the write-human skill, which writes them about prose a person reads.',
+  )
+  logInfo(
+    'A shorter paragraph stays unmeasured, since a two-sentence note carries no spread worth reading.',
+  )
+  logInfo(
+    'A healthy range differs by surface, so neither number gates and neither names a file wrong. Terse reference prose sits below the range a page written for a reader sits in.',
+  )
+  logInfo(
+    `The corpus these numbers were read against measured ${BASELINE.flatShare} percent flat overall, and its files carrying ${BASELINE.floor} or more measured paragraphs ran from ${BASELINE.low} to ${BASELINE.high} percent with a median near ${BASELINE.median}. Compare a rate against that rather than against zero.`,
+  )
+
+  const measured = reports.reduce(
+    (sum, report) => sum + report.structure.cadence.measured,
+    0,
+  )
+
+  if (measured === 0) {
+    logInfo(
+      `No paragraph reached ${checkpoints.cadence} sentences, so nothing was measured.`,
+    )
+    return
+  }
+
+  const flat = reports.reduce(
+    (sum, report) => sum + report.structure.cadence.flat,
+    0,
+  )
+  const repeating = reports.reduce(
+    (sum, report) => sum + report.structure.cadence.repeating,
+    0,
+  )
+
+  logInfo(
+    `${plural(measured, 'paragraph')} measured, ${flat} at or under the spread checkpoint (${Math.round((flat / measured) * 100)} percent) and ${repeating} past the opener checkpoint.`,
+  )
+
+  const carrying = reports
+    .filter(
+      (report) =>
+        report.structure.cadence.flattest ||
+        report.structure.cadence.mostRepeated,
+    )
+    .sort(
+      (a, b) =>
+        b.structure.cadence.flat +
+        b.structure.cadence.repeating -
+        (a.structure.cadence.flat + a.structure.cadence.repeating),
+    )
+
+  if (carrying.length === 0) return
+
+  pipeOutput(
+    carrying
+      .map((report) => {
+        const { flattest, mostRepeated } = report.structure.cadence
+        const lines = [
+          flattest &&
+            `  :${flattest.line}  ${plural(flattest.sentences, 'sentence')}, spread ${plural(flattest.spread, 'word')}`,
+          mostRepeated &&
+            `  :${mostRepeated.line}  ${plural(mostRepeated.sentences, 'sentence')}, "${mostRepeated.opener}" opens ${mostRepeated.repeats}`,
+        ].filter(Boolean)
+
+        return `${report.rel}\n${lines.join('\n')}`
+      })
+      .join('\n'),
+  )
+}
+
 /**
  * Names the render width and the blank-line convention on every run.
  *

package/src/markdown/structure.ts

@@ -33,6 +33,14 @@ const SENTENCE_END = /[.!?]["'’”)\]]*(?=\s+(?:["'“(\[]*[A-Z]|`)|\s*$)/g
  * degraded a number and the report had to carry a legend saying which one. The
  * standard still states every number for a reader, and moving one is an edit to
  * both.
+ *
+ * The last three come from the `## Rhythm` section of the `write-human` skill
+ * rather than from a standard. That skill states what good rhythm is and this
+ * measures against the statement, so the numbers are read off the sentences
+ * that already carry them: a longest and shortest sentence within roughly five
+ * words of each other is one cadence, an opening word repeating twice is
+ * coincidence and three times is a pattern, and both rules are written about a
+ * paragraph, which needs a third sentence before either says anything.
  */
 export const CHECKPOINTS = {
   run: 40,
@@ -41,6 +49,37 @@ export const CHECKPOINTS = {
   paragraph: 700,
   sentences: 4,
   renderWidth: 80,
+  cadence: 3,
+  spread: 5,
+  opener: 2,
+} as const
+
+/**
+ * The reading a cadence rate is compared against, rather than a checkpoint.
+ *
+ * A count with nothing beside it reads as a finding, and the two counts the
+ * cadence step reports have no range a reader can place them in: twelve flat
+ * paragraphs out of forty says the same as two without one. Naming that a
+ * healthy range differs by surface states that a range exists rather than what
+ * it looks like, so the reading travels with the command.
+ *
+ * This is an observation rather than a rule, which is why it sits apart from
+ * `CHECKPOINTS`. Nothing compares a run against it and no exit code reads it. A
+ * project whose corpus is entirely terse reference prose is expected to sit
+ * above the high end, and that is the measure working.
+ *
+ * Read across 483 markdown files at `6c273324` on 2026-08-20. A number here
+ * goes stale against the corpus it describes with nothing comparing the two, so
+ * re-measure before moving one.
+ */
+export const BASELINE = {
+  /** Share of every measured paragraph sitting at or under the spread checkpoint. */
+  flatShare: 8,
+  /** Measured paragraphs a file needs before its own rate means anything. */
+  floor: 10,
+  low: 0,
+  median: 6,
+  high: 21,
 } as const
 
 /**
@@ -58,6 +97,12 @@ export interface Checkpoints {
   readonly paragraph: number
   readonly sentences: number
   readonly renderWidth: number
+  /** Sentences a paragraph needs before its cadence is measured at all. */
+  readonly cadence: number
+  /** Words between the longest and shortest sentence, at or under which the paragraph reads as one cadence. */
+  readonly spread: number
+  /** Times one opening word may open a sentence in a paragraph before it is a pattern. */
+  readonly opener: number
 }
 
 export interface BulletFinding {
@@ -72,6 +117,47 @@ export interface ParagraphFinding {
   readonly characters: number
 }
 
+/**
+ * One measured paragraph, carrying both cadence numbers rather than one.
+ *
+ * A paragraph reported for a narrow spread is usually worth reading for its
+ * openers too, and splitting the two into separate finding types would name the
+ * same line twice with half the picture on each.
+ */
+export interface CadenceFinding {
+  readonly line: number
+  readonly sentences: number
+  /** Words between the longest and shortest sentence. */
+  readonly spread: number
+  /** Times the most repeated opening word opens a sentence here. */
+  readonly repeats: number
+  /** The opening word behind `repeats`, lowercased and stripped of punctuation. */
+  readonly opener: string
+}
+
+/**
+ * A file's cadence distribution, reported rather than listed finding by finding.
+ *
+ * Both numbers are advisory in a way even the weight checkpoints are not. A
+ * healthy range differs by surface, so terse reference prose and a page written
+ * for a reader sit at different spreads and one range applied across the corpus
+ * would report the surfaces that are correct. The counts are what a reader
+ * compares against the stated range, and the two worst paragraphs are where
+ * they open the file.
+ */
+export interface CadenceReport {
+  /** Paragraphs carrying at least the floor sentence count. */
+  readonly measured: number
+  /** Measured paragraphs at or under the spread checkpoint. */
+  readonly flat: number
+  /** Measured paragraphs past the opener checkpoint. */
+  readonly repeating: number
+  /** Narrowest paragraph among the flat ones, or undefined when none is flat. */
+  readonly flattest: CadenceFinding | undefined
+  /** Most repetitive paragraph among the repeating ones, or undefined when none repeats. */
+  readonly mostRepeated: CadenceFinding | undefined
+}
+
 export interface StructureReport {
   readonly rel: string
   /** Rendered lines at the render width, not source lines. */
@@ -80,6 +166,7 @@ export interface StructureReport {
   readonly longestRunLine: number
   readonly heavyBullets: readonly BulletFinding[]
   readonly heavyParagraphs: readonly ParagraphFinding[]
+  readonly cadence: CadenceReport
 }
 
 /**
@@ -275,48 +362,46 @@ export function heavyBullets(
   return findings
 }
 
+/**
+ * Splits a paragraph into the sentences terminal punctuation closes.
+ *
+ * A trailing span no punctuation closes is dropped rather than returned, which
+ * keeps this and the count below one definition. The pattern already matches a
+ * paragraph's final period through its end-of-text alternative, so the only
+ * span this drops is a paragraph genuinely ending without terminal punctuation,
+ * which is a fragment rather than a sentence to either measure.
+ */
+function splitSentences(text: string): string[] {
+  const sentences: string[] = []
+  let start = 0
+
+  for (const match of text.matchAll(SENTENCE_END)) {
+    const end = match.index + match[0].length
+    sentences.push(text.slice(start, end).trim())
+    start = end
+  }
+
+  return sentences
+}
+
 function countSentences(text: string): number {
-  return [...text.matchAll(SENTENCE_END)].length
+  return splitSentences(text).length
 }
 
 /**
- * Finds the prose paragraphs past either half of the standard's checkpoint.
+ * Splits the body into its prose paragraphs, each a run of consecutive lines.
  *
- * Both halves are stated in the standard and both are read from it. The weight
- * half was added there rather than borrowed from the bullet checkpoint, which
- * governs a different construct: one number feeding both would move the
- * paragraph rule whenever the bullet rule was changed, and an author reading
- * the sentence cap would find no weight rule to read at all.
- *
- * The two numbers coincide today because paragraph and bullet weight measure
- * one population, sharing a median near 170 characters with no gap behind
- * either candidate. They are separate checkpoints regardless, so either moves
- * without dragging the other.
- *
- * A paragraph is a run of consecutive prose lines. A heading, a list item, a
- * table row, a blockquote, a blank line, and a fence each end one, so a bullet
- * is measured by `heavyBullets` alone and never twice.
+ * A heading, a list item, a table row, a blockquote, a blank line, and a fence
+ * each end one, so a bullet is measured by `heavyBullets` alone and never
+ * twice. Both paragraph measures walk this rather than one each, since two
+ * walks deciding what a paragraph is would drift apart.
  */
-export function heavyParagraphs(
-  lines: readonly BodyLine[],
-  checkpoints: Checkpoints,
-): ParagraphFinding[] {
-  const findings: ParagraphFinding[] = []
+function paragraphBlocks(lines: readonly BodyLine[]): BodyLine[][] {
+  const blocks: BodyLine[][] = []
   let block: BodyLine[] = []
 
   const close = (): void => {
-    if (block.length > 0) {
-      const text = block.map((line) => line.text.trim()).join(' ')
-      const sentences = countSentences(text)
-      const characters = visibleText(text).length
-
-      if (
-        sentences > checkpoints.sentences ||
-        characters > checkpoints.paragraph
-      ) {
-        findings.push({ line: block[0].number, sentences, characters })
-      }
-    }
+    if (block.length > 0) blocks.push(block)
     block = []
   }
 
@@ -340,9 +425,168 @@ export function heavyParagraphs(
 
   close()
 
+  return blocks
+}
+
+/** Folds a paragraph's source lines into the one line they would have wrapped from. */
+function paragraphText(block: readonly BodyLine[]): string {
+  return block.map((line) => line.text.trim()).join(' ')
+}
+
+/**
+ * Finds the prose paragraphs past either half of the standard's checkpoint.
+ *
+ * Both halves are stated in the standard and both are read from it. The weight
+ * half was added there rather than borrowed from the bullet checkpoint, which
+ * governs a different construct: one number feeding both would move the
+ * paragraph rule whenever the bullet rule was changed, and an author reading
+ * the sentence cap would find no weight rule to read at all.
+ *
+ * The two numbers coincide today because paragraph and bullet weight measure
+ * one population, sharing a median near 170 characters with no gap behind
+ * either candidate. They are separate checkpoints regardless, so either moves
+ * without dragging the other.
+ */
+export function heavyParagraphs(
+  lines: readonly BodyLine[],
+  checkpoints: Checkpoints,
+): ParagraphFinding[] {
+  const findings: ParagraphFinding[] = []
+
+  for (const block of paragraphBlocks(lines)) {
+    const text = paragraphText(block)
+    const sentences = countSentences(text)
+    const characters = visibleText(text).length
+
+    if (
+      sentences > checkpoints.sentences ||
+      characters > checkpoints.paragraph
+    ) {
+      findings.push({ line: block[0].number, sentences, characters })
+    }
+  }
+
   return findings
 }
 
+/** Punctuation either side of a word, so an opener is compared on its letters. */
+const WORD_EDGE = /^[^\p{L}\p{N}]+|[^\p{L}\p{N}]+$/gu
+
+/**
+ * The word a sentence opens on, lowercased and stripped of punctuation.
+ *
+ * A sentence opening on a code span yields the command inside it rather than a
+ * backtick, which is the word a reader hears. Casing is dropped because an
+ * opener repeating is a repetition whether or not one of the two sits mid-list
+ * and lost its capital.
+ */
+function openingWord(sentence: string): string {
+  const [first = ''] = sentence.split(/\s+/)
+  return first.replace(WORD_EDGE, '').toLowerCase()
+}
+
+/**
+ * Measures one paragraph's spread and its most repeated opener.
+ *
+ * Words are counted off the text a reader is shown, so a link contributes its
+ * anchor text and a destination contributes nothing. The sentence boundaries do
+ * not move with that masking, since the pattern requires whitespace after the
+ * terminal punctuation and no destination or autolink carries any.
+ */
+function measureParagraph(block: readonly BodyLine[]): CadenceFinding {
+  const sentences = splitSentences(visibleText(paragraphText(block)))
+  const lengths = sentences.map(
+    (sentence) => sentence.split(/\s+/).filter(Boolean).length,
+  )
+
+  const counts = new Map<string, number>()
+  for (const sentence of sentences) {
+    const word = openingWord(sentence)
+    if (word !== '') counts.set(word, (counts.get(word) ?? 0) + 1)
+  }
+
+  let opener = ''
+  let repeats = 0
+  for (const [word, count] of counts) {
+    if (count > repeats) {
+      opener = word
+      repeats = count
+    }
+  }
+
+  // A paragraph closing no sentence at all has no spread rather than a
+  // negative one, and the floor drops it before either number is read.
+  const spread =
+    lengths.length === 0 ? 0 : Math.max(...lengths) - Math.min(...lengths)
+
+  return {
+    line: block[0].number,
+    sentences: sentences.length,
+    spread,
+    repeats,
+    opener,
+  }
+}
+
+/**
+ * Reports how a file's prose is distributed across sentence length and opening
+ * word, which is the layer the ban sets cannot reach.
+ *
+ * A banned-word list expresses negatives and every symptom this answers is the
+ * absence of something, so no addition to that set catches a paragraph whose
+ * sentences are all one length. The measure stops at what is countable. A
+ * sentence's grammatical shape and whether it carries a finite verb are the two
+ * rules `write-human` states that this does not implement, because identifying
+ * either needs a parse rather than a match, and an imperative or a heading
+ * fragment would read as a defect. Reporting them wrong is worse than not
+ * reporting them, since they name the exact failure this exists to measure.
+ *
+ * A paragraph under the floor is skipped rather than scored. A two-sentence
+ * configuration note has no spread worth reading, and the opener rule is
+ * written about a third sentence turning a coincidence into a pattern, so
+ * neither measure says anything before the floor is reached.
+ */
+export function measureCadence(
+  lines: readonly BodyLine[],
+  checkpoints: Checkpoints,
+): CadenceReport {
+  const measured = paragraphBlocks(lines)
+    .map(measureParagraph)
+    .filter((finding) => finding.sentences >= checkpoints.cadence)
+
+  const flat = measured.filter(
+    (finding) => finding.spread <= checkpoints.spread,
+  )
+  const repeating = measured.filter(
+    (finding) => finding.repeats > checkpoints.opener,
+  )
+
+  return {
+    measured: measured.length,
+    flat: flat.length,
+    repeating: repeating.length,
+    flattest: worst(flat, (finding) => -finding.spread),
+    mostRepeated: worst(repeating, (finding) => finding.repeats),
+  }
+}
+
+/**
+ * The file's worst paragraph on one measure, earliest line breaking a tie.
+ *
+ * Only paragraphs already past their checkpoint are passed in, so a file
+ * reading healthy names nothing rather than naming its least healthy paragraph,
+ * which a reader would take for a finding.
+ */
+function worst(
+  findings: readonly CadenceFinding[],
+  rank: (finding: CadenceFinding) => number,
+): CadenceFinding | undefined {
+  return findings.reduce<CadenceFinding | undefined>(
+    (held, finding) => (!held || rank(finding) > rank(held) ? finding : held),
+    undefined,
+  )
+}
+
 export function measureStructure(
   rel: string,
   lines: readonly BodyLine[],
@@ -356,5 +600,6 @@ export function measureStructure(
     longestRunLine: run.line,
     heavyBullets: heavyBullets(lines, checkpoints),
     heavyParagraphs: heavyParagraphs(lines, checkpoints),
+    cadence: measureCadence(lines, checkpoints),
   }
 }

package/standards/requirements.md

@@ -14,7 +14,7 @@ Governs the product-scope document at `.claude/REQUIREMENTS.md`: problem, goals,
 Does not govern:
 
 - Rationale for a technical choice: `architecture.md`
-- Sequencing the scope into ordered versions: `roadmap.md`
+- Execution order across the work the scope generates: `tasks.md`
 - Per-domain structure and narrative: `context.md`
 
 ## What goes in
@@ -39,7 +39,7 @@ Use `## Problem`, `## Goals`, `## Non-goals`, `## MVP features`, `## Tech stack`
 
 The MVP list is a historical record of the original scope. Once those features ship it stays as written. Do not renumber it, do not append to it, and do not annotate entries with status. A reader telling the original scope apart from what followed depends on the first one staying legible.
 
-Later scope arrives as a new section rather than as an extension of the MVP list. Name the section for what it delivers and state its entries as outcomes, the same way the goals are stated. A roadmap sequences the MVP list alone, so a later scope section is sequenced by a fresh pass rather than folded into the roadmap that already shipped. The roadmap standard sends a project here once its last version ships, and this is the pass it means.
+Later scope arrives as a new section rather than as an extension of the MVP list. Name the section for what it delivers and state its entries as outcomes, the same way the goals are stated. Nothing sequences either list into versions. Work reaches the board as discrete tasks under `tasks.md`, which orders them by readiness, so a section here states what is wanted and never when it lands.
 
 ## Distribution
 

package/standards/session.md

@@ -57,7 +57,7 @@ Add a section only for content that fits none of the three and would otherwise b
 ## Writing one
 
 1. Capture what the session learned first, so the map cites what was written instead of restating the same lesson in prose.
-2. Run `aitk claude skills drift <the commit this session started from>` and record what it names under `## Standing cautions`. A skill body enters a session once and re-invoking the skill replays the held copy rather than the file, so the drift is worst at exactly this moment and a name here is a body the session has been following out of date. This step belongs to session length rather than to any role, so every writer runs it, and a refusal names the boundary of what the verb can read rather than a fault.
+2. Run `aitk claude skills drift <the commit this session started from>` and record what it names under `## Standing cautions`. A skill body enters a session once and re-invoking the skill does not re-read the file, so the drift is worst at exactly this moment and a name here is a body the session has been following out of date. Recording a name is not acting on it, and the verb misses a body this session edited and has not committed. This step belongs to session length rather than to any role, so every writer runs it, and a refusal names the boundary of what the verb can read rather than a fault.
 3. Recover that commit from how long the session has been running with `git log -1 --format=%H --before='<duration> ago'`, rounding the duration up rather than down. Nothing on the machine records it. A ref older than the oldest load over-reports, and confirming a name costs one read of the body, so the generous end is the safe one and a guess at the exact commit is not worth making.
 4. Write only what a compaction destroys and no other artifact already carries. The board holds the ordering and what each task waits on, a task file holds its own findings, and a measurement folder holds its track.
 5. Cite a commit, a task, or a file and line for every claim, so the next session can tell a read from a recall.

package/standards/tasks.md

@@ -19,7 +19,6 @@ Does not govern:
 
 - The plan file a task cites, its sections, and its answer contract: `plan.md`
 - Phase-label format and which surfaces a label may appear on: `versioning.md`
-- Sequencing across versions and why the order is what it is: `roadmap.md`
 - Architectural reasoning that outlives a task: `architecture.md`
 - The pre-compaction handoff sitting in the folder, its filename and its sections: `session.md`
 - When a project opens a task at all, which is project policy rather than a shape rule
@@ -52,7 +51,9 @@ The `claude-tasks` skill creates and archives task files. `claude-docs` marks ou
 
 ## Ordering
 
-`priority.md` carries execution order and what each task is waiting on. The generated index sorts by filename and says nothing about order, so without this file board state gets reconstructed by hand every session. Why one version sequences against another belongs in `.claude/ROADMAP.md`, which is committed because that rationale has no substitute record. Why a row sits where it does inside its group is stated on the row itself, in the column that already carries what the task is waiting on.
+`priority.md` carries execution order and what each task is waiting on. The generated index sorts by filename and says nothing about order, so without this file board state gets reconstructed by hand every session. Why a row sits where it does inside its group is stated on the row itself, in the column that already carries what the task is waiting on, one line per row.
+
+That cell is the only home sequencing rationale has. Rationale spanning several rows, why one group of work runs before another, is carried by nothing and reaches a later session only through whoever remembers it. Naming the gap is deliberate: a second document holding it would be the version-sequencing surface this board replaced, and a row already states what it waits on, which is the part of the reasoning a reader acts on.
 
 Group tasks by readiness rather than by status, one row per task, under the columns each group fixes below. Keep it to links and blockers: tables, plus at most one sentence per section. A paragraph in `priority.md` is a defect whatever it says. Stating the shape this way is what lets a single diff fail, since a size cap only trips after the fact and every addition looks defensible on its own.
 
@@ -240,7 +241,7 @@ The line is what lets a merge close its own task. Every merge on `main` is a squ
 - Architectural reasoning that outlives the task. A finding explains why this task is shaped as it is. A decision the system keeps after the task closes belongs in `.claude/ARCHITECTURE.md`.
 - Narrative of the session that produced the task. A finding states what constrains the task, so what was probed, what it cost, and who decided belongs in the groundwork folder the `Groundwork:` line names. A task with no groundwork folder cuts the narrative rather than relocating it, since the board is not the fallback destination for it.
 - "In progress" or "Blocked" headings. Note status inline on the outcome instead.
-- Sequencing rationale or which version is active. Why this task is planned before its neighbors goes on its row in `priority.md`, in the cell that already carries what it is waiting on. Why one version sequences against another belongs in `.claude/ROADMAP.md`, which is committed because that reasoning has no substitute record.
+- Sequencing rationale or which version is active. Why this task is planned before its neighbors goes on its row in `priority.md`, in the cell that already carries what it is waiting on. Rationale wider than one row has no home at all, so cut it rather than filing it here.
 
 ## Archiving
 

package/claude/skills/claude-roadmap/REQUIREMENT.md

@@ -1,41 +0,0 @@
----
-name: claude-roadmap
-description: Why versions are sequenced from the MVP list alone, what makes a version a usable increment, and the lifecycle gate that stops a second pass
----
-
-# Claude roadmap requirement
-
-## Gap
-
-Without this skill, versions are invented from a sense of what should come next rather than sequenced from the scope the requirements already fixed. Each one reads as a milestone nobody can use, because the ordering follows what feels foundational instead of what a user can then do, and a version that de-risks nothing sits ahead of the subsystem the whole plan rests on. The roadmap then drifts into task-level steps, which duplicates the plan folder and goes stale the first time a file moves.
-
-An update is where the file quietly breaks. Rewriting rows that never changed hides the one line that moved, so a reader diffing the roadmap learns nothing from it. And a project whose MVP already shipped gets its later scope sequenced here, which puts a fresh requirements pass's work into a file that only ever sequenced the MVP.
-
-## Must
-
-- Sequence from the MVP list in the requirements file and name it as the source
-- Make every version a usable increment, stated as what the user can then do
-- Order by dependency and by de-risking, placing an unproven subsystem inside the version that first needs it
-- Preserve rows that still hold when updating, resequencing or splitting only where scope shifted
-- Follow the reference for the document shape and version format rather than inventing one
-- Report which versions changed on an update
-
-## Must not
-
-- Break a version into task-level steps or a file list
-- Rewrite a row that did not change
-- Sequence a later scope section without an explicit override from the caller
-- Stage or commit the file, which is tracked but belongs to the git skills
-
-## Guards
-
-- Requirements file absent or carrying no MVP features: stop, because there is nothing to sequence
-- A later scope section present after the MVP list: stop and name the override, since that scope belongs to a fresh requirements pass
-- Neither copy of the requirements standard resolves: draft without the lifecycle gate. Refusing on a rule that could not be read stops more than it protects.
-
-## Out of scope
-
-- Task-level steps and file lists, which `claude-feature` and the task board own
-- Writing the requirements being sequenced
-- Committing the file, which the git skills own
-- Deciding what to build next once the MVP list has shipped

package/claude/skills/claude-roadmap/SKILL.md

@@ -1,61 +0,0 @@
----
-name: claude-roadmap
-description: Drafts or updates `.claude/ROADMAP.md` by sequencing the MVP scope from `.claude/REQUIREMENTS.md` into ordered versions, each a usable increment. Use when asked to "draft a roadmap", "build the roadmap", "sequence the versions", "plan the roadmap", or "update the roadmap". Do NOT break versions into task-level steps. That is `claude-feature` and `.claude/tasks/`.
----
-
-# Claude roadmap
-
-## Guards
-
-- If `.claude/REQUIREMENTS.md` is absent or has no MVP features, stop: `❌ No requirements to sequence. Draft .claude/REQUIREMENTS.md first.`
-- If the requirements file carries a later scope section, stop per Lifecycle gate below
-- Sequence versions and their outcomes only. Do not produce file lists or task steps.
-
-## Lifecycle gate
-
-A roadmap sequences the MVP list alone, so a later scope section means that list has shipped and a fresh requirements pass owns what follows. The rule is the Lifecycle section of `.claude/standards/requirements.md`, falling back to `${CLAUDE_SKILL_DIR}/../../standards/requirements.md` when the project has no copy.
-
-- A later scope section is a `##` heading after `## MVP features` that `.claude/standards/requirements.md` names nowhere, neither among the six it fixes nor as the conditional `## Distribution`
-- On finding one, stop: `❌ MVP scope already sequenced. ## <section> is later scope, which a fresh requirements pass sequences rather than this roadmap. Say to sequence it anyway to override.`
-- Draft without the gate when neither copy of the standard resolves. Refusing on a rule that could not be read stops more than it protects.
-- When the caller overrides, sequence the later scope section's entries as versions and proceed
-
-## Step 1: read context
-
-Read these in parallel from the project root, skipping any that do not exist:
-
-- `.claude/REQUIREMENTS.md`: the MVP feature scope to sequence
-- `.claude/ROADMAP.md`: the existing roadmap, when updating rather than drafting
-- `.claude/tasks/index.md`: what is in flight, to mark the active version
-- `.claude/ARCHITECTURE.md`: technical dependencies that constrain ordering
-
-Follow `${CLAUDE_SKILL_DIR}/references/roadmap.md` for the doc shape, sections, and version format.
-
-## Step 2: sequence
-
-Group the MVP features into versions, each a usable increment that stands on its own. Order the versions by two forces:
-
-- Dependency: a version that produces data or a contract another version consumes comes first.
-- De-risking: a version that de-risks an unproven subsystem comes early, inside the version that first needs it.
-
-For each version, state the observable outcome as what the user can then do, list the features it groups by name, and note what it depends on and why.
-
-When updating an existing roadmap, preserve rows that still hold. Resequence, add, or split only where scope shifted. Do not rewrite rows that did not change.
-
-## Step 3: write
-
-Write the roadmap to `.claude/ROADMAP.md` at the project root, following `${CLAUDE_SKILL_DIR}/references/roadmap.md`. Create the file when absent.
-
-Unlike `.claude/plans/` and `.claude/tasks/`, `.claude/ROADMAP.md` is committed. Do not stage or commit it here. Leave staging to the git skills.
-
-## Step 4: output
-
-```markdown
-📝 Wrote .claude/ROADMAP.md
-
-<N> versions sequenced. Active: vX.Y.
-
-Next: /claude-feature for the first version's opening feature.
-```
-
-When updating, replace the first line with `📝 Updated .claude/ROADMAP.md` and name which versions changed.

package/claude/skills/claude-roadmap/references/roadmap.md

@@ -1,62 +0,0 @@
----
-title: Roadmap reference
-description: Shape and content rules for .claude/ROADMAP.md
-consumers: claude-roadmap
----
-
-# Roadmap reference
-
-Applies to `.claude/ROADMAP.md`. Sequences the scope from `.claude/REQUIREMENTS.md` into ordered versions, each a usable increment. Update when the sequence changes or a version ships. The roadmap is committed because the sequence and its rationale are shared strategic truth a fresh session needs, unlike `.claude/tasks/`, which is ephemeral scratch.
-
-The roadmap is one scannable table. That is what keeps it distinct from `.claude/tasks/`: the roadmap is an overview read at a glance, while tasks are worked one file at a time.
-
-## Scope
-
-Governs the sequencing document at `.claude/ROADMAP.md`: the version table, its columns, and its lifecycle.
-
-Does not govern:
-
-- What the scope is, which the roadmap sequences rather than defines: `requirements.md`
-- Task files, outcomes, and board state: `tasks.md`
-- Phase-label format and semver discipline: `versioning.md`
-- Rationale for a technical choice: `architecture.md`
-
-## What goes in
-
-- One row per version, ordered top to bottom by sequence
-- A status per version: active, next in line, or deferred
-- The observable outcome each version delivers, as a short phrase
-- The features a version groups, by name, drawn from the MVP list in `.claude/REQUIREMENTS.md`
-- The version each row depends on, and a short why
-
-## What does not go in
-
-- Task breakdown, checkboxes, or per-feature file lists
-- Implementation detail, API names, or component references
-- Sentence-long cells. Keep each cell terse so the table stays scannable.
-
-## Format
-
-One table. Columns, in order:
-
-- `Version`: the `vX.Y` phase label. Phase-label format is governed by `standards/versioning.md`.
-- `Status`: `Now` for the active version, `Next` for sequenced upcoming versions, `Later` for deferred themes.
-- `Outcome`: what the user can do once this version ships, as a phrase.
-- `Features`: the feature names this version groups, comma-separated.
-- `Depends on`: the version this one needs and a short why, or `none` when independent.
-
-## Template
-
-```markdown
-# Roadmap
-
-| Version | Status | Outcome  | Features             | Depends on         |
-| ------- | ------ | -------- | -------------------- | ------------------ |
-| v0.1    | Now    | <phrase> | <feature>, <feature> | none               |
-| v0.2    | Next   | <phrase> | <feature>            | v0.1, for <reason> |
-| v0.3    | Later  | <phrase> | <feature>            | none               |
-```
-
-## Lifecycle
-
-The roadmap sequences a finite, known scope. When the last version ships, the scope is exhausted and the project cuts a semver release per `standards/versioning.md`. Later work arrives as discrete items, a fresh requirements pass or tracked issues, rather than extending the original roadmap without end.

package/standards/bundled/roadmap.md

@@ -1,62 +0,0 @@
----
-title: Roadmap reference
-description: Shape and content rules for .claude/ROADMAP.md
-consumers: claude-roadmap
----
-
-# Roadmap reference
-
-Applies to `.claude/ROADMAP.md`. Sequences the scope from `.claude/REQUIREMENTS.md` into ordered versions, each a usable increment. Update when the sequence changes or a version ships. The roadmap is committed because the sequence and its rationale are shared strategic truth a fresh session needs, unlike `.claude/tasks/`, which is ephemeral scratch.
-
-The roadmap is one scannable table. That is what keeps it distinct from `.claude/tasks/`: the roadmap is an overview read at a glance, while tasks are worked one file at a time.
-
-## Scope
-
-Governs the sequencing document at `.claude/ROADMAP.md`: the version table, its columns, and its lifecycle.
-
-Does not govern:
-
-- What the scope is, which the roadmap sequences rather than defines: `requirements.md`
-- Task files, outcomes, and board state: `tasks.md`
-- Phase-label format and semver discipline: `versioning.md`
-- Rationale for a technical choice: `architecture.md`
-
-## What goes in
-
-- One row per version, ordered top to bottom by sequence
-- A status per version: active, next in line, or deferred
-- The observable outcome each version delivers, as a short phrase
-- The features a version groups, by name, drawn from the MVP list in `.claude/REQUIREMENTS.md`
-- The version each row depends on, and a short why
-
-## What does not go in
-
-- Task breakdown, checkboxes, or per-feature file lists
-- Implementation detail, API names, or component references
-- Sentence-long cells. Keep each cell terse so the table stays scannable.
-
-## Format
-
-One table. Columns, in order:
-
-- `Version`: the `vX.Y` phase label. Phase-label format is governed by `standards/versioning.md`.
-- `Status`: `Now` for the active version, `Next` for sequenced upcoming versions, `Later` for deferred themes.
-- `Outcome`: what the user can do once this version ships, as a phrase.
-- `Features`: the feature names this version groups, comma-separated.
-- `Depends on`: the version this one needs and a short why, or `none` when independent.
-
-## Template
-
-```markdown
-# Roadmap
-
-| Version | Status | Outcome  | Features             | Depends on         |
-| ------- | ------ | -------- | -------------------- | ------------------ |
-| v0.1    | Now    | <phrase> | <feature>, <feature> | none               |
-| v0.2    | Next   | <phrase> | <feature>            | v0.1, for <reason> |
-| v0.3    | Later  | <phrase> | <feature>            | none               |
-```
-
-## Lifecycle
-
-The roadmap sequences a finite, known scope. When the last version ships, the scope is exhausted and the project cuts a semver release per `standards/versioning.md`. Later work arrives as discrete items, a fresh requirements pass or tracked issues, rather than extending the original roadmap without end.