Kevin Veen-BirkenbachandClaude Opus 5
846742b99a
Two incidents in one session: a permanent CLI subcommand invented for a migration that runs exactly once, deleted again on demand; and `git add -A` twice sweeping local operator config into a bundle it had nothing to do with. scope-guard states the test — which sentence of the request asks for this? No sentence, no artifact — and three rules under it: no permanent scaffolding for a one-off need, path-scope every `git add`, and report an adjacent defect in one line instead of quietly fixing it into someone elses commit. commit-next draws the same line where staging actually happens. Step 4 is now the only place that stages: never to run a lint or a test, and always path-scoped, because `git add -A` collects work that was never part of the bundle. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.2 KiB
2.2 KiB
name, description
| name | description |
|---|---|
| commit-next | Fetch every branch and check whether the staged fix already exists elsewhere, then commit the staged bundle with --no-verify, stage the next logical bundle and brief the operator on it. Trigger on /commit-next or when the operator asks to commit and stage the next bundle in one step. Portable across projects. |
git fetch --all --prune --tags, then hunt the staged fix across every ref with the merge-fix search steps (git log --allby--grep, by-S<symbol>, by path). Describe the staged bundle in one line first so a wrong search intent is visible. Only the search runs here — never cherry-pick or merge, and never touch the staging index or the tree.- A similar fix on another branch is a stop: run the dialectic skill on the two candidates (staged version as thesis, foreign commit as antithesis) until one survives, then present sha, branch, both diffs, the verdict and the recommended move (keep staged / take theirs / combine). Wait for the operator's decision; do not commit.
- Nothing similar found, or the operator picked the staged version: run the
commit-no-verify skill on the currently staged changes (comments-clean
audit first, then
git commit --no-verify, exact staging index only). - Group the remaining uncommitted changes into logical bundles (one
concern per bundle: same failure class, same mechanism, or same role)
and stage the next one; never mix concerns to save a commit. Staging
happens here and nowhere else: never stage merely to run a lint or a
test. Repository checks that enumerate through
git ls-filesalready see tracked, modified files and read the worktree; only an untracked NEW file needsgit addto become visible. Path-scope everygit addto the bundle —git add -Asweeps up the operator's own edits and their local config. - For the newly staged bundle run the explain skill (what the changes do and how the pieces interact, file:line-anchored) followed by the confidence skill (fix confidence, break risk, evidence, residuals).
- Close with what remains unstaged and wait for the operator's commit decision; never auto-commit the newly staged bundle.