bump-core-req
Updates the minimum core version requirement for a fleet plugin in all three canonical places: `required_core_version` and `requires["claude-code-hermit"]` in…
Documentation-drift audit for the plugin monorepo. Audits either each scoped plugin's unreleased changelog claims or its latest shipped release from the previous reachable plugin-name--v* tag, then checks whether the matching plugin README, docs/, CLAUDE.md or AGENTS.md files,
$ npx -y skills add gtapps/claude-code-hermit --skill docs-drift --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/docs-driftContext preview
The summary Claude sees to decide when to auto-load this skill.
Documentation-drift audit for the plugin monorepo. Audits either each scoped plugin's unreleased changelog claims or its latest shipped release from the previous reachable plugin-name--v* tag, then checks whether the matching plugin README, docs/, CLAUDE.md or AGENTS.md files,
name: docs-drift description: Documentation-drift audit for the plugin monorepo. Audits either each scoped plugin's unreleased changelog claims or its latest shipped release from the previous reachable plugin-name--v* tag, then checks whether the matching plugin README, docs/, CLAUDE.md or AGENTS.md files, and root documentation still tell the truth. Reports meaningful drift with concrete proposed edits and asks before applying anything. Use when preparing or verifying a release, when asked to check the latest version, or when the operator says "docs drift", "check the docs", "are the docs up to date", "docs audit", "did the docs keep up", "check documentation before release", or whether documentation matches released or unreleased changes. Complements /pre-release-review, which checks changelog claims against code; this skill checks changelog claims against docs.
The third leg of the release check. `/release-status` shows what is queued, `/pre-release-review` verifies that the changelog tells the truth about the code, and this skill verifies that the docs tell the truth after the change.
**Read-only until the operator approves.** The audit never edits, commits, tags, pushes, publishes, or releases. Apply only the findings the operator selects in Step 5.
non-empty `[Unreleased]` section.
plugin.
Default to unreleased mode. Treat "latest version", "latest release", or equivalent wording as latest-release mode.
Natural ordering before a ship:
`/release-status` → `/pre-release-review` → `/docs-drift` → `/release <slug>`
Never mix released and unreleased windows in one claim set.
Identify plugins whose `[Unreleased]` section contains non-blank content:
for p in plugins/*/CHANGELOG.md; do
slug=$(basename "$(dirname "$p")")
awk '/^## \[Unreleased\]/{f=1; next} /^## \[/{f=0} f && NF' "$p" | rg -q '.' \
&& echo "$slug"
doneIf the operator named a plugin, limit scope to that slug after verifying it exists and has unreleased content. If nothing is in scope, stop with:
`No unreleased changes in any plugin — nothing to drift-check.`
Use the working tree as the documentation snapshot. Keep incidentally noticed older drift separate as pre-existing debt.
Start from all `plugins/*/CHANGELOG.md` slugs, or only the operator-named slug. Resolve each plugin's refs independently:
EMPTY_TREE=$(git hash-object -t tree /dev/null)
for p in plugins/*/CHANGELOG.md; do
slug=$(basename "$(dirname "$p")")
latest=$(git describe --tags --abbrev=0 --match "${slug}--v*" HEAD 2>/dev/null || true)
if [ -z "$latest" ]; then
printf '%s\n' "$slug: skipped (no reachable release tag)"
continue
fi
previous=$(git describe --tags --abbrev=0 --match "${slug}--v*" "${latest}^" 2>/dev/null || true)
printf '%s\n' "$slug latest=$latest previous=${previous:-<empty-tree>}"
doneUse only reachable `<slug>--v*` tags. Do not select an unreachable tag merely because its version sorts later. If a plugin has only one reachable tag, use the empty tree as its previous snapshot. If every scoped plugin lacks a tag, stop with:
`No reachable plugin release tags — nothing to latest-release drift-check.`
For each plugin, record:
Later commits and working-tree changes are not release claims in this mode. Different plugins may have different latest-tag snapshots; preserve the plugin-to-tag mapping throughout the audit.
In unreleased mode, read only each scoped plugin's working-tree `[Unreleased]` section.
In latest-release mode, derive the version from `<slug>--v<version>` and read the matching changelog section from the tagged snapshot:
version=${latest##*--v}
git show "$latest:plugins/$slug/CHANGELOG.md" | awk -v ver="$version" '
index($0, "## [" ver "]") == 1 {f=1; next}
/^## \[/ && f {exit}
f
'Also inspect the plugin-scoped release diff to catch doc-checkable operator-visible changes that a changelog bullet may group:
release_diff_base=${previous:-$EMPTY_TREE}
git diff "$release_diff_base" "$latest" -- "plugins/$slug/"Use that diff only in latest-release mode and only for claim discovery. This skill does not replace changelog-versus-code review.
Turn each bullet or diff-derived behavior into zero or more claims:
or CLI changed identity.
hook, CLI, or channel behavior should appear where siblings are enumerated.
or behavior. Treat this as the highest-severity class.
still contain the old value.
the changelog promises.
Mark pure internal fixes, refactors, and test-only changes as `no doc surface`. Do not manufacture a finding for every bullet.
For each scoped plugin, consider the files that exist in its selected snapshot:
`CONTRIBU
If you know Claude Tag, the idea will feel familiar: hand Claude work through a channel, such as Discord, Telegram, or your custom integration, and get results back there.
Repo: gtapps/claude-code-hermit
Updates the minimum core version requirement for a fleet plugin in all three canonical places: `required_core_version` and `requires["claude-code-hermit"]` in…
Changelog and commit — lightweight motion for day-to-day plugin dev work in the monorepo. One commit per plugin scope; CHANGELOG and staging routed by detected…
Explain in plain language what a fix, feature, PR, or plan will actually change for downstream hermits and the operators chatting with them — a before/after…
Use this skill whenever the user wants to release, ship, prep, or cut versions for two or more plugins together on the current branch. Trigger on phrasings…
Daily release-pipeline digest with a change gate — reports which plugins are pending release, whether main's CI is green, which branches went stale, and GitHub…
Pre-release gate for the monorepo — establishes per-plugin release boundaries (each plugin's last tag → HEAD), audits every changed plugin's CHANGELOG against…