Extending
Add to the config
- Add a language rule: drop a lean
rules/<lang>.mdwithpaths:frontmatter (Tier 1) and, if it needs depth, areferences/<lang>.mdit points to (Tier 2). - Vendor another subagent: copy the
.mdintoagents/, add a row with its source + commit SHA toAGENTS_SOURCES.md. - Add a command/skill: cherry-pick from
qdhenry/Claude-Command-Suite
into
skills/, record it inskills/SOURCES.md. - Update a pinned asset: re-fetch at a newer commit, replace the file,
bump the SHA in the relevant
SOURCES.md. - Per-project memory: copy
templates/CLAUDE.project.mdto a repo’s./CLAUDE.mdand fill it in. Codebase-specific facts belong there, not global.
Each addition should name the concrete pain it removes.
Releasing the Claude Code plugin
Tagged releases, not rolling — a plain /plugin marketplace add tracks the
default branch, so cutting a release is what gives anyone who wants to pin a
version something to point at:
# 1. bump the version in .claude-plugin/plugin.json
# 2. tag + push (validates plugin.json and the marketplace entry agree)
claude plugin tag --push -m "addit-harness %s"
# 3. publish release notes, using the tag claude plugin tag just created
gh release create addit-harness--v<version> --notes "..."
claude plugin tag creates an addit-harness--v<version> tag (not a bare
vX.Y.Z) and refuses a dirty working tree or a duplicate tag unless
--force; pass --dry-run to preview first.
Versioning is manual, not tag-derived. plugin.json’s version field is
the source of truth — claude plugin tag reads it and creates a matching
git tag (and errors if plugin.json and the marketplace entry disagree); it
does not go the other direction and infer a version from existing tags. So
step 1 above (bump version by hand) always comes first.
The release.yml workflow
runs this exact sequence in CI — trigger it with workflow_dispatch instead
of running the commands locally. See the Changelog for what
that produces.