From f9c86dfc2ab458a5f4c951cc980d36fc1c0f31d1 Mon Sep 17 00:00:00 2001 From: unional Date: Sun, 6 Sep 2026 14:33:29 -0700 Subject: [PATCH] fix(commit-work): replace interactive commands an agent cannot run The staging step recommends `git add -p`, and the message step prefers `git commit -v`. Both are interactive: they take over the terminal and wait for input, so an agent running this skill cannot complete them. `git restore --staged -p` has the same problem. Stage explicit paths instead, unstage by path, and supply multi-line messages via `git commit -F -` or repeated `-m` flags. Hunk-level splitting is called out as the step to hand back to a human. Also note that a repository's own commit rules take precedence, since repos that ban `git add .` and `git add -p` in AGENTS.md currently contradict this skill. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01G8tfUyynnULymhHvohRHZx Signed-off-by: unional --- dist/plugins/commit-work/skills/commit-work/SKILL.md | 11 +++++++---- skills/commit-work/SKILL.md | 11 +++++++---- 2 files changed, 14 insertions(+), 8 deletions(-) diff --git a/dist/plugins/commit-work/skills/commit-work/SKILL.md b/dist/plugins/commit-work/skills/commit-work/SKILL.md index 33d816e..25a24e6 100644 --- a/dist/plugins/commit-work/skills/commit-work/SKILL.md +++ b/dist/plugins/commit-work/skills/commit-work/SKILL.md @@ -11,6 +11,8 @@ Make commits that are easy to review and safe to ship: - commits are logically scoped (split when needed) - commit messages describe what changed and why +If the repository states its own commit rules (AGENTS.md or CLAUDE.md, often under "Commit Discipline"), those take precedence over this skill. + ## Inputs to ask for (if missing) - Single commit or multiple commits? (If unsure: default to multiple small commits when there are unrelated changes.) - Commit style: Conventional Commits are required. @@ -23,10 +25,11 @@ Make commits that are easy to review and safe to ship: - If many changes: `git diff --stat` 2) Decide commit boundaries (split if needed) - Split by: feature vs refactor, backend vs frontend, formatting vs logic, tests vs prod code, dependency bumps vs behavior changes. - - If changes are mixed in one file, plan to use patch staging. + - If unrelated changes are mixed in one file, commit one concern first and the next afterwards; a file cannot be split non-interactively. 3) Stage only what belongs in the next commit - - Prefer patch staging for mixed changes: `git add -p` - - To unstage a hunk/file: `git restore --staged -p` or `git restore --staged ` + - Stage explicit paths: `git add ...`. Avoid `git add .` and `git add -A`, which sweep in unrelated work. + - To unstage: `git restore --staged ` + - `git add -p` and `git restore --staged -p` are interactive; an agent cannot drive them. If a file genuinely needs hunk-level splitting, hand that step to the human. 4) Review what will actually be committed - `git diff --cached` - Sanity checks: @@ -42,7 +45,7 @@ Make commits that are easy to review and safe to ship: - blank line - body (what/why, not implementation diary) - footer (BREAKING CHANGE) if needed - - Prefer an editor for multi-line messages: `git commit -v` + - For multi-line messages, supply the body directly — `git commit -F -` with a heredoc, or repeated `-m` flags. `git commit -v` opens an editor an agent cannot use. - Use `references/commit-message-template.md` if helpful. 7) Run the smallest relevant verification - Run the repo's fastest meaningful check (unit tests, lint, or build) before moving on. diff --git a/skills/commit-work/SKILL.md b/skills/commit-work/SKILL.md index 33d816e..25a24e6 100644 --- a/skills/commit-work/SKILL.md +++ b/skills/commit-work/SKILL.md @@ -11,6 +11,8 @@ Make commits that are easy to review and safe to ship: - commits are logically scoped (split when needed) - commit messages describe what changed and why +If the repository states its own commit rules (AGENTS.md or CLAUDE.md, often under "Commit Discipline"), those take precedence over this skill. + ## Inputs to ask for (if missing) - Single commit or multiple commits? (If unsure: default to multiple small commits when there are unrelated changes.) - Commit style: Conventional Commits are required. @@ -23,10 +25,11 @@ Make commits that are easy to review and safe to ship: - If many changes: `git diff --stat` 2) Decide commit boundaries (split if needed) - Split by: feature vs refactor, backend vs frontend, formatting vs logic, tests vs prod code, dependency bumps vs behavior changes. - - If changes are mixed in one file, plan to use patch staging. + - If unrelated changes are mixed in one file, commit one concern first and the next afterwards; a file cannot be split non-interactively. 3) Stage only what belongs in the next commit - - Prefer patch staging for mixed changes: `git add -p` - - To unstage a hunk/file: `git restore --staged -p` or `git restore --staged ` + - Stage explicit paths: `git add ...`. Avoid `git add .` and `git add -A`, which sweep in unrelated work. + - To unstage: `git restore --staged ` + - `git add -p` and `git restore --staged -p` are interactive; an agent cannot drive them. If a file genuinely needs hunk-level splitting, hand that step to the human. 4) Review what will actually be committed - `git diff --cached` - Sanity checks: @@ -42,7 +45,7 @@ Make commits that are easy to review and safe to ship: - blank line - body (what/why, not implementation diary) - footer (BREAKING CHANGE) if needed - - Prefer an editor for multi-line messages: `git commit -v` + - For multi-line messages, supply the body directly — `git commit -F -` with a heredoc, or repeated `-m` flags. `git commit -v` opens an editor an agent cannot use. - Use `references/commit-message-template.md` if helpful. 7) Run the smallest relevant verification - Run the repo's fastest meaningful check (unit tests, lint, or build) before moving on.