2bc0cf025f
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.
74 lines
2.3 KiB
Markdown
74 lines
2.3 KiB
Markdown
# Install
|
|
|
|
## Prerequisites
|
|
|
|
- Claude Code with `~/.claude/` writable
|
|
- bash or any POSIX shell to run `install.sh`
|
|
|
|
## One-time global install
|
|
|
|
```sh
|
|
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:
|
|
|
|
```sh
|
|
~/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:
|
|
|
|
1. **Project facts** — the handful of mechanical facts the skills
|
|
consume (code roots, build/test command, issue-tracker slug, …),
|
|
under a `## Skills plugin: project facts` heading.
|
|
2. **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:
|
|
|
|
```sh
|
|
$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
|
|
|
|
```sh
|
|
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.
|