commit-push skill

Commit and Push

Commit all local changes following Conventional Commits format and push to remote.

Gates

Complete in order. Do not run the next action until the Pass condition is satisfied (use command output as evidence, not memory).

1. Diff understood — Pass when: Outputs from git status, git diff, and git diff --cached are consistent with your one-sentence description of what changed (or you recorded that there is nothing to commit).
2. Commit line chosen — Pass when: You have a draft first line type(scope): description (or type: description if omitting scope) that matches the change set you intend to ship.
3. Staging matches intent — Pass when: After git add, git diff --cached --stat (and spot-check git diff --cached if needed) shows only the paths you meant to include; adjust staging before committing if not.
4. Push target confirmed — Pass when: Current branch and remote are the ones you intend (git branch -vv, git remote -v); then push.
5. Remote caught up — Pass when: git status is clean and git status -sb shows the branch is up to date with its configured upstream (no unexpected unpushed commits left for this task).

Step 1: Gather Context

Run these commands in parallel to understand the changes:

# See all untracked and modified files
git status

# See staged and unstaged changes
git diff
git diff --cached

# See recent commit messages for style reference
git log --oneline -10

Step 2: Analyze Changes

Review the changes and determine:

• Type: What kind of change is this?

  • feat - New feature or capability
  • fix - Bug fix
  • docs - Documentation only
  • refactor - Code restructure without behavior change
  • test - Adding or updating tests
  • chore - Maintenance, dependency updates
  • perf - Performance improvement
  • ci - CI/CD changes

• Scope: Which component is affected?

  • Examine the changed files and determine the appropriate scope
  • Use consistent scope names within the project (check git log for patterns)
  • (omit scope for cross-cutting changes)

• Breaking: Does this break backward compatibility? If yes, add ! after scope.

Step 3: Write Commit Message

Format:

type(scope): description

[optional body explaining why, not what]

[optional footer with issue references]

Rules:

• Use imperative mood: "add feature" not "added feature"
• Keep first line under 72 characters
• Focus on why in the body, the diff shows what
• Reference issues: Closes #123 or Fixes #456

Step 4: Stage, Commit, and Push

Satisfy Gates 1–3 before git commit; satisfy Gate 4 before git push; satisfy Gate 5 after push.

# Stage all changes (or selectively stage)
git add -A

# Gate 3: confirm staged set before committing
git diff --cached --stat

# Commit with message (use HEREDOC for multi-line)
git commit -m "$(cat <<'EOF'
type(scope): description

Optional body explaining the motivation.

Closes #123
EOF
)"

# Push to remote
git push

Examples

# Simple feature
git commit -m "feat(api): add pagination support to list endpoints"

# Bug fix with body
git commit -m "$(cat <<'EOF'
fix(auth): handle token expiration during long requests

The previous implementation did not account for tokens expiring
during the processing of long-running requests.

Fixes #42
EOF
)"

# Breaking change
git commit -m "$(cat <<'EOF'
feat!(api): change response format for user endpoints

BREAKING CHANGE: The `status` field is now an object with `state` and
`message` properties instead of a plain string.
EOF
)"

Optionally append a co-author or footer trailer per project convention (e.g. a Co-Authored-By: line or a tool-attribution footer). Omit it when the project has no such convention.

Step 5: Verify

After pushing, satisfy Gate 5: run git status and git status -sb and confirm a clean tree and upstream sync (or an expected ahead/behind you can explain, e.g. fork workflow).