Brummel
69034747c6
install.sh skipped a symlink pointing at another checkout, so there was no scripted way to take the live set over. Add a --force flag that repoints such divergent symlinks at the invoking clone (default run still skips, stays idempotent). Document in INSTALL.md that the plugin must be developed in the primary clone, not a worktree, and that --force repoints. closes #17
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`, 4-digit 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.
|