Git

<essential_principles>

<git_safety> Never run destructive commands without explicit user request:

• No git push --force to main/master
• No git reset --hard
• No --no-verify flag (skip hooks)
• No git commit --amend on pushed commits

Never push directly to main/master:

• If current branch is main or master, create a new branch before committing/pushing
• Use a descriptive branch name based on the changes (e.g., fix/login-bug, feat/add-filter)
• Only push to feature/fix branches, never directly to the default branch

Always verify before acting:

• Check git status before staging
• Check git log for commit style
• Check remote tracking before push

</git_safety>

<commit_format> End all commit messages with:

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Use HEREDOC for multi-line messages:

git commit -m "$(cat <<'EOF'
Message here

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"

</commit_format>

<pr_format> PR body structure:

## Summary
<1-3 bullet points>

## Test plan
- [ ] Test item 1
- [ ] Test item 2

🤖 Generated with [Claude Code](https://claude.com/claude-code)

</pr_format>

</essential_principles>

<intake> What would you like to do?

1. Commit - Stage and commit changes 2. Push - Push commits to remote 3. PR - Open a pull request 4. Ship - Full workflow: commit + push + PR

Wait for response before proceeding. </intake>

<routing>

After reading the workflow, follow it exactly. </routing>

<workflows_index>

</workflows_index>

Workflow: Commit

<process>

Step 1: Gather Context (parallel)

Run these commands in parallel:

git status
git diff --staged
git diff
git log --oneline -5

Step 2: Analyze Changes

From the output, determine:

• What files are modified/added/deleted
• What's already staged vs unstaged
• Recent commit message style in the repo

Step 2b: Branch Guard

If current branch is main or master:

git checkout -b <descriptive-branch-name>

Never commit directly to main/master. Create a feature branch first based on the changes (e.g., fix/login-bug, feat/add-filter).

Step 3: Stage Changes

If nothing is staged, stage relevant files:

git add <files>

Skip files that likely contain secrets: .env, credentials.json, *.pem, etc.

Step 4: Draft Commit Message

Analyze the staged changes and write a message that:

• Summarizes the nature of change (feature, fix, refactor, docs, test)
• Focuses on "why" not "what"
• Matches the repo's existing commit style
• Is concise (1-2 sentences for simple changes)

Step 5: Create Commit

git commit -m "$(cat <<'EOF'
<commit message here>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"

Step 6: Verify

git status
git log -1

Confirm the commit was created successfully.

</process>

<success_criteria>

• [ ] Changes analyzed before staging
• [ ] No secrets staged
• [ ] Commit message matches repo style
• [ ] Commit includes Claude attribution
• [ ] Git status shows clean working tree (for staged files)

</success_criteria>

Workflow: Pull Request

<process>

Step 1: Gather Context (parallel)

Run these commands in parallel:

git status
git log --oneline main..HEAD 2>/dev/null || git log --oneline master..HEAD
git diff main..HEAD --stat 2>/dev/null || git diff master..HEAD --stat
gh repo view --json defaultBranchRef -q .defaultBranchRef.name

Determine:

• Current branch
• All commits since branching from main
• Files changed
• Default branch name

Step 2: Ensure Pushed

If local is ahead of remote:

git push -u origin <branch-name>

Step 3: Analyze All Changes

Review ALL commits that will be in the PR (not just the latest). Draft a summary covering:

• What changed and why
• Key implementation decisions
• Testing approach

Step 4: Create PR

gh pr create --title "<title>" --body "$(cat <<'EOF'
## Summary
- <bullet 1>
- <bullet 2>
- <bullet 3>

## Test plan
- [ ] <test item 1>
- [ ] <test item 2>

🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

Optional flags (use if user requests):

• --reviewer <username> - Request reviewers
• --label <label> - Add labels
• --draft - Create as draft PR
• --assignee @me - Self-assign

Step 5: Report

Output the PR URL so user can view it.

</process>

<success_criteria>

• [ ] All commits analyzed (not just latest)
• [ ] Branch pushed to remote
• [ ] PR title is descriptive
• [ ] Summary covers key changes
• [ ] Test plan included
• [ ] PR URL returned to user

</success_criteria>

Workflow: Push

<process>

Step 1: Check Current State

git status
git branch -vv

Determine:

• Current branch name
• Whether branch tracks a remote
• How many commits ahead/behind

If current branch is `main` or `master`: STOP. Do not push. Inform the user they need to be on a feature branch. Offer to create one.

Step 2: Verify Commits to Push

git log --oneline @{u}..HEAD 2>/dev/null || git log --oneline -5

Review what will be pushed.

Step 3: Push

If branch tracks remote:

git push

If branch is new (no upstream):

git push -u origin <branch-name>

Never use `--force` unless explicitly requested by user.

Step 4: Verify

git status

Confirm push succeeded and branch is up to date with remote.

</process>

<success_criteria>

• [ ] Verified what commits will be pushed
• [ ] Used -u flag for new branches
• [ ] No force push without explicit request
• [ ] Push completed successfully

</success_criteria>