No description
  • Python 74%
  • Shell 26%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2026-09-24 16:56:31 -07:00
.claude-plugin touchstone: name the plugin, and make the install instructions true 2026-08-14 18:38:53 -07:00
agents implementer: cannot be woken -- never end a turn waiting, and commit before reporting 2026-09-14 15:14:00 -07:00
assets Add parallel-worktrees skill + optional attention bell 2026-07-24 11:11:49 -07:00
hooks sync from private skills repo 2026-09-24 16:56:31 -07:00
skills sync from private skills repo 2026-09-24 16:56:31 -07:00
.gitignore skills: add reporting-altitude; gate the ADR on decision-brief; broaden the review bar 2026-08-14 13:45:36 -07:00
README.md readme: give updates their own section, covering both install routes 2026-08-14 18:42:32 -07:00

touchstone

Marco Brieden's shared agent skills — the standard engineering work is tested against. One source of truth for cross-repo conventions, instead of copy-pasted CLAUDE.md/AGENTS.md sections that drift.

(The git repo is still named agent-skills; the plugin is touchstone.)

Install

This repo is a Claude Code plugin. Its SessionStart hook prints a trigger index built from each skill's frontmatter, so every skill's load condition reaches context — skill descriptions are not reliably surfaced otherwise, and a skill nobody is reminded of never fires.

Skills are namespaced by the plugin name once installed: /touchstone:adr.

If you are developing these skills — use the skills directory

ln -s /path/to/this/repo ~/.claude/skills/touchstone

Any folder under a skills directory containing .claude-plugin/plugin.json is discovered on the next session and loads as touchstone@skills-dir, in place — no copy, no marketplace, no install step.

That is why this is the author's route: a marketplace install copies the repo into ~/.claude/plugins/cache/ and pins a commit, so your edits would not be live. See Updates for what takes effect when.

If you are consuming these skills — use the marketplace

/plugin marketplace add git@git.k-net.ca:marco/agent-skills.git
/plugin install touchstone@touchstone

(Or claude plugin marketplace add … + claude plugin install … from a shell, for non-interactive setup.)

This install does not update itself by default — see Updates.

Updates

The two install routes get updates completely differently, and the marketplace one is silent about being stale — which is the failure worth knowing about.

Skills directory (the author's route)

Nothing to do. The plugin loads in place from the symlinked repo, so git pull is the update.

Changed Takes effect
A skill's SKILL.md immediately
Hooks, agents, plugin.json /reload-plugins, or next session

Marketplace (everyone else)

Auto-update is off by default, and nothing tells you that. From the Claude Code docs:

Official Anthropic marketplaces have auto-update enabled by default. Third-party and local development marketplaces have auto-update disabled by default.

touchstone is a third-party marketplace, so a fresh install is pinned to the commit it was installed at until someone acts. Two ways to act:

Turn it on once, per marketplace: /plugin → Marketplaces → select touchstone → Enable auto-update. For a team, an admin can set it centrally with "autoUpdate": true on the extraKnownMarketplaces entry in managed settings.

Or pull by hand, whenever you want it:

/plugin marketplace update touchstone
/plugin update touchstone

Two caveats that apply even with auto-update enabled:

  • The check runs after session start, with a random delay of up to ten minutes, and the running session keeps whatever it loaded at launch. You get a prompt to run /reload-plugins, or the new version loads next launch.
  • DISABLE_AUTOUPDATER=1 disables plugin updates too, not just Claude Code's own. To keep plugins updating while pinning Claude Code, also set FORCE_AUTOUPDATE_PLUGINS=1.

Removing the marketplace uninstalls anything installed from it.

Hooks

Hook Fires Does
SessionStart session start Prints the trigger index — every skill's name and load condition — so skills fire on their conditions rather than on memory
PreToolUse (Bash) before a git push Blocks a push unless the repo's real gate passed on the commit being pushed. Opt-in per repo: a .claude-gate file names the one command CI runs, .git/claude-gate-ok records the SHA it last passed on. Repos without .claude-gate are untouched

The push gate exists because a 21-commit deploy failed on lint regressions that the documented pre-push command did not run — the docs and the pipeline had drifted, and ship-discipline already said "run the gate CI runs" and was not invoked. A reminder that can be skipped is what failed, so it blocks.

Skills

Skill Covers
adr ADR conventions + a scaffolding script (numbering, template, index, supersede flow)
decision-brief How a decision gets made before it is recorded: full option set, honest costs, measured-vs-inferred evidence, an invitation to reframe. Feeds adr
merge Landing branches: append-only/generated-file conflict rules, semantic collisions git can't see, gate every merge
plans Implementation plans: decision-free, adversarial pre-flight, deleted on completion
commit-style Commit message conventions and commit granularity
working-agreements Minimal change, narrow scope, dependency approval, never extrapolate a precise spec
doc-freshness Keep repo docs true in the same change as the code
code-shape File splits behind facades, anchor functions, arg structs, tests-next-to-code
director-loop Director/implementer working mode: main session directs, cheap-model subagents implement; dispatch discipline, measurement rules, escalation. Pairs with the agent defs in agents/ (see below)
parallel-worktrees Multiple agents in one repo: worktree + branch per track, director-serialized integration, collision rules
ship-discipline Pre-push shipping: verified suite exit codes (no test && push chains), package-build checks when dependencies change, one deploy per green batch, watched deploys
autonomous-work Unattended/overnight sessions: standing-orders-only scope, stall guards on every background task, watched deploys, risk asymmetry, serialized test resources, the morning report
research-first Evidence base before implementation in researched domains (reward mechanics, sound, UX psychology, health logic…), or when the research is itself the deliverable (report, briefing, purchase evaluation): dispatch decision-feeding research with graded citations, then adversarially verify (refutation pass, deep-reads on load-bearing claims, completeness critic) before the applied ruleset file becomes binding spec — or before a report reaches a human who acts on it

Repo-specific facts (invariants, commands, numeric ceilings, enforcement tools) stay in each repo's CLAUDE.md/AGENTS.md; every skill defers to the repo file on conflict.

Agents

agents/ holds Claude Code agent definitions (not skills — they install to a different directory). They power the director-loop skill:

Agent Model Role
implementer Sonnet (high reasoning) Executes director briefs: code changes, runs, diagnostics. Continue the same one via SendMessage to keep its context
scout Haiku Cheap recon: inventories, shortlists, filename-level scans. Its judgment calls get verified by the director
reviewer Sonnet (high reasoning) Fresh-context adversarial pre-flight of plans/ADRs before approval. Reports findings; changes nothing

Installing (superseded)

The old per-skill symlink setup:

ln -s "$PWD"/skills/* ~/.claude/skills/
ln -s "$PWD"/agents/* ~/.claude/agents/

Do not use this. It symlinks each skill individually, so a skill added here is invisible until someone adds another symlink — two skills sat unreachable that way, and the agents/ never got linked at all, so director-loop was dispatching to agents that did not exist. Symlink the repo into ~/.claude/skills/ instead (see Install); the plugin manifest then carries skills, agents and hooks together and nothing can be half-installed.

Setting up the director-loop working mode

To make director-loop the default (not just available), add this to your global ~/.claude/CLAUDE.md — or just tell Claude Code: "read the director-loop skill in my agent-skills repo and set it up as my default working mode" and it can do the steps itself:

# Default working mode: director loop
For substantive multi-step work (features, iteration loops, migrations,
audits), default to the `director-loop` skill: act as director, dispatch
`implementer` (Sonnet/high) and `scout` (Haiku) subagents, reserve main-
session tokens for planning, review, and decisions. Skip it for trivial
edits and pure Q&A.

What you get: the main (expensive-model) session plans, reviews, and makes accept/revert calls; cheap-model subagents do implementation and recon; you only get pulled in for real decisions, credentials, and sign-offs. The skill file (skills/director-loop/SKILL.md) carries the discipline rules that make it reliable — one change per measured run, interpretation agreed before results, evidence over assertion.

Attention bell (optional)

Have Claude ring a bell — at its own discretion — when it finishes a substantive task or needs your input. Discretionary beats a Stop/Notification hook: a hook rings on every turn end, which is spam; a missed ring is cheap.

One-time setup (run from this repo's root):

cp assets/bell.wav ~/.claude/bell.wav

Add to your global ~/.claude/CLAUDE.md (personal — not a project file):

# Attention bell
When finishing a substantive task or genuinely needing my input
(escalation, blocked, long turn done), ring the bell:
`paplay ~/.claude/bell.wav || aplay -q ~/.claude/bell.wav`
(macOS: `afplay ~/.claude/bell.wav`; Windows: PowerShell Media.SoundPlayer)
Use judgment — don't ring for quick Q&A replies or minor steps. Missing a
ring is fine; spamming is not.

And allow the command in ~/.claude/settings.json so it never prompts:

"permissions": { "allow": ["Bash(paplay ~/.claude/bell.wav*)", "Bash(aplay -q ~/.claude/bell.wav*)"] }

Only the main session rings — subagents don't. Prefer deterministic every-turn ringing instead? Wire the same play command into Stop/ Notification hooks in settings.json.

Editing

Refine a rule here once; every repo picks it up. Don't copy rule text into repo instruction files — add repo-specific deltas there instead.