---
name: git-workflow
description: Procedures for git commits, worktrees, branches, and GitHub PRs — load before any git operation
---

## Git Commit Procedure

1. Run `git status` to see all untracked and modified files.
2. Run `git diff` (staged + unstaged) to review changes that will be committed.
3. Run `git log --oneline -5` to see recent commit message style.
4. Draft a Conventional Commit message (`feat:`, `fix:`, `chore:`, `refactor:`, `docs:`, `test:`):
   - Focus on **why**, not **what**.
   - 1-2 sentences max.
   - Match the repository's existing style.
5. Check for secrets: do NOT commit `.env`, credentials, key files, or `.megamemory/` contents.
6. If `.megamemory/` is not in `.gitignore`, add it before the first commit.
7. Stage relevant files: `git add <files>` (not blindly `git add .`).
8. Commit: `git commit -m "<message>"`.
9. Run `git status` after commit to verify success.

## Git Worktree Procedure

### When to use worktrees:
- Always use a worktree for new feature work to keep `main` clean.
- **One worktree per independent workstream.** If implementing multiple unrelated features, create separate worktrees for each.

### Deciding on worktree count:
- **1 worktree**: Single feature, or 2 tightly-coupled features sharing state/files.
- **2+ worktrees**: Features that touch different domains, have different risk profiles, or could ship independently. Each gets its own worktree, branch, and PR.

### Creating a worktree for a new feature:
```bash
# From project root
git worktree add .worktrees/<feature-name> -b <branch-name>
```

### Creating multiple worktrees for independent workstreams:
```bash
# From project root — create all worktrees upfront
git worktree add .worktrees/<workstream-1> -b feat/<workstream-1>
git worktree add .worktrees/<workstream-2> -b feat/<workstream-2>
```

### Working in a worktree:
- All file edits, test runs, and dev server starts must use the worktree path.
- Example: `workdir="/path/to/project/.worktrees/my-feature"` for all bash commands.
- **Each coder invocation must target a specific worktree** — never mix worktrees in one coder dispatch.

### Completing a worktree:
```bash
# From main working tree
git checkout main
git merge <branch-name>
git worktree remove .worktrees/<feature-name>
git branch -d <branch-name>  # optional cleanup
```

### Completing multiple worktrees (independent PRs):
Complete and merge each worktree independently. If workstream-2 depends on workstream-1, merge workstream-1 first, then rebase workstream-2 before merging.

## GitHub PR Procedure

### Push and create PR:
```bash
# Push branch
git push -u origin <branch-name>

# Create PR with heredoc body
gh pr create --title "<title>" --body "$(cat <<'EOF'
## Summary
- <bullet 1>
- <bullet 2>

## Changes
- <file/area>: <what changed>

## Testing
- <how it was validated>
EOF
)"
```

### Check CI status:
```bash
gh run list                    # List recent workflow runs
gh run view <run-id>           # View specific run details
gh pr checks <pr-number>       # Check statuses on a PR
```

### Issue operations:
```bash
gh issue list                  # List open issues
gh issue view <number>         # View specific issue
gh issue comment <number> -b "<comment>"  # Add comment
```

## Safety Rules

- **Never `git push --force` to `main`/`master`** unless the user explicitly confirms.
- **Never skip hooks** (`--no-verify`) unless the user explicitly requests it.
- **Never `git commit --amend`** unless: (1) explicitly requested OR pre-commit hook auto-modified files, (2) HEAD was created in this session, AND (3) commit has NOT been pushed to remote.
- If commit fails due to pre-commit hook, fix the issue and create a NEW commit.