howarewoo/commit

Commit Skill

Commits changes using Graphite, ensuring proper branch management and PR metadata.

Usage

Invoke with /commit or /commit <message>.

• /commit — auto-generates a conventional commit message from the diff
• /commit fix: resolve auth redirect loop — uses the provided message
• /commit --new-branch — forces creation of a new branch even if already on a feature branch
• /commit --new-branch fix: resolve auth redirect loop — combines both

Autonomous Execution

This skill runs fully autonomously without user interaction. When invoked:

• Do NOT ask for user confirmation at any step
• Do NOT pause between tasks or wait for approval
• Proceed directly through all workflow steps
• Only stop if a critical error occurs

Workflow

Step 1: Check Current Branch

Determine the current branch:

git branch --show-current

If the --new-branch flag was passed, always create a new branch regardless of the current branch. Proceed to Step 2a.

If the current branch is main or staging (a trunk branch), you are on trunk and must create a new branch before committing. Proceed to Step 2a.

If already on a feature branch (and --new-branch was not passed), skip to Step 3.

Step 2a: Create a New Branch

Create a new feature branch. First, examine the staged and unstaged changes to determine an appropriate branch name:

git diff --stat
git diff --staged --stat

Generate a descriptive kebab-case branch name based on the changes (e.g., fix/auth-redirect-loop, feat/add-user-avatar, chore/update-dependencies).

Create the branch with Graphite:

gt create <branch-name>

gt create automatically stacks the new branch on top of the current branch. This means:

• If on trunk (main/staging), the new branch's parent is trunk
• If on a feature branch (e.g., via --new-branch), the new branch stacks on top of that feature branch

Step 2b: Track Parent (only when creating from trunk)

If the new branch was created from main or staging (i.e., NOT via --new-branch from a feature branch), ensure it targets staging:

gt track --parent staging

Skip this step when --new-branch was used from a feature branch — the branch is already correctly stacked on the current branch by gt create.

Step 3: Stage Changes

Check for unstaged changes:

git status

If there are unstaged changes, stage all of them:

gt add .

If the user specified specific files, stage only those files instead.

Step 4: Review the Diff

Get the full diff of staged changes:

git diff --staged

Analyze the diff to understand:

• What type of change this is (feat/fix/refactor/docs/chore/test/style)
• What scope/area is affected
• What the changes accomplish

Step 5: Run Pre-Commit Checks

Run formatting and tests on changed files:

pnpm pre-commit

If pre-commit fails:

1. Review the failures
2. Fix any formatting issues automatically
3. Re-stage the fixed files with gt add .
4. Re-run pnpm pre-commit
5. If tests fail, report the failures and stop — do not commit broken code

Step 6: Create the Commit

Generate a conventional commit message if one was not provided. The message format:

type(scope): concise description

Optional body with more detail if the change is complex.

Co-Authored-By: Claude Opus 4.6 <[email protected]>

Type: feat, fix, refactor, docs, chore, test, style, perf Scope: The affected package or area (e.g., landing, web, mobile, orpc, ui)

Create the commit:

gt modify -c -m "$(cat <<'EOF'
type(scope): concise description

Co-Authored-By: Claude Opus 4.6 <[email protected]>
EOF
)"

Use a HEREDOC to preserve multi-line formatting.

Step 7: Submit PR

Create or update the PR with Graphite:

gt submit

This will create a new PR if one doesn't exist, or update the existing one.

Step 8: Update PR Title and Summary

After submitting, get the full commit history for this branch:

gh pr view --json number,title,body,headRefName,commits

And get the full diff against the base branch:

gh pr diff

Analyze ALL commits and the full diff to generate:

1. PR Title — conventional commit format covering the overall change:

   • feat(scope): description for new features
   • fix(scope): description for bug fixes
   • refactor(scope): description for refactoring
   • docs(scope): description for documentation
   • chore(scope): description for maintenance
   • If the PR has mixed types, use the most significant one

2. PR Summary — structured markdown body:

## Summary
<1-3 bullet points describing what this PR does>

## Changes
<Bulleted list of specific changes made>

## Test Plan
<How to verify the changes work>

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

Update the PR:

gh pr edit --title "type(scope): description" --body "$(cat <<'EOF'
## Summary
...

## Changes
...

## Test Plan
...

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

Step 9: Report Result

Output a summary to the user:

✓ Committed: type(scope): description
✓ PR #<number> updated: <title>
  <PR URL>

Edge Cases

• No changes to commit: If git status shows no changes, report "Nothing to commit" and stop
• Branch already exists: If gt create fails because the branch exists, use gt branch checkout <name> instead
• PR submit fails: If gt submit fails, report the error — the commit was still made successfully
• Pre-commit hook failure: Fix formatting issues and retry. If tests fail, stop and report

Important Rules

• Always use gt commands for branch/commit operations (never raw git commit)
• Always run pnpm pre-commit before committing
• Always include Co-Authored-By trailer in commit messages
• Always update PR title and summary after each commit using the full diff
• Branch names use kebab-case with type prefix (e.g., feat/thing, fix/bug)
• New branches target staging via gt track --parent staging