| name | sloppy-commit-push |
| description | Stages all repository changes, creates a concise Conventional Commit, and pushes the current branch. Use only when you explicitly want to commit and push the entire working tree. |
| license | MIT |
sloppy-commit-push
Run this skill only after the user explicitly invokes it. The invocation authorizes one commit that contains all current non-ignored changes and a push of the current branch to its configured upstream.
Keep the operation bounded:
- Use the current repository and current branch.
- Preserve normal Git hooks and server checks.
- Use one normal commit.
- Use
git push without force options.
- Leave merge, rebase, cherry-pick, revert, bisect, detached-HEAD, and missing-upstream states for the user.
Procedure
1. Check the repository
Run these commands from the repository root:
git rev-parse --show-toplevel
git status --short --branch
git branch --show-current
git remote -v
git rev-parse --abbrev-ref --symbolic-full-name '@{u}'
Proceed only when all of these conditions hold:
- The command target is a Git worktree.
- The branch name is non-empty.
- The branch has a configured upstream.
- No merge, rebase, cherry-pick, revert, or bisect is in progress.
Check operation state with git status. Stop and report the state when any condition fails.
Review the current changes before staging them:
git status --short
git diff --stat
git diff --cached --stat
If the worktree has no changes, report a no-op and stop. Do not create an empty commit.
2. Stage the complete change set
Stage all non-ignored changes from the repository root:
git add -A
git diff --cached --name-status
git diff --cached --stat
Treat the staged name-status output as the commit scope. Git does not stage ignored files. If the staged set is empty, report a no-op and stop.
3. Write the commit message
Read the staged diff with git diff --cached. Choose the type that best describes the dominant change:
| Type | Use for |
|---|
feat | A new user-facing capability |
fix | A bug correction |
docs | Documentation only |
refactor | Behavior-preserving code restructuring |
test | Tests only |
build | Build or dependency changes |
ci | Continuous-integration changes |
chore | Maintenance without a better specific type |
Use this Conventional Commits format:
<type>[optional scope]: <short imperative summary>
<optional overview of the important changes>
Keep the subject specific, lower-case after the colon, and shorter than 72 characters when possible. Add ! after the type or scope when the staged changes introduce a breaking change. Add a BREAKING CHANGE: ... footer when the breaking behavior needs detail.
Prefer one subject that summarizes the whole staged set. Use a short body when the subject alone does not explain the important changes.
Examples:
feat(auth): add passkey sign-in
Store passkey credentials and expose the sign-in flow in the account screen.
chore: refresh repository skills
Add the new skill and update the catalog entry.
4. Commit and push
Create the commit with the subject and body:
git commit -m "<subject>" -m "<overview>"
Capture the new commit SHA:
git rev-parse --short HEAD
Push the current branch to its configured upstream:
git push
Verify the result:
git status --short --branch
git log -1 --oneline
Failure handling
- A failed preflight leaves the worktree unchanged.
- A failed hook leaves the changes staged. Report the hook output and stop.
- A failed push leaves the new commit local. Report its SHA and stop.
- Never amend, reset, force-push, retry a failed push blindly, or change remotes.
Completion report
Report the commit SHA, complete commit subject, branch, upstream, push result, and final status. State the exact failure and next action when the operation stops early.
