| name | cp |
| description | This skill should be used when the user asks to "commit and push", "cp", "commit push", "ship it", "push my changes", or wants to commit and push while respecting the project's CLAUDE.md (or AGENTS.md) commit requirements. Also triggered by the /cp command. |
| user-invocable | true |
Commit & Push
Commit and push changes to the current branch, running only the pre-commit checks described in the project's CLAUDE.md (or AGENTS.md). Does not invent extra steps — if the project specifies no requirements, skip straight to commit and push.
Workflow
Step 1: Read the project's CLAUDE.md
First determine the Git repository root by running git rev-parse --show-toplevel. Then look for a CLAUDE.md (or AGENTS.md) starting from the working directory and walking up through its ancestor directories, but stop once you reach that repo root and do not search beyond it. Use the nearest file found; if both CLAUDE.md and AGENTS.md exist in the same directory, prefer CLAUDE.md. Read the file and extract any commit-related requirements such as:
- Formatting commands (e.g.
prettier, black, gofmt)
- Linting commands (e.g.
eslint, ruff, clippy)
- Type-checking commands (e.g.
tsc --noEmit, mypy)
- Test commands (e.g.
npm test, pytest, cargo test)
- Build commands (e.g.
npm run build, cargo build)
- Commit message conventions (e.g. conventional commits, prefix rules)
Only extract requirements that are explicitly stated. If CLAUDE.md says nothing about pre-commit checks, do not run any.
Step 2: Determine the branch
Run git branch --show-current to get the current branch name. If the result is empty (detached HEAD) or is main/master, ask the user which branch to push to before proceeding — this is a safety guard to avoid accidental commits directly to main/master. Once the target branch is determined, switch to it:
- If the branch already exists locally:
git switch <branch-name>
- If it needs to be created:
git switch -c <branch-name>
If the current branch is neither main/master nor detached HEAD, use it as-is without switching.
Step 3: Run pre-commit checks
For each requirement found in Step 1, run the corresponding command via Bash. Execute them in a logical order: format → lint → type-check → test → build.
- If a formatter modifies files, stage the changes with
git add on those files.
- If any check fails, report the failure to the user and stop. Do not commit broken code.
If no requirements were found in CLAUDE.md (or AGENTS.md), skip this step entirely.
Step 4: Stage and commit
- Run
git status and git diff --stat to review what will be committed.
- Stage the relevant changed files (prefer explicit file names over
git add -A).
- Write a concise commit message that summarizes the why of the changes. Follow any commit message conventions found in CLAUDE.md. Use a HEREDOC to pass the message:
git commit -F - <<'EOF'
<commit message here>
EOF
- Run
git status after committing to verify success.
Step 5: Push
Check whether the branch already has an upstream configured by running git rev-parse --abbrev-ref <branch-name>@{upstream}.
- Upstream exists: simply run
git push (no flags needed — git uses the existing tracking config).
- No upstream: determine the remote via
git config --get branch.<branch-name>.remote, falling back to origin, then run:
git push -u <remote> <branch-name>
If the push fails due to a network error, retry up to 4 times with exponential backoff (2s, 4s, 8s, 16s). If it fails for other reasons (e.g. rejected), report the error and stop.
Step 6: Report
Tell the user:
- What checks were run (if any) and their results.
- The commit hash and message.
- The branch that was pushed to.
