Files

T

Brummel 69034747c6 feat(install): add --force to repoint symlinks; document worktree caveat

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

2026-06-30 14:16:44 +02:00

2.3 KiB

Raw Blame History

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 facts heading.
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, 4-digit 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.

2.3 KiB Raw Blame History