recursive-spine-method

name	recursive-spine-method
description	Use when a builder wants to learn or be reminded of the recursive-spine tracking convention — where work state lives (GitHub issues+milestones, never prose ledgers), the five principles, the module system, and how to design a repo's dialect. Pure knowledge; takes no actions.

recursive-spine: the method

Read ${CLAUDE_PLUGIN_ROOT}/reference/principles.md and teach from it. Do not paraphrase the principles loosely — state them exactly, then explain. Issues also carry macro/micro depth — moment-triggered sub-issue trees — per the depth section of the same principles doc.

How to teach it

1. Open with the failure mode, not the rule: prose ledger files (status files, queue tables) merge as text; rows get lost silently; every branch edits them so they become the repo's #1 conflict source. The convention exists because that failure was measured, not imagined.
2. State the five principles verbatim from the reference.
3. Explain the recursion doctrine: the convention was built under itself (issues before code, self-bootstrap, self-digest) and any adopting repo can hold it to that standard.
4. Walk the module system: deferral label mandatory; gap/debt/lane/ pollination optional. Ask which failure modes the user actually has before recommending modules.

Dialect design

Each repo keeps its own vocabulary ON TOP of the principles. Guide the user:

• What do you call a unit of work today? (W-item, ticket, task…) That word maps to "issue".
• Do you run assessments that produce findings? If yes → gap module.
• Do finished units hand incomplete edges to the next unit? If yes → debt module.
• Do you route work across model tiers or people? If yes → lane module, renamed to fit.
• Do elements that proved themselves in one project die there? If yes → pollination module (recursive-spine-pollinate).
• Does closing a unit need its record assembled — debts filed, the pollen question asked, state pointers captured? If yes → recursive-spine-handover posts the closing comment on the issue.
• Does the repo need the rest of its spine — rules codex with a moments map, ADR directory, CI gate skeleton, session-memory convention? If yes → recursive-spine-scaffold (frames + the builder's interview + proven pollen; every part optional, declines recorded). Record the answers as a short dialect note the repo keeps in its docs.

Vocabulary seams

Same words, different plugins — don't conflate: spine "handover" = a closing unit filing its debt issues (principle 4). tokenomics "handoff" = a down-tier work spec crossing model tiers. plumb-line "handoff" = a skill-to-skill baton pass within one session. plumb-line's internal "spine" (null-result expressibility) is unrelated to this plugin's name.

What this skill never does

No writes, no gh calls, no repo changes. If the user wants the convention installed, name recursive-spine-bootstrap. If they have an existing prose ledger, name recursive-spine-migrate. If something just proved itself and should travel, name recursive-spine-pollinate. If a unit of work is closing, name recursive-spine-handover. Suggest; never auto-invoke.