Commit Pr

---
name: commit-pr
description: Activate when user asks to commit, push changes, create a PR, open a pull request, or submit changes for review. Activate when process skill reaches commit or PR phase. Provides commit message formatting and PR structure. PRs default to dev branch, not main. Works with git-privacy skill.
---

# Git Commit and Pull Request Skill

This skill handles git commits and pull requests with specific formatting requirements.

## PR TARGET BRANCH (CRITICAL)

**PRs go to `dev` by default, NOT `main`.**

```
feature/* → PR to dev   (default, normal workflow)
dev       → PR to main  (release only, requires explicit request)
```

### When to PR to main
- **ONLY** for releases (merging stable dev to main)
- **ONLY** when user explicitly says "release", "PR to main", or "merge to main"
- **NEVER** for regular feature work

### Default Behavior
```bash
# CORRECT - PR to dev (default)
gh pr create --base dev

# WRONG - PR to main (unless releasing)
gh pr create --base main  # DO NOT DO THIS!
```

## PREREQUISITES (MANDATORY)

**Before ANY commit or PR, you MUST:**

1. **Run tests** - All tests must pass
2. **Run reviewer skill** - Must complete with no blocking findings
3. **Fix all findings** - Auto-fix or get human decision

```
BLOCKED until prerequisites pass:
- git commit
- git push
- gh pr create
```

**If you skip these steps, you are violating the process.**

## CRITICAL RULES

**NEVER include any of the following in commits or PRs:**
- `Co-Authored-By:` lines for AI models or tools
- Any "Generated with" or "Generated by" footers
- Any indication of AI authorship or generation
- Tool URLs in attribution context

**You CAN include:**
- AI-related feature descriptions (e.g., "feat: Add GPT-4 integration")
- Bug fixes for AI components (e.g., "fix: AI inference timeout")
- Any legitimate technical content

## Commit Message Format

Use this format for commit messages:

```
<type>: <short description>

<optional body with more details>
```

### Commit Types
| Type | Usage |
|------|-------|
| `feat` | New feature |
| `fix` | Bug fix |
| `docs` | Documentation changes |
| `refactor` | Code refactoring |
| `test` | Adding or updating tests |
| `chore` | Maintenance tasks |
| `style` | Formatting, missing semicolons, etc. |
| `perf` | Performance improvements |

### Example Commit Messages

```bash
# Simple commit
git commit -m "feat: Add user authentication endpoint"

# Commit with body (use HEREDOC)
git commit -m "$(cat <<'EOF'
fix: Resolve race condition in payment processing

The payment processor was not awaiting transaction confirmation
before updating order status. Added proper async handling.
EOF
)"
```

## Pull Request Format

When creating PRs with `gh pr create`:

```bash
# ALWAYS specify --base dev (unless releasing to main)
gh pr create --base dev --title "<type>: <title under 70 chars>" --body "$(cat <<'EOF'
## Summary
- Brief overview (1-3 bullets)

## Changes
- What was modified

## Test Plan
- [ ] Test case 1
- [ ] Test case 2

## Breaking Changes
- (if applicable)
EOF
)"
```

### Release PR (dev → main)
Only when explicitly releasing:
```bash
gh pr create --base main --title "release: v10.2.0" --body "$(cat <<'EOF'
## Release Summary
- Version: v10.2.0
- Changes since last release

## Verification
- [ ] Dev branch stable
- [ ] All tests passing
- [ ] Release notes updated
EOF
)"
```

### PR Title Guidelines
- Keep under 70 characters
- Use same type prefixes as commits
- Be descriptive but concise

### PR Body Sections
- **Summary**: Brief overview (1-3 bullet points)
- **Changes**: What was modified
- **Test Plan**: How to verify the changes
- **Breaking Changes**: (if applicable)

## Workflow

### For Commits:
1. Run `git status` to see changes
2. Run `git diff` to review what changed
3. Stage specific files (avoid `git add -A` for sensitive files)
4. Create commit with proper message format
5. Verify no AI attribution in message

### For Pull Requests:
1. Ensure all changes are committed
2. Push branch to remote if needed
3. Run `git log origin/dev..HEAD` to see all commits for the PR
4. Create PR with `gh pr create --base dev` (NOT main!)
5. Verify no AI attribution in title/body

### For Release PRs (dev → main):
1. Ensure dev is stable and tested
2. User must explicitly request release
3. Create PR with `gh pr create --base main`
4. Tag after merge: `git tag v10.2.0`

## Merging PRs (Gated, Required)

This skill may be used to merge PRs, but ONLY after the merge gates below are satisfied.

### Merge Gates (Required)

1. **Post-PR review receipt exists and matches current head SHA**
   - Reviewer skill Stage 3 MUST have posted an `ICC-REVIEW` / `ICC-REVIEW-RECEIPT` comment.
   - The comment MUST include:
     - `Reviewer-Stage: 3 (temp checkout)` (dedicated reviewer/subagent context)
     - `Reviewer-Agent: ... (subagent)` (must indicate subagent execution)
     - `Head-SHA: <sha>` matching the PR's current `headRefOid`
     - `Findings: 0` and `NO FINDINGS`
     - `Result: PASS`
2. **All checks are green**
   - `gh pr checks <PR-number>` must show all required checks passing.
3. **Approval to merge (one of the following)**
   - Default: explicit user approval in chat ("merge PR <N>", "LGTM", "approve", etc.).
   - Optional: `workflow.auto_merge=true` for the current AgentTask/workflow context.
     - This is a standing approval that allows the agent to merge once gates 1-2 pass.
     - Recommended: allow auto-merge ONLY for PRs targeting `dev` (never `main`).
   - If neither applies, STOP and wait.

### Optional Gate: Enforce GitHub-Style Approvals

By default this repo uses **self-review-and-merge**:
- PR is required (branch protection), but GitHub required approvals may remain at 0.
- Review is required via the **ICC Stage 3 receipt** (skills-level gate).

If you want to also enforce GitHub-style approvals (at least 1 `APPROVED` review), set:
- `workflow.require_github_approval=true`

Notes:
- GitHub forbids approving your own PR (server-side rule). For self-authored PRs, you need a second GitHub identity/bot
  if you want a GitHub `APPROVED` review.

### Enabling Auto-Merge (Recommended)

Auto-merge is controlled by the workflow configuration that drives AgentTasks:
- AgentTask field: `workflow.auto_merge`
- Workflow files (hierarchy): `./icc.workflow.json` or `~/.claude/icc.workflow.json` over `icc.workflow.default.json`

Minimal project workflow example (`icc.workflow.json`):
```json
{
  "medium": { "auto_merge": true },
  "large": { "auto_merge": true },
  "mega": { "auto_merge": true }
}
```

### Verify The Receipt (Copy/Paste)

```bash
PR=<PR-number>
HEAD_SHA=$(gh pr view "$PR" --json headRefOid --jq .headRefOid)

# Grab the most recent receipt body (if any)
RECEIPT=$(gh pr view "$PR" --json comments --jq '.comments | map(select(.body | contains("ICC-REVIEW-RECEIPT"))) | last | .body // ""')

echo "$RECEIPT" | rg -q "Reviewer-Stage: 3 \\(temp checkout\\)" || echo "Missing Stage 3 receipt"
echo "$RECEIPT" | rg -q "Reviewer-Agent:.*\\(subagent\\)" || echo "Missing Reviewer-Agent subagent marker"
echo "$RECEIPT" | rg -q "Head-SHA: $HEAD_SHA" || echo "Receipt is missing/stale for current head SHA"
echo "$RECEIPT" | rg -q "Findings: 0" || echo "Receipt does not indicate zero findings"
echo "$RECEIPT" | rg -q "NO FINDINGS" || echo "Receipt does not include NO FINDINGS marker"
echo "$RECEIPT" | rg -q "Result: PASS" || echo "Receipt does not indicate PASS"
```

**If any verification line fails:** DO NOT MERGE. Re-run reviewer Stage 3 and post a fresh receipt.

### Verify GitHub Approval (Copy/Paste)

```bash
PR=<PR-number>
REQUIRE_GH_APPROVAL=${REQUIRE_GH_APPROVAL:-false} # set to true if workflow.require_github_approval=true

PR_AUTHOR=$(gh pr view "$PR" --json author --jq .author.login)
GH_USER=$(gh api user --jq .login)
APPROVALS=$(gh pr view "$PR" --json reviews --jq '[.reviews[] | select(.state=="APPROVED")] | length')

if [ "$REQUIRE_GH_APPROVAL" = "true" ]; then
  if [ "$PR_AUTHOR" = "$GH_USER" ]; then
    echo "Self-authored PR ($GH_USER): GitHub forbids self-approval; approvals require a bot/second identity."
  else
    test "$APPROVALS" -ge 1 || echo "Missing GitHub APPROVED review"
  fi
fi
```

### Merge (Only After Approval)

```bash
gh pr merge <PR-number> --squash --delete-branch
```

## Examples

### Creating a Commit
```bash
# Stage files
git add src/auth/login.ts src/auth/types.ts

# Commit without any AI attribution
git commit -m "feat: Add login validation with rate limiting"
```

### Creating a PR
```bash
gh pr create --title "feat: Add user authentication" --body "$(cat <<'EOF'
## Summary
- Implements JWT-based authentication
- Adds login/logout endpoints
- Includes rate limiting for security

## Changes
- Added `src/auth/` module with authentication logic
- Updated API routes to include auth endpoints
- Added middleware for protected routes

## Test Plan
- [ ] Test login with valid credentials
- [ ] Test login with invalid credentials
- [ ] Verify rate limiting after 5 failed attempts
EOF
)"
```

## Reminders

1. **No AI attribution** - Never add Co-Authored-By or Generated-with lines
2. **Be specific** - Describe what changed and why
3. **Keep it clean** - No unnecessary files (check .gitignore)
4. **Review first** - Always `git diff` before committing