Short prompt interpretation regression: Claude acts on unstated assumptions for git/PR commands

Description

When a user issues short git-related prompts (e.g., "push and create PR", "commit", "merge"), Claude often reacts reflexively without first verifying the current repository state. This leads to acting on unstated assumptions:

• Switching branches without being asked
• Proposing commits for uncommitted changes that belong to a different task
• Failing to recall that a PR for the current branch already exists, even when the fact is present in the conversation history
• Following the spirit of "complete the user's intent" instead of the literal scope

Existing project-level memory (e.g., "no empty promises" rule) does not reliably prevent this because Claude's adherence to memory-recorded rules degrades under short prompts. The model produces verbal acknowledgements ("I'll be careful", "I accept this") that are empirically empty.

Suggested directions for built-in mitigations (not project hooks)

1. Auto-inject canonical repository state (current branch, unpushed commits, open PR for the branch) as context whenever the prompt contains git/PR action verbs and is below a length threshold.
2. Treat short git-action prompts as requiring explicit reference to existing artifacts (commit SHA, PR number) -- degrade gracefully by reporting state rather than acting.
3. First-class "command completion check" tool that returns whether the action implied by a prompt has already been completed in the current session.

Reproduction

1. Branch A has pushed commits and an open PR; uncommitted changes exist for task B.
2. User: "push and create PR" -- referring to confirmed work on branch A.
3. Claude switches to branch B's planned branch, stashes/pops, proposes commits.

Correct behavior: report "PR #N already exists on branch A: <url>".

Workaround (project-level)

A UserPromptSubmit hook that auto-injects git branch, git log @{u}..HEAD, gh pr list --head <branch>, and git status --short for short prompts with git action verbs works empirically. This should be a built-in capability rather than requiring per-project hook setup.