Menu
Use this skill when the user wants to commit code changes. Follows the Conventional Commits specification.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use this skill when creating or editing pull requests. Generates well-structured PR descriptions following GitHub best practices for reviewability.
Structural code search and rewrite using AST patterns via ast-grep. Use when text search is too brittle, you need syntax-aware queries, or want to find/transform code by structure rather than string content.
Use this skill when the user wants to synchronize their current branch with another branch. Prioritizes linear history using fast-forward merges and rebasing.
Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
| name | commit-message |
| description | Use this skill when the user wants to commit code changes. Follows the Conventional Commits specification. |
<type>(<scope>): <subject>
[optional body]
[optional footer(s)]
The scope is optional and should describe the part of the codebase affected (e.g., feat(api), fix(auth), docs(readme)).
When committing changes that include both feature/refactoring work and corresponding tests, always commit them together in a single commit. This prevents CI breakage where features are updated but tests are not, causing test failures.
Example of problematic separate commits:
feat: add new validation logic (feature without tests)test: add tests for validation (tests added later)Correct approach - single commit:
feat: add new validation logic with testsOnly separate test commits when:
git status to see all changesgit diff to review the changesgit log -1 to verify the commit was created correctlyWhen reviewing staged changes, check if they contain unrelated modifications. If so, split them into separate atomic commits — each commit should represent one logical change.
Exception: feature + its tests stay together (see Test Grouping above).
If a commit is missing changes that should have been part of it, amend the commit rather than creating a new "fix" commit. One task = one commit.
git commit --amend and force push if needed.Do not create separate commits like "fix: forgot to add X" or "chore: address review feedback" for changes that belong in the original commit.
When pushing to remote, use git push origin <branch> instead of --set-upstream to avoid changing the upstream configuration.