Closes four PR #135 review findings in skill content. #2 — plugins/git/config.example.json was deleted inf5e4d0d, 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 inc96ca9c(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
3.8 KiB
3.8 KiB
name, description, metadata, allowed-tools
| name | description | metadata | allowed-tools | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| git-commits | Use when creating, amending, squashing, or cherry-picking commits, including writing and validating the Conventional Commits message. Not history inspection -> `git-history`. Not branch lifecycle -> `git-branches`. |
|
Bash |
Gotchas
- Run git as
rtk git <subcommand>, never baregit— org convention, in&&chains too. Run it bare only when rtk would break it: output a script parses, or a command that opens an interactive editor (rebase -iinreferences/rewrite-history.md). Say why inline. - Refuse to force-push
main/master. A rewrite diverges the branch and the reflex is to force it back — safe only where nobody else has based work on it. reset --hardis a confirmation gate, not a default. It overwrites the working tree, and uncommitted edits it discards were never in git, so no reflog recovers them. Name what will be lost and offer a stash first.- Never add
--no-verify— using it when a hook fails bypasses the QA gate the pipeline depends on. Only on the user's explicit demand, with a warning.
Dispatch
Read exactly one flow file. Each is self-contained.
| Condition | Flow | Read |
|---|---|---|
| Composing a new commit from staged changes | create | references/create-commit.md |
| Amending, squashing, folding a fixup, rebasing onto a new base, or resetting HEAD | rewrite | references/rewrite-history.md |
| Replaying an existing commit onto the current branch | cherry-pick | references/cherry-pick.md |
Gates on every flow
- Confirmation. No history rewrite executes without explicit approval from the user or the calling agent. Cherry-pick needs the destination branch confirmed first.
- Atomicity. The result must be one logical, independently reviewable and reversible change that leaves the repository buildable and testable. This binds an amend or a squashed result as much as a fresh commit — say so before writing it, not after.
- Secrets. Before any commit or amend, scan the staged diff for anything resembling an API key, token, password, connection string, or environment-specific config. Stop and flag it rather than committing it.
- Validation. Check the message against commitlint
config-conventionalbefore committing. If a type, footer, or breaking-change edge case is not obvious, readreferences/conventional-commits-spec.md— it carries the constraint table, the 11-type set, and the footer token rules. - SemVer impact. Report the bump the commit implies:
feat→ MINOR,fix/perf/revert→ PATCH, any breaking change → MAJOR, everything else → none. Callers decide releases from this, so never omit it. - Conflicts. If a rebase or cherry-pick halts, offer resolution or an abort. Do not resolve automatically without confirmation.
Output
For an agent caller, return:
{
"operation": "create|amend|squash|cherry-pick",
"status": "success|conflict|rejected",
"message": "commit message or error description",
"commit_hash": "abc1234",
"semver_impact": "MAJOR|MINOR|PATCH|none",
"breaking_change": false,
"confirmation_required": false,
"details": {
"type": "feat",
"scope": "api",
"description": "add user authentication",
"body": "optional body text, or null",
"footers": ["Fixes: #123", "Refs: #456", "Co-authored-by: Bob <bob@example.com>"]
}
}
details.footers is an array of the resolved trailer lines, empty when there are none — never a
single joined string, and never omitted. Downstream agents index it.
For a human caller, show the same fields as a prose preview with a confirmation prompt.