A safety-focused tool to automate the verify-commit-push sequence without staging unrelated files.
Install
mkdir -p .claude/skills/cp && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/15411" && unzip -o skill.zip -d .claude/skills/cp && rm skill.zipInstalls to .claude/skills/cp
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Local verify-commit-push wrapper for Codex. Use only when the user explicitly says `/cp` or clearly asks to finish the current work by running the relevant local checks, staging intended files explicitly, committing on the current branch, and pushing. This workflow may commit directly to `main` or `master` when that is the repo's chosen operating model.Key capabilities
- →Inspect git status and current branch
- →Run local verification checks before committing
- →Stage only intended files explicitly
- →Generate concise conventional commit messages
- →Commit changes on the current branch
How it works
The skill inspects the git status, runs local verification, stages specific files, generates a commit message, commits to the current branch, and then pushes the changes.
Inputs & outputs
When to use cp
- →Finish a task with git push
- →Run tests before committing
- →Commit work without dirty files
- →Push current branch updates
About this skill
Cp
Use this as a thin finish mode after implementation is done.
cp is the local gate before push: verify first, then commit and push the intended changes on the current branch.
Default Flow
- Inspect:
git status- current branch
- intended files for this task
- recent commit message style if needed
- Run the closest local verification to the repo's normal safety checks before committing.
- Prefer repo-native commands over invented ones.
- Prefer the narrowest safe checks first: changed-file lint/format checks, affected package tests, or targeted builds.
- If the repo's only reliable gate is broader, run the broader command.
- If a broad local check fails because of unrelated dirty files outside the intended change set, stop and report that clearly instead of fixing or staging those unrelated files.
- Stage only the intended files explicitly.
- If a commit message was not provided, generate a concise conventional commit message that matches the repo style.
- Commit on the current branch.
- Committing directly to
mainormasteris allowed when that is the repo or user's chosen workflow. - If the repo explicitly requires short-lived branches, follow that instead.
- Push the current branch.
- If upstream is missing, push with upstream tracking.
Rules
- Never use
git add .,git add -A, or similar broad staging. - Never commit unrelated local changes from other tasks or sessions.
- Never commit secrets,
.envfiles, credentials, or generated noise by accident. - Never silently skip verification; state what ran and what was skipped.
- Never force push unless the user explicitly asks for it.
- Do not create or require a PR unless the user explicitly asks for one.
Good Targets
- "/cp"
- "커밋하고 푸시해줘"
- "메인에 올려"
- "이제 검증하고 바로 푸시해"
Avoid
- Do not use this for "just commit" or "just push" if the user clearly asked for only one of those actions.
- Do not infer permission to push a different branch than the current one.
- Do not hide skipped or excluded files; mention them briefly if they matter.
Finish
Return:
- branch pushed
- verification run or skipped
- commit message
- commit hash
- intentionally excluded files if any
When not to use it
- →When the user explicitly asks for only a commit or only a push
- →When the user wants to push to a different branch than the current one
- →When the task involves broad staging commands like 'git add .'
Limitations
- →Never use 'git add .', 'git add -A', or similar broad staging
- →Never commit unrelated local changes from other tasks or sessions
- →Never silently skip verification
How it compares
This skill automates a verify-commit-push workflow with explicit file staging and safety checks, contrasting with manual git commands that might inadvertently include unintended changes.
Compared to similar skills
cp side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| cp (this skill) | 0 | 5mo | Review | Intermediate |
| github-workflow-automation | 11 | 2mo | Review | Advanced |
| github-actions-templates | 7 | 3mo | No flags | Intermediate |
| hooks-automation | 3 | 4mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
github-workflow-automation
ruvnet
Advanced GitHub Actions workflow automation with AI swarm coordination, intelligent CI/CD pipelines, and comprehensive repository management
github-actions-templates
wshobson
Create production-ready GitHub Actions workflows for automated testing, building, and deploying applications. Use when setting up CI/CD with GitHub Actions, automating development workflows, or creating reusable workflow templates.
hooks-automation
ruvnet
Automated coordination, formatting, and learning from Claude Code operations using intelligent hooks with MCP integration. Includes pre$post task hooks, session management, Git integration, memory coordination, and neural pattern training for enhanced development workflows.
cli-commands
windmill-labs
MUST use when using the CLI.
dev
atopile
LLM-focused workflow for working in this repo: compile Zig, run the orchestrated test runner, consume test-report.json/html artifacts, and discover/debug ConfigFlags.
toolhive-release
stacklok
Creates ToolHive release PRs by analyzing commits since the last release, categorizing changes, recommending semantic version bump type (major/minor/patch), and triggering the release workflow. Use when cutting a release, preparing a new version, checking what changed since last release, or when the user mentions "release", "version bump", or "cut a release".