commit

# Commit Detect which plugin's scope this change belongs to, append a changelog line in that plugin's CHANGELOG, then commit. No push, no tag, no version bump — that's `/release`'s job. ## Guardrails (check before starting) - Clean tree (`git status` shows nothing) → stop and say so, nothing to commit. - Detached HEAD, mid-rebase, or mid-merge → stop and ask the user to resolve that first. - Never `--amend`, `--no-verify`, force-push, or create tags here. - Never use `git add -A` or `git add .` — staging is path-scoped per step 0. - If a pre-commit hook fails, fix the root cause and create a new commit — don't bypass the hook. - **`main` is the default base for everyday work.** Claude Code's `/plugin update` only fires when `version` in `plugin.json` changes, so commits merged to `main` between releases are invisible to operators on the standard install path — `[Unreleased]` accumulates until `/release` ships them. ## Steps ### 0. Detect scope Run `git status --porcelain` and partition the changed paths: - Paths matching `plugins/<X>/...` → group by `<X>` (the slug). - Paths outside `plugins/` (root README, `.github/`, `.claude/`, `.claude-plugin/marketplace.json`, root configs) → "root-scope" paths. Then decide: - **Single plugin slug, no root-scope paths** → set `$PLUGIN_DIR = plugins/<slug>/`, set `$SCOPE = plugin`. Continue. - **Multiple plugin slugs touched** → stop. Print the per-slug file groups and ask the user to split the change into separate `/commit` runs...