| 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
- 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.
- State the five principles verbatim from the reference.
- 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.
- 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.
