commit-dirty

name	commit-dirty
description	Use when I explicitly want the current intended dirty git worktree committed and pushed now, including requests like `commit dirty`, `commit all dirty`, `commit and push this`, or `ship these changes`, after verifying scope and running the minimum relevant checks. Do not use for commit planning only, history rewrites, force-pushes, or ambiguous mixed diffs.

Commit Dirty

Use this skill for explicit write requests to create a real git commit and push it from the current repository, including the "commit dirty" and "commit all dirty" cases where the intended scope is the current dirty worktree. Treat speed as secondary to shipping a coherent, verified change.

Required Workflow

1. Confirm the current directory is a git repository and identify the active branch and upstream.
2. Inspect git status, changed files, and relevant diffs before staging anything.
3. Decide whether the worktree is safe to ship as requested.
   • If the changes are coherent, continue.
   • If unrelated or suspicious changes are mixed in, stop and ask how to split or exclude them instead of guessing.
4. Verify the change.
   • Run the smallest relevant automated checks.
   • Add or run a failing reproducer first for bug fixes when practical.
   • Do not commit failing or unverified work just because the user asked for a quick push.
5. Run the readme-recruiter-sync skill check against the root README.md. For a shell-only path, run ./scripts/executable_readme-recruiter-sync.
   • Treat the gate as mandatory before staging or committing.
   • If the README is stale or missing required install or bootstrap, usage, core command flag, repo-based tech stack rationale, or recruiter-facing coverage, update it in the same change before continuing.
   • If satisfying the gate would require mixing unrelated dirty README work or other user changes, stop and ask instead of guessing.
6. Stage only the intended files or hunks, including README.md when the gate required it.
7. Write the commit message.
   • Use a concise Conventional Commit subject line.
   • Add a body with around 5 to 10 concrete bullet points that describe the actual changes.
8. Create the commit.
9. Push the branch.
   • Push immediately after each successful commit by default.
   • Push to the configured upstream by default.
   • If no upstream exists or the target remote is unclear, stop and ask instead of guessing.
   • Do not amend, rebase, squash, or force-push unless the user explicitly asks.
10. Report the result with the validation performed, commit SHA, push target, and remaining worktree state.

Guardrails

• Treat commit all dirty as "ship the full intended dirty worktree now", not as permission to bundle unrelated changes.
• Do not use this skill when the task is only to plan commits or group dirty changes without writing. Use commit-plan for that case.
• Do not use this skill when the user explicitly wants to ship only the current Codex session's changes. Use commit-session for that case.
• Never bypass readme-recruiter-sync because the code diff looks small.
• Never invent README claims, flags, install steps, or recruiter copy that the repo does not support.
• Never leave a newly created commit unpushed by default unless the user explicitly told you not to push.
• Never bundle unrelated dirty changes into one commit to save time.
• Never stage secrets, credentials, caches, build output, or machine-local files unless they clearly belong in version control.
• Respect pre-existing user changes. Do not revert or discard work you did not make.
• If the diff is too mixed to ship safely without a decision, ask one short clarifying question and stop there.

Output Contract

After a successful run, report:

• the final commit subject and short SHA
• the validation commands or manual checks that were run
• the branch and push destination
• whether the worktree is now clean or what still remains dirty