Files

Defame1297 3920dfab20 fix(skills): drop references to deleted config and .mcp.json files

Closes four PR #135 review findings in skill content.

#2 — plugins/git/config.example.json was deleted in f5e4d0d, but four
git-plugin files still told the agent to read it. The file only ever
carried branching_pattern, commit_style and rebase_strategy, so the
`base_branch` and scope instructions were wrong even before the
deletion. Each site now describes what the skill actually does: base is
`main` under GitHub Flow or `develop` when Gitflow is inferred, the
Gitflow fallback keys off the repo's own branches, the orchestrator
contract's `base` defaults to the inferred base branch, and the commit
scope is inferred from the changed files.

N6 — gitea-prs was the one gitea skill with no permission-scope caveat
on a 404. Added one alongside the existing issue/PR number-space
guidance rather than replacing it: a 404 is only evidence of
"that number is an issue" once write:repository scope is confirmed.

N4 — plugins/kyberforge/bin/README.md pointed at `.mcp.json`, but all
six plugin-root .mcp.json files were deleted in c96ca9c (ADR-0018).
${CLAUDE_PLUGIN_ROOT} itself is still live, so the sentence now points
at .apm/hooks/hooks.json, which kyberforge's own hook already uses.

N7 — not applied. The finding claimed a marketplace field override
emits a verbose BuildDiagnostic that `apm pack -v` surfaces, so
"silently wins" was wrong. apm 0.28.0 does construct the diagnostic in
marketplace/output_mappers.py, but nothing renders it:
_render_marketplace_result in commands/pack.py iterates `warnings`
only, and BuildReport.diagnostics has no consumer. Confirmed on a
fixture — neither `apm pack -v` nor APM_LOG_LEVEL=DEBUG prints the
override, and --check-versions reports [matches]. The existing wording
in configure.md and marketplace.md is correct, so both are unchanged.

Version bumps required by check-skill-version-bump.sh: git-branches
1.0.4 -> 1.0.5, git-commits 0.1.6 -> 0.1.7, gitea-prs 0.1.4 -> 0.1.5.
bin/README.md is outside any skill directory and needs no bump.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NwD8Egs5r4ndqeFLmhusX2

2026-09-19 21:17:14 +00:00

2.1 KiB

Raw Blame History

source_keys

conventional-commits-spec

commitlint-config-conventional

org-commit-conventions

Creating a new commit

Gather context — what changed and why, from the staged diff, the PR description, or the issue. Confirm the staged diff is one logical, independently reviewable and reversible change that leaves the repository buildable and testable. If it bundles unrelated work, suggest splitting it before going further.
Determine the type — read it off the change itself: a new user-visible feature is feat, a bug fix is fix. For the full 11-type set and each type's SemVer impact, read references/conventional-commits-spec.md.
Determine the scope — infer it from the files changed (api, db, cli, config). Scope is optional, but it identifies which part of the system moved and is worth setting.
Write the description — imperative mood, no trailing period: "add user authentication", "fix race condition in cache". Neither source spec sets a target below the 100-character header maximum, but convention favours roughly 50 characters so git log --oneline stays readable.
Add a body when the change is non-trivial — blank line first, wrapped at 100 characters. Explain why, not what: the diff already shows what changed, and the message's job is the context the diff cannot carry — motivation, root cause, tradeoffs. Follow the Why / Implementation Notes / Impact structure in references/commit-template.md.
Add footers where they apply — Fixes: #123, Refs: #123, ADR: 0012, Co-authored-by: Name <email>, BREAKING CHANGE: description. For the full trailer list, read references/commit-template.md.
Signal a breaking change with ! before the colon — feat!: drop Node 6 is visible in git log --oneline, where the BREAKING CHANGE: footer alone is machine-readable but hidden. Use both when the break needs describing.
Validate, confirm, execute — check header length, type, lowercase subject and trailing period against commitlint, show the message, and commit only once the caller has approved. Never add --no-verify.

2.1 KiB Raw Blame History

Creating a new commit

2.1 KiB

Raw Blame History