| name | tuturuuu-commit |
| description | Tuturuuu scoped commit workflow guidance. Use when the user asks Codex to commit, commit and push, split commits by scope or domain, claim or wait for a commit window, stage work safely in a shared worktree, or report final commit hashes after validation. |
Tuturuuu Commit
Core Workflow
Use this skill when the user explicitly asks for commits, scoped commits,
atomic commits, commit-and-push follow-through, or commit reporting.
Read references/commit-workflow.md for examples of scope grouping, staging,
and failure handling before creating commits.
Guardrails
- Run
git status --short before staging.
- Treat unknown dirty and untracked files as user-owned or other-agent-owned.
- Claim the commit window with
bun git-commit-window claim immediately before
changing the staged set or committing in a shared checkout. Use
bun git-commit-window wait when another agent owns the window and waiting is
appropriate.
- Keep the commit window tight: claims default to 10 minutes, only accept
5-10-minute TTLs, and should be released as soon as commit work finishes or
aborts.
- Stage only files intentionally changed for the current commit.
- Avoid
git add . in shared worktrees.
- Treat existing staged files as owned by the staging agent or coordinator until
explicitly reassigned. If a path is
MM, review both staged and unstaged
portions with the relevant owner before committing.
- Keep commits atomic by product domain, package, behavior, or independently
revertible operational policy.
- Use Conventional Commit subjects that match repo rules.
- Never include secrets, local-only scratch files, or unrelated formatting churn.
- Do not push unless the user explicitly asks for push.
- Let commit hooks run by default. Use
git commit --no-verify only when the
current agent has proof-gated no-verify evidence for its exact staged paths.
Do not use no-verify to bypass failures caused by unrelated worker files unless
you own the staged set and have exact-path proof.
Commit Planning
Before staging, group changed paths by the reason they should be reverted
together. Prefer a small number of meaningful commits over file-by-file commits.
Good split boundaries:
- product behavior fixes
- user-facing feature work
- package or tooling policy changes
- docs-only follow-through for a workflow change
- plugin, skill, or agent-workflow updates
Do not split one behavior across multiple commits just because it touches tests,
translations, docs, or helper modules. Those supporting files belong with the
behavior they validate or expose.
Staging And Validation
For each commit:
- Claim or wait for the commit window and keep the token out of notes.
- Stage the exact paths for that scope.
- Inspect
git diff --cached --stat and git diff --cached --name-only.
- Commit with a Conventional Commit subject.
- Release the commit window after the commit succeeds or aborts.
- Let commit hooks run unless proof-gated no-verify evidence is complete.
git commit --no-verify is allowed only when the current agent can prove the
exact staged files would pass the checks normally covered by bun check: it
must own every staged path, record the separated checks it ran, explain why
those checks cover every touched file, and list unrelated dirty files excluded
from the claim. If ownership is unclear, proof is incomplete, or affected checks
cannot be mapped confidently, do not use --no-verify.
If a hook fails because of unrelated dirty files or pre-existing repo failures,
do not widen the commit to fix them. Unstage if needed, report the blocker, and
keep the staged scope clean. A complete proof-gated no-verify packet may justify
using --no-verify; otherwise leave the hook failure unresolved for the user.
Final Report
After committing, report:
- commit hashes and subjects
- validation that ran, including hook results
- whether the worktree is clean or what remains dirty
- push status when the user requested a push
