← ClaudeAtlas

recursive-spine-methodlisted

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.
slopstopper/recursive-spine · ★ 1 · Code & Development · score 57
Install: claude install-skill slopstopper/recursive-spine
# 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 projec