Otaq''s default Commit workflow skill - commit every change in this worktree (messages as the Agent instructions say, else "<KEY>: <what changed>"), before `otaq stage next`.
Installs into .claude/skills of the current project.
Sponsors
SSkills DirectorySkills Directory
Know which skills are safe — weekly.
SSkills DirectorySkills Directory
Is that skill safe to install?
Are you the author of Commit?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/otaq-io-commit)
---
name: commit
description: 'Otaq''s default Commit workflow skill - commit every change in this worktree (messages as the Agent instructions say, else "<KEY>: <what changed>"), before `otaq stage next`.'
---
# Commit everything
Commit all of your work in this worktree so nothing is left uncommitted. `otaq stage next` is refused while
any file is uncommitted, and the user reviews and merges only what is committed. Otaq never commits for you.
1. Run `git status` and look at every changed, deleted and untracked file.
2. Delete scratch files you made (logs, notes, temporary scripts) instead of committing them. Command output you
want to keep belongs in `$OTAQ_RESOURCE_DIR`, never in the worktree, so you can name it in your comment: move it
there instead, search it with `grep` or `tail`, and never print it in full or retype it.
Never commit secrets or env files (`.env`, keys, tokens). If one shows up as untracked, don't commit it and don't
delete it: ask the user with `otaq ask human --stdin` (it may belong in `.gitignore`).
3. **Follow the Agent instructions** that `otaq prime` prints, and the project's own rules on commits (a
contributing guide, a commit message format). If you haven't read `otaq prime` in this session, run it now and read
its Agent instructions. They decide how the commits are written: the message format (for example Conventional
Commits) and how the work is split into commits. They never decide whether to commit everything (step 4 always
does) and never make you push.
4. Stage the rest and commit. Unless the instructions say otherwise, use one commit, or a few if the work splits into
clear steps, and start each message with the ticket key from `$OTAQ_TICKET`:
```sh
git add -A
git commit -m "SHOP-19: add the price table with sorting"
```
5. The user's git hooks and settings apply. If a hook rejects the commit, fix the problem and commit again; never use
`--no-verify`.
6. Check that `git status` is clean. **Never push.**