Checkpoint commit
Skill colinwilliams91/gaitor-orchestrator-cli/.agents/skills/checkpoint-commit
CLI for AIDDLC -- Scaffolded, parallelized, context aware agent runtime in seconds.
npx -y skills add colinwilliams91/gaitor-orchestrator-cli --skill checkpoint-commitAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Create a deliberate git checkpoint commit from staged or current working changes using a diff-based, model-written Conventional Commit message. Use when you want a clean commit boundary during intensive agentic iteration.
SKILL.md
2.2 KB, as published. Nobody here has run it
Checkpoint Commit
Use this skill when you want a real commit, not an autosave fallback.
Required Workflow
- Confirm the current directory is inside a git repository.
- Inspect
git status --short. - If staged changes already exist, use them as the commit boundary.
- If nothing is staged but the working tree is dirty, stage the current work with
git add -Abecause the user explicitly invoked a commit checkpoint. - If there are still no changes, stop and report that there is nothing to commit.
- Gather commit context from the staged diff:
git diff --cached --name-statusgit diff --cached --statgit diff --cached --unified=2git log --oneline -5
- Write the commit message from the actual diff.
- Create the commit immediately unless the user explicitly asked for a preview only.
Commit Message Rules
- Follow Conventional Commits.
- Choose
feat,fix,docs,refactor,test,chore,perf, orcibased on the behavioral change shown in the diff, not only file names. - Add a scope only when it is obvious and materially helpful.
- Keep the subject line concise, imperative, and specific.
- Use the user's
$ARGUMENTSas optional intent if it improves the message. - Add a body only when the diff spans multiple tightly related changes and the extra context is genuinely useful.
- Do not use timestamps.
- Do not use placeholder phrases like
update filesormisc changes. - Do not expose hidden reasoning or chain-of-thought.
Guardrails
- Prefer one logical commit. If the staged diff spans unrelated concerns, stop and tell the user to split the change set.
- Do not push.
- Do not amend unless the user explicitly asks.
- If
git commitfails, report the failure and the proposed commit message clearly.
Output
After committing, report:
- The final commit subject.
- Whether a commit body was used.
- The files included in the staged set.