spec-spine: Skill for Claude Code

/commit

Create a git commit following these steps. Text that lands in git is public under the author's name: the banned list at the end is not optional.

0. Preflight

• git branch --show-current is not the default branch. Work lands on a feature branch, named after the spec id when it implements one; the push hook refuses the default branch anyway, but do not get there.
• The gate has run green on this tree since the last edit (the command list in AGENTS.md "Working the backlog", "Run the gate before every commit"). If it has not, run it now; a commit on a red gate is a commit that will be amended.
• git diff --stat -- .derived/: shards the gate regenerated belong in this commit with the change they describe. build-meta.json is gitignored, so git add .derived/ is safe. Never stage the tool-state directory spec-spine.toml [layout] state_dir names.

1. Survey the changes

git status
git diff --cached
git diff
git log --oneline -5

Identify what is staged versus unstaged, the nature of each change (feature, fix, refactor, docs, test, chore, ci), and the user-visible impact. Match the scoping visible in recent history.

2. Draft a conventional-commit message

Format: type(scope): subject

Type (required): feat, fix, refactor, docs, test, chore, ci.

Scope: the three-digit ordinal of the spec the change implements or amends: feat(017): ..., fix(011): ..., docs(024): .... Several specs: feat(045,046): .... A shard-only regeneration uses chore(derived): ...; a release bump chore(release): ...; a change with no owning spec uses an area name (ci(workflows): ...).

Subject line:

• 72 characters maximum (hard limit; count them).
• Lead with the impact or problem solved, not the technique used.
• No trailing period. No emojis. No em dash.

Good versus bad:

• BAD: refactor(017): extract helper for parent sorting
• GOOD: feat(017): ledger entries reject unsorted or duplicate parents
• BAD: fix(005): update validation
• GOOD: fix(005): the coupling gate names the owning spec on C-001