v1.23.0: step 25d — a prompt index row rots on a different clock from the page it points at

[wan-huiyan]

Step 26a makes the next prompt reachable. Nothing made it true.

A one-row-per-prompt index (docs/handoffs/next_session_prompt.md and its equivalents) and the pages it links to are two copies of the same claim, written by different sessions at different times — and the row is what a fresh session reads first. Nothing forces them to agree, and the skill had zero coverage of this (0 hits for "index row" across 1,446 lines).

Measured 2026-08-07: both rows on one index wrong, in opposite directions, while both pages were current

the row said	reality	cost to a reader
"what is left is four files and five ledger entries, verified absent from main"	all four present; the page's own foot already said "the file restoration is finished"	advertised finished work as the remaining work — the actual remainder, a content audit nobody had started, went unadvertised
"expect main to be red for reasons of its own (#839)"	#839 closed, main measured green	pre-authorised the reader to ignore red

The second is the dangerous direction. A stale "expect it to be broken" does not merely misinform — it disables a check. That is how a real failure gets waved through, and it is why the step calls out any row that lowers a future reader's guard as load-bearing.

The step

25d, placed beside 25c on purpose: 25c checks your own work survived; 25d checks the pointer to the next work is accurate. Three cheap checks —

1. Re-derive the row's headline claim, don't re-read it. "Four files are missing" → list them at origin/main. "main is red" → run the suite, or check the issue is still open.
2. Confirm the row agrees with its own page. A page corrected at its foot while the row keeps the superseded summary is the normal failure, not a rare one — that is exactly what had happened to both.
3. Grep the figure across the repo, not just the row you were looking at. The same stale sentence had also been pasted into a ledger entry.

Plus two things the same defect produces:

• Closing the row is part of closing the item. A row still marked live for a merged PR sends the next session to a branch that no longer exists — the same shape as an issue telling its reader to extend a file that has since been deleted.
• One structural check: is the page's remaining work at the TOP? A prompt that grows by appending dated corrections ends up as a long finished job with the live work in a coda after the archive, and a reader working top-down re-runs the completed part. Measured at 200 lines of finished work ahead of a ten-line remainder.

The gate earned its keep, which is the other half of this

I wrote it against npm test rather than from memory, and that caught what memory would not: the version lives in five places and my first pass found three.

• npm test failed on SKILL.md frontmatter — my grep '"version"' missed it because YAML is version:, not "version":. Sweep-by-value, caught by your gate rather than by me.
• Then the marketplace manifest, then the README Version History entry.

Final: 77 passed, 0 failed, 2 skipped.

Note on a sibling PR

Open PR #18 is also labelled v1.22.0, which origin/main already shipped (as #19). It will need renumbering — this PR takes 1.23.0. That is the collision your own session-handoff-number-collision-with-unmerged-sibling skill describes.

Authored in a dedicated worktree rather than in the repo's checkout, which was sitting on another branch (learn/own-work-survival-check).

🤖 Generated with Claude Code