| name | commit |
| description | Create a clean, focused Git commit for completed repository work. Use when the user asks to commit, make a commit, save the work as a commit, or invokes /commit or $commit. |
Commit
Create one intentional commit containing only the completed work in scope.
Hard Rules
- Commit authorship belongs solely to the repository user's existing Git
identity. Never attribute a commit to an agent, assistant, model, or AI.
- Never add
Co-Authored-By, Generated-By, or any equivalent trailer or message.
- Never pass
--trailer, --author, or a Cursor/agent email to git commit. The
host may still rewrite the command and inject
Co-authored-by: Cursor <cursoragent@cursor.com>. That is still forbidden.
- Never change Git author identity to an agent identity. If author identity is missing, stop and report it.
- Never attribute branch ownership to an agent, assistant, model, AI, or tool.
Use a neutral, purpose-based branch name with no automated-author prefix or suffix.
- Never stage unrelated user changes, secrets, generated artifacts, or temporary files.
- Never push, amend, rebase, force-push, or alter earlier commits unless the user explicitly requests it.
- Never bypass a failed commit hook.
Workflow
- Read the repository instructions that govern commits and verification.
- Inspect
git status --short, the current branch, the configured Git author
identity, unstaged and staged diffs, and recent commit titles.
- Determine the exact files belonging to the completed task. Preserve every unrelated user change.
- Classify the commit before staging:
- ordinary commit: records completed work but does not release Open, Cloud, CLI, or Bench; do not bump a product version or create a release tag;
- product release commit: the user explicitly requested a release/version or explicitly designated this commit as a product release; apply the
semver skill first.
Do not treat main, user-facing work, shared-package changes, homepage work, documentation, or deployment capability as automatic evidence of a product release. Ask when the user's release intent is genuinely ambiguous.
- Confirm the relevant verification has passed. Run missing checks when repository instructions require them and their cost is proportionate to the change.
- Stage only the intended paths. Do not use a broad staging command without first proving every affected path belongs to the commit.
- Review the staged diff with
git diff --cached and check it for accidental files, secrets, debugging residue, version changes in an ordinary commit, and whitespace errors.
- Write the commit message using the format below and create the commit non-interactively.
- Inspect the complete stored commit message with
git log -1 --format=%B.
Do not rely on the message passed to git commit, because the runtime may
inject attribution afterward. Verify that the author is the repository
user's existing identity and that the message contains no agent, assistant,
model, AI, or tool attribution.
- If attribution was injected, do not push or report success. Do not
--amend a hook-failed commit. If hooks succeeded and the stored message
still contains agent attribution, rewrite only the commit metadata:
keep HEAD^{tree} and HEAD^, keep the user's GIT_AUTHOR_* from HEAD,
write a message with those trailers removed, git commit-tree, then
git reset --soft to the new hash. Repeat the stored-message and author
checks. Never use this path to change the tree, skip hooks, or alter an
earlier commit.
- Verify the result with
git status --short and inspect the new commit
summary.
Commit Message
This is the canonical GitHub git-title contract. PR titles match it because they become the squash commit.
Use a concise, imperative title that:
- is entirely lowercase, including acronyms
- describes one coherent change
- is preferably 3–8 words and 72 characters or fewer
- has no trailing period
- is a verb plus an object, not a press sentence
- avoids vague titles such as
updates, fixes, or changes
- avoids marketing adjectives such as
first, stable, self-hosted, clean, simple, or official
- follows an established repository prefix only when the repository requires one
Ordinary commits omit the version. Version belongs in a product-release title, the Git tag, and release metadata.
Product-release commits use this exact shape, with the version semver already chose:
release open 1.0.0
release cloud 0.4.0
release cli 1.2.0
release bench 2.0.0
Do not invent a version. Do not write a slogan instead of this shape.
Default to a title only. Do not add a body. The diff already shows what changed.
Add a body only when the code cannot say it: why this over the obvious alternative, a compatibility or migration constraint, or something not to revert. Separate it from the title with a blank line. Use clean - bullets for multiple points. Do not restate the diff or write a file-by-file inventory.
add commit workflow
Not:
publish the first stable self-hosted creed open release
Stop Conditions
Stop without committing and report the blocker when:
- the intended scope cannot be determined safely
- unresolved merge conflicts exist
- the staged diff contains likely credentials or secrets
- Git author identity is missing
- there is nothing meaningful to commit
- a required check or commit hook fails because of the proposed change
If a check fails for an unrelated pre-existing reason, identify that clearly and follow the repository's stated policy rather than silently claiming success.
Anti-Patterns
- Do not trust the
git commit argv as the stored message. Inspect git log -1.
- Do not stage everything merely because it is convenient.
- Do not mix separate tasks into one commit.
- Do not add a commit body by default. Do not add a body that restates the diff or repeats the title.
- Do not claim checks passed unless they were actually run.
- Do not expose unrelated working-tree details in the final response.
- Do not bump Open, Cloud, CLI, or Bench merely because a commit lands on
main.
- Do not write a marketing sentence as a commit title. Put that prose in the changelog or GitHub release notes.
- Do not create category tags such as
open, docs, home, or fix; release tags are created only through explicit release work.
Report
After a successful commit, report the commit hash and exact title, summarize its scope in one sentence, and state the verification performed.
