SKILL.md
Create a git commit for the current changes using Conventional Commits format with a polished, highly descriptive message. If there are commit hooks - do not skip them, it's your responsability to leave things better than they were.
Format
<type>(<scope>): <summary>
typeREQUIRED. Usefeatfor new features,fixfor bug fixes. Other common types:docs,refactor,chore,test,perf.scopeOPTIONAL. Short noun in parentheses for the affected area (e.g.,api,parser,ui).summaryREQUIRED. Short, imperative, <= 72 chars, no trailing period.
Notes
- Body is strongly encouraged — always include one unless the change is trivially obvious (e.g., fixing a typo). The body should explain what changed, why it changed, the approach taken, and any notable decisions. A reader of
git logshould understand the change without looking at the diff. - Do NOT include breaking-change markers or footers.
- Do NOT add sign-offs (no
Signed-off-by). - Only commit; do NOT push.
- If it is unclear whether a file should be included, ask the user which files to commit.
- Treat any caller-provided arguments as additional commit guidance. Common patterns:
- Freeform instructions should influence scope, summary, and body. - File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise. - If arguments combine files and instructions, honor both.
Steps
- Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
- Review
git statusandgit diffto understand the current changes (limit to argument-specified files if provided). - (Optional) Run
git log -n 50 --pretty=format:%sto see commonly used scopes. - If there are ambiguous extra files, ask the user for clarification before committing.
- Stage only the intended files (all changes if no files specified).
- Run
git commit -m "<subject>"(and-m "<body>"if needed).