An adversarial review of 08bc2aa found three gaps:
- templates/CLAUDE.md.fragment still described the OLD git-tracked /
git-rm-at-close model verbatim — the worst place to miss it, since new
projects import this fragment into their CLAUDE.md. Rewritten to the
gitignored / shell-rm / ledger-only model.
- INSTALL.md still cited "4-digit naming" — now slug-only.
- The fieldtest cross-cycle deletion rule was self-defeating: it keyed
the spare/delete decision on the permanent fieldtest- prefix, which
cannot encode "spare once, then delete." Because fieldtest runs only
AFTER audit closes, the fresh fieldtest spec never exists at the
cycle-close sweep, so the rule is simply "audit discards every
working-tree spec/plan"; the spent fieldtest spec present at N+1's
close was already consumed and goes with the rest. The prefix is now
only a working-tree label, not a delete discriminator. Reconciled
across audit, conventions, pipeline, fieldtest, fieldtester.
2.3 KiB
Install
Prerequisites
- Claude Code with
~/.claude/writable - bash or any POSIX shell to run
install.sh
One-time global install
git clone <repo-url> ~/dev/skills
cd ~/dev/skills
./install.sh
install.sh creates symlinks from ~/.claude/skills/ and
~/.claude/agents/ into this repo. Claude Code discovers them
at session start under user-level skill and agent registries,
so they become available in every project without further setup.
To uninstall:
~/dev/skills/uninstall.sh
Per-project activation
There is no profile file. A project activates the plugin through its
own CLAUDE.md — which the skills read as standing reading on every
dispatch. Two things go in it:
- Project facts — the handful of mechanical facts the skills
consume (code roots, build/test command, issue-tracker slug, …),
under a
## Skills plugin: project factsheading. - Sittenkodex — feature acceptance criteria, anti-patterns the project has earned the hard way, domain-specific contracts.
A starter for both lives in templates/CLAUDE.md.fragment: the
universal discipline sentences (only-orchestrator-commits, main
sacrosanct, …) plus a commented ## Skills plugin: project facts
template. Copy what you need into the project's CLAUDE.md and fill
it in:
$EDITOR <project-root>/CLAUDE.md # paste from templates/CLAUDE.md.fragment
Everything the plugin does not read from project facts is a fixed
convention (spec dir docs/specs, slug-only naming, the pipeline graph,
…) documented once in docs/conventions.md and docs/pipeline.md —
not configurable per project.
Update
cd ~/dev/skills && git pull
Symlinks pick up the changes automatically. If new skills or
agents have been added, re-run install.sh to add the new
symlinks (it is idempotent and will not overwrite existing
ones — pass --force to repoint a symlink that points at a
different checkout).
Worktrees
The symlinks target the absolute path of the clone install.sh was
run from. Develop this plugin only in that primary clone, never from a
git worktree: a running session loads skills, agents, and workflows
through the symlinks regardless of cwd, so worktree edits are not what
it executes (see CLAUDE.md). To take the live set over from a
different checkout, run ./install.sh --force from it.