stage_hunks.py takes git diff -U0 of one file, keeps the added lines of an add-only hunk that match a regex and every other hunk whole when one of its changed lines matches, and applies the result to the index with git apply --cached --unidiff-zero --recount, or prints it with --dry-run; exit 1 when nothing matches. Step 4 of kvb-git-commit-next names it for a file that carries two bundles, which replaces the hand-written partial patches needed five times on 2026-11-03. tests/test_stage_hunks.py covers matching, the unstaged rest and the exit codes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
40 lines
2.4 KiB
Markdown
40 lines
2.4 KiB
Markdown
---
|
|
name: kvb-git-commit-next
|
|
description: >
|
|
Search every branch for the staged fix, commit it with --no-verify, then
|
|
stage and brief the next bundle. Trigger on /kvb-git-commit-next or a
|
|
request to commit and stage next.
|
|
---
|
|
|
|
1. `git fetch --all --prune --tags`, then hunt the staged fix across every
|
|
ref with the kvb-git-merge-fix skill's `find_fix.py` (by `--grep`, by `-S`, 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.
|
|
2. A similar fix on another branch is a stop: run the kvb-think-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.
|
|
3. Nothing similar found, or the operator picked the staged version: run the
|
|
kvb-git-commit-no-verify skill on the currently staged changes (kvb-code-no-comments
|
|
audit and kvb-check-legal check first, then its four-line block of
|
|
worktree path, branch, fix confidence and break risk, then
|
|
`git commit --no-verify`, exact staging index only).
|
|
4. 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-files` already
|
|
see tracked, modified files and read the worktree; only an untracked
|
|
NEW file needs `git add` to become visible. Path-scope every `git add`
|
|
to the bundle — `git add -A` sweeps up the operator's own edits and
|
|
their local config. A file that carries two bundles is staged by line:
|
|
`${CLAUDE_SKILL_DIR}/scripts/stage_hunks.py --repo <worktree> --file
|
|
<path> --match <regex>`, first with `--dry-run`.
|
|
5. For the newly staged bundle run the kvb-think-explain skill (what the changes do
|
|
and how the pieces interact, file:line-anchored) followed by the
|
|
kvb-check-confidence skill (fix confidence, break risk, evidence, residuals).
|
|
6. Close with what remains unstaged and wait for the operator's commit
|
|
decision; never auto-commit the newly staged bundle.
|