git amend guidance can cause amends when original commit failed

[altendky]

Problem

Condition (1) in the git amend guidance says to amend when "commit SUCCEEDED but pre-commit hook auto-modified files that need including."

opencode/packages/opencode/src/tool/bash.txt

Lines 58 to 59 in 77d4f99

	- Avoid git commit --amend. ONLY use --amend when ALL conditions are met:
	(1) User explicitly requested amend, OR commit SUCCEEDED but pre-commit hook auto-modified files that need including

The word "SUCCEEDED" is ambiguous here. The guidance doesn't specify how to verify whether the commit actually landed. When pre-commit hooks modify files, the output shows modified files regardless of whether the commit succeeded or failed — "auto-modified files that need including" is observable in both cases. Without an explicit verification step, the presence of modified files alone can appear to satisfy condition (1) even when the commit failed.

Line 62 says "If commit FAILED or was REJECTED by hook, NEVER amend," but this relies on correctly determining that the commit failed — the same ambiguity.

opencode/packages/opencode/src/tool/bash.txt

Line 62 in 77d4f99

- CRITICAL: If commit FAILED or was REJECTED by hook, NEVER amend - fix the issue and create a NEW commit

Hook frameworks differ on this

Whether a commit can succeed while hooks also modify files varies across hook frameworks:

Framework	When hooks modify files	Commit succeeds?	Auto-stages changes?
pre-commit (Python)	Always returns exit 1	No — commit blocked	No
lint-staged (v10+)	Returns exit 0 by default	Yes	Yes, automatically
Lefthook	Returns exit 0 by default	Yes	Only with stage_fixed: true
Overcommit (Ruby)	Modifications silently discarded	N/A	No

For lint-staged and Lefthook users, condition (1) describes a real scenario. For pre-commit Python framework users, it doesn't — and the current wording doesn't provide a way to distinguish the two outcomes.

The wording of condition (1) should be adjusted so that verifying the commit actually landed is explicit.

Other observations

The full amend guidance block (lines 58-63) has a degree of complexity — overlapping conditions, redundant rules, and some internal contradictions — that may be worth addressing independently.

opencode/packages/opencode/src/tool/bash.txt

Lines 58 to 63 in 77d4f99

	- Avoid git commit --amend. ONLY use --amend when ALL conditions are met:
	(1) User explicitly requested amend, OR commit SUCCEEDED but pre-commit hook auto-modified files that need including
	(2) HEAD commit was created by you in this conversation (verify: git log -1 --format='%an %ae')
	(3) Commit has NOT been pushed to remote (verify: git status shows "Your branch is ahead")
	- CRITICAL: If commit FAILED or was REJECTED by hook, NEVER amend - fix the issue and create a NEW commit
	- CRITICAL: If you already pushed to remote, NEVER amend unless user explicitly requests it (requires force push)

Adjacent issues

These are not directly related to the specific problem above, but involve other aspects of the amend guidance:

• The agent refuses to amend my own Git commits #17398 — Agent refuses to amend user's own commits
• Agent refuses to commit despite explicitly required #17157 — Agent refuses to commit despite explicit instructions