Review the current Git changes and recent history, then create a focused commit with a Conventional Commits message. The skill helps stage only related files, follow the required format, and address hook failures before committing.
Stage and create a Conventional Commits message for the current change
Run score Not tested
See how to installReviews current changes, staged differences, and recent commit history, then guides creation of one focused commit. The commit message follows Conventional Commits, with a type such as feat or fix, an optional scope, and a short summary of the change. Breaking changes and related issues can be noted in the body or footer. If the working tree contains unrelated changes, stage only the files that belong in this commit.
Use it to review a diff before committing and match the style of the existing history. It is also useful when commit messages are checked by hooks or when you want to keep separate changes from being committed together by mistake.
The commit-msg hook uses gitlint to check commit messages. Do not use --no-verify; if a hook fails, fix the cause and commit again. Do not commit secrets, generated files, or work in progress directly to the protected main branch.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 29, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
Create a well-formed commit following the Conventional Commits
standard. The format is enforced by gitlint in the commit-msg hook.
Run git status and git diff (and git diff --staged) to see what changed.
Review recent history for style: git log --oneline -10.
Group the change into a single focused commit. If the working tree mixes
unrelated changes, stage selectively (git add -p / specific paths) rather
than committing everything at once.
Write the message in Conventional Commits form:
<type>[(scope)][!]: <imperative summary, ≤72 chars>
<optional body: what & why, wrapped at 72>
<optional footer: BREAKING CHANGE: …, Refs: #123>
Never use --no-verify. If pre-commit hooks fail, fix the cause and re-commit.
Do not commit secrets, generated artifacts, or work-in-progress directly to
the protected main branch.
| Type | Use for |
|---|---|
feat | new feature |
fix | bug fix |
refactor | behavior-preserving restructure |
test | add / update tests |
docs | documentation |
style | formatting only |
perf | performance |
chore | config / build / tooling |
build | build system or dependencies |
ci | CI configuration |
revert | revert a previous commit |
type.scope is optional: fix(search): …. A ! before the colon (or a
BREAKING CHANGE: footer) marks a breaking change.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Guide developers through adding a persisted business memory type. Choose Markdown, SQLite, and LanceDB storage and a Markdown file strategy, then wire up schemas, repositories, and writers across the layers the data needs.
Creates a scoped Git branch from the updated `main` branch using the project’s naming convention. It selects a prefix for feature work, fixes, docs, CI, maintenance, or refactoring, then adds a concise lowercase, hyphenated name.
Opens a GitHub pull request from a scoped branch to `main` using the repository’s template. It checks that `make ci` passes, pushes the branch, and guides completion of the summary, change area, verification, checklist, and reviewer notes.
Prepare and publish a versioned everos release to PyPI. The skill guides version and changelog updates, the tag-triggered workflow, its approval step, and review and publication of the resulting GitHub Release draft.