Git-native · the repo is the store

Skill Registry

7 skills, read straight from their SKILL.md files. Every version is a git commit; edits happen in your editor and flow through the loop. Click any skill for its frontmatter, body, and history.

Process

finish-featureany stack

Close out a feature branch on any stack — tests green, PR that Closes the issue, spec status, changelog fragment. Use when the user says "wrap up", "finish the feature", "ship it", "open the PR", or the implementation work on an issue is done. Pairs with /start-feature.

user-levelmodel + manual
start-featureany stack

Kick off a new feature or work stream on any repo's GitHub Projects board. Use when the user says "start on <feature/brief>", "pick up issue #N", "begin the <X> work", "work the next thing", or points at an issue. Sets up the issue, branch, and consult-first flow; pairs with /finish-feature.

user-levelmodel + manual
update-docsany stack

Route new work and doc changes — GitHub issues for live work; files only for design docs and history. Use when the user says "track this", "capture that bug/idea", "where does this go", "log a decision", "add a spec", or describes work that needs recording.

user-levelmodel + manual

Reviews

crucible-blazorBlazor / .NET

Unusually strict, refactor-oriented code-quality review for .NET / Blazor projects — vertical-slice architecture, outcome-oriented SOLID, structural simplification, Blazor component-layer guidance. Use for PR review, "crucible", or when enforcing VSA on a Blazor/.NET repo. Install one crucible variant per repo, matched to its stack (sibling: crucible-nextjs).

user-levelmanual onlydisable-model-invocation
crucible-nextjsNext.js / React

Unusually strict, refactor-oriented code-quality review for Next.js / React / TypeScript projects — vertical-slice (feature-folder) architecture, outcome-oriented SOLID, structural simplification, server/client-boundary and RSC guidance. Use for PR review, "crucible", or when enforcing feature-slice structure on a Next.js repo. Install one crucible variant per repo, matched to its stack (sibling: crucible-blazor).

user-levelmanual onlydisable-model-invocation

Autonomous

night-shiftany stack

Autonomous overnight loop — pick the next eligible board issue and drive it start → implement → crucible review → refactor → PR without a human, stopping at any real decision fork. Meant to be launched by a scheduled task while you sleep. Opens PRs, never merges. Leaves a morning report.

user-levelscheduler-fired

Recall

historyany stack

Reconstruct the full history of an issue, feature, or topic — what we've tried, in order, and what happened each time. Use when the user asks "what did we do last on X", "what have we tried on <issue/topic>", "history of #N", "previous attempts", "catch me up on <area>", or points at an issue and wants the backstory.

user-levelmodel + manual
Why Crucible is "manual only." The reviews carry disable-model-invocation: true— a deliberate, heavy review you run on command, not something that auto-fires on "review this." night-shift must NOT have that flag: it would stop a scheduled task from firing the skill.

Where skills live — user vs. project level

◆ User level (all seven canonical skills)

  • Installed once by scripts/install-skills into ~/.claude/skills/ — the single install root
  • Cursor discovers the same directory through its compatibility roots — no second copy (it would double-list every skill in Cursor's slash menu)
  • Shared by every project on the machine
  • Update in one place — the repo's skills/ is the source of truth; re-run the script to sync

◆ Project level (the override)

  • A repo may carry .claude/skills/<name>/ (or .cursor/skills/<name>/)
  • Wins by name over the user-level skill — the escape hatch for a repo that needs a custom variant
  • None of the canonical skills require this; per-repo variation belongs in GITHUB-PROJECTS.md, not skill forks

One set of skills, both tools: Cursor honors the same SKILL.md standard and scans ~/.claude/skills itself, so the Claude-format skills here are the only skills and ~/.claude/skills is the only install location — nothing Cursor-specific is ever authored or copied. (Older Cursor builds that read only ~/.cursor/skills: run the install script with --include-cursor / -IncludeCursor.)

Frontmatter — shared vs. platform extensions

Author one SKILL.md. The shared fields work in both tools; Claude Code's extensions are additive and silently ignored by Cursor.

✅ Shared (portable — define once)

  • name — identifier / display name
  • description — what it does + when to trigger
  • disable-model-invocation — invoke-only, honored by both
  • Supporting files / references — markdown links to files in the skill folder, loaded on demand

➕ Claude Code extensions (ignored by Cursor)

  • allowed-tools / disallowed-tools
  • context: fork + agent (subagent run)
  • model · effort · argument-hint · arguments
  • hooks · paths · ${CLAUDE_SKILL_DIR} path substitution

Rule of thumb: keep anything that must work in both tools in the shared fields and the body. Use Claude-only fields only as enhancements that degrade gracefully — never for behavior Cursor needs to get right.

References (supporting files)

Both tools support the same progressive-disclosure pattern: drop extra files (reference.md, examples.md, scripts/) in the skill folder and link them from SKILL.md; the agent loads them on demand. Claude Code adds ${CLAUDE_SKILL_DIR}so bundled scripts resolve wherever the skill is installed. Our skills don't need references yet — but this is how you'd bundle, say, a shared VSA cheat-sheet with the Crucible reviews.

Each skill's full text, frontmatter, and version history is one click away above — read live from skills/. See Setup for where to install them per platform.