Conventional Commit Generator
Generate commit messages following the Conventional Commits specification.
Workflow
FIRST: Read .ai-factory/config.yaml if it exists to resolve:
- Paths:
paths.description, paths.architecture, paths.rules_file, paths.roadmap, and paths.rules
- Language:
language.ui for prompts and commit message conventions
- Git preference:
git.skip_push_after_commit for post-commit push behavior
- Rules hierarchy:
rules.base plus any named rules.<area> entries
If config.yaml doesn't exist, use defaults:
- Paths:
.ai-factory/ for all artifacts
- Language:
en (English)
- Git preference:
skip_push_after_commit: false
Read .ai-factory/skill-context/aif-commit/SKILL.md — MANDATORY if the file exists.
This file contains project-specific rules accumulated by /aif-evolve from patches,
codebase conventions, and tech-stack analysis. These rules are tailored to the current project.
How to apply skill-context rules:
- Treat them as project-level overrides for this skill's general instructions
- When a skill-context rule conflicts with a general rule written in this SKILL.md,
the skill-context rule wins (more specific context takes priority — same principle as nested CLAUDE.md files)
- When there is no conflict, apply both: general rules from SKILL.md + project rules from skill-context
- Do NOT ignore skill-context rules even if they seem to contradict this skill's defaults —
they exist because the project's experience proved the default insufficient
- CRITICAL: skill-context rules apply to ALL outputs of this skill — including the commit
message format and conventions. If a skill-context rule says "commits MUST follow format X"
or "message MUST include Y" — you MUST comply. Generating a commit message that violates
skill-context rules is a bug.
Enforcement: After generating any output artifact, verify it against all skill-context rules.
If any rule is violated — fix the output before presenting it to the user.
Analyze Changes
- Run
git status to see staged files
- Run
git diff --cached to see staged changes
- If nothing staged, show warning and suggest staging
Run Context Gates (Read-Only)
- Check the resolved architecture and description artifacts (use paths from config) to catch obvious scope/boundary drift
- Check the resolved RULES.md and roadmap artifacts (use paths from config) to catch rule and milestone alignment issues
- Check rules hierarchy (resolved
paths.rules_file + rules.base + named rules.<area>) for commit conventions
- Missing optional files (
ROADMAP.md, RULES.md) are WARN, not blockers
- Never modify context artifacts from this command
Determine Commit Type
feat: New featurefix: Bug fixdocs: Documentation onlystyle: Code style (formatting, semicolons)refactor: Code change that neither fixes a bug nor adds a featureperf: Performance improvementtest: Adding or modifying testsbuild: Build system or dependenciesci: CI configurationchore: Maintenance tasks
Identify Scope
- From file paths (e.g.,
src/auth/ → auth)
- From argument if provided
- Optional - omit if changes span multiple areas
Generate Message
- Keep subject line under 72 characters
- Use imperative mood ("add" not "added")
- Don't capitalize first letter after type
- No period at end of subject
Format
<type>(<scope>): <subject>
<body>
<footer>
Examples
Simple feature:
feat(auth): add password reset functionality
Bug fix with body:
fix(api): handle null response from payment gateway
The payment API can return null when the gateway times out.
Added null check and retry logic.
Fixes #123
Breaking change:
feat(api)!: change response format for user endpoint
BREAKING CHANGE: user endpoint now returns nested profile object
Behavior
When invoked:
Check for staged changes
Analyze the diff content
Run read-only context gates and summarize findings as WARN/ERROR
If commit type is feat/fix/perf and roadmap exists, check milestone linkage; if missing, warn and suggest adding linkage in commit body/footer
Propose a commit message
Confirm with the user before committing:
AskUserQuestion: Proposed commit message:
<type>(<scope>): <subject>
Options:
1. Commit as is
2. Edit message
3. Cancel
Handle user response:
- Commit as is → proceed to step 8
- Edit message → ask the user for the corrected message via
AskUserQuestion, then return to step 6 with the new message
- Cancel → stop, do NOT commit. End the workflow
Execute git commit with the confirmed message
Post-commit push handling:
If git.skip_push_after_commit = true in resolved config:
- Skip push prompt entirely
- End workflow after successful local commit
Otherwise (default behavior), offer to push:
- Show branch/ahead status:
git status -sb
- If the branch has no upstream, use:
git push -u origin <branch>
- Otherwise:
git push
AskUserQuestion: Push to remote?
Options:
1. Push now
2. Skip push
- Push now → execute push command based on upstream status:
- if branch has no upstream →
git push -u origin <branch>
- otherwise →
git push
- Skip push → end the workflow
If argument provided (e.g., /aif-commit auth):
- Use it as the scope
- Or as context for the commit message
Important
- Never commit secrets or credentials
- Review large diffs carefully before committing
/aif-commit has no implicit strict mode — context gates are warning-first unless user explicitly requests blocking behavior- Treat the resolved architecture, roadmap, RULES.md, and description artifacts as read-only context in this command
- If staged changes contain unrelated work (e.g., a feature + a bugfix, or changes to independent modules), suggest splitting into separate commits:
Show which files/hunks belong to which commit
Confirm split plan with the user:
AskUserQuestion: Split into separate commits?
Options:
1. Yes, split as suggested
2. No, commit everything together
3. Let me adjust the grouping
Handle user response:
- Yes, split as suggested → proceed to step 4
- No, commit everything together → proceed to step 5 (propose single commit message)
- Let me adjust the grouping → ask the user for the adjusted grouping via
AskUserQuestion, then return to step 2 with the new plan
Unstage all: git reset HEAD
Stage and commit each group separately using git add <files> + git commit
Offer to push only after all commits are done
- NEVER add
Co-Authored-By or any other trailer attributing authorship to the AI. Commits must not contain AI co-author lines
1---2name: aif-commit3description: Create conventional commit messages by analyzing staged changes. Generates semantic commit messages following the Conventional Commits specification. Use when user says "commit", "save changes", or "create commit".4---56# Conventional Commit Generator78Generate commit messages following the [Conventional Commits](https://www.conventionalcommits.org/) specification.910## Workflow1112**FIRST:** Read `.ai-factory/config.yaml` if it exists to resolve:13- **Paths:** `paths.description`, `paths.architecture`, `paths.rules_file`, `paths.roadmap`, and `paths.rules`14- **Language:** `language.ui` for prompts and commit message conventions15- **Git preference:** `git.skip_push_after_commit` for post-commit push behavior16- **Rules hierarchy:** `rules.base` plus any named `rules.<area>` entries1718If config.yaml doesn't exist, use defaults:19- Paths: `.ai-factory/` for all artifacts20- Language: `en` (English)21- Git preference: `skip_push_after_commit: false`2223**Read `.ai-factory/skill-context/aif-commit/SKILL.md`** — MANDATORY if the file exists.2425This file contains project-specific rules accumulated by `/aif-evolve` from patches,26codebase conventions, and tech-stack analysis. These rules are tailored to the current project.2728**How to apply skill-context rules:**29- Treat them as **project-level overrides** for this skill's general instructions30- When a skill-context rule conflicts with a general rule written in this SKILL.md,31 **the skill-context rule wins** (more specific context takes priority — same principle as nested CLAUDE.md files)32- When there is no conflict, apply both: general rules from SKILL.md + project rules from skill-context33- Do NOT ignore skill-context rules even if they seem to contradict this skill's defaults —34 they exist because the project's experience proved the default insufficient35- **CRITICAL:** skill-context rules apply to ALL outputs of this skill — including the commit36 message format and conventions. If a skill-context rule says "commits MUST follow format X"37 or "message MUST include Y" — you MUST comply. Generating a commit message that violates38 skill-context rules is a bug.3940**Enforcement:** After generating any output artifact, verify it against all skill-context rules.41If any rule is violated — fix the output before presenting it to the user.42431. **Analyze Changes**44 - Run `git status` to see staged files45 - Run `git diff --cached` to see staged changes46 - If nothing staged, show warning and suggest staging47482. **Run Context Gates (Read-Only)**49 - Check the resolved architecture and description artifacts (use paths from config) to catch obvious scope/boundary drift50 - Check the resolved RULES.md and roadmap artifacts (use paths from config) to catch rule and milestone alignment issues51 - Check rules hierarchy (resolved `paths.rules_file` + `rules.base` + named `rules.<area>`) for commit conventions52 - Missing optional files (`ROADMAP.md`, `RULES.md`) are `WARN`, not blockers53 - Never modify context artifacts from this command54553. **Determine Commit Type**56 - `feat`: New feature57 - `fix`: Bug fix58 - `docs`: Documentation only59 - `style`: Code style (formatting, semicolons)60 - `refactor`: Code change that neither fixes a bug nor adds a feature61 - `perf`: Performance improvement62 - `test`: Adding or modifying tests63 - `build`: Build system or dependencies64 - `ci`: CI configuration65 - `chore`: Maintenance tasks66674. **Identify Scope**68 - From file paths (e.g., `src/auth/` → `auth`)69 - From argument if provided70 - Optional - omit if changes span multiple areas71725. **Generate Message**73 - Keep subject line under 72 characters74 - Use imperative mood ("add" not "added")75 - Don't capitalize first letter after type76 - No period at end of subject7778## Format7980```81<type>(<scope>): <subject>8283<body>8485<footer>86```8788## Examples8990**Simple feature:**91```92feat(auth): add password reset functionality93```9495**Bug fix with body:**96```97fix(api): handle null response from payment gateway9899The payment API can return null when the gateway times out.100Added null check and retry logic.101102Fixes #123103```104105**Breaking change:**106```107feat(api)!: change response format for user endpoint108109BREAKING CHANGE: user endpoint now returns nested profile object110```111112## Behavior113114When invoked:1151161. Check for staged changes1172. Analyze the diff content1183. Run read-only context gates and summarize findings as `WARN`/`ERROR`1194. If commit type is `feat`/`fix`/`perf` and roadmap exists, check milestone linkage; if missing, warn and suggest adding linkage in commit body/footer1205. Propose a commit message1216. Confirm with the user before committing:122123 ```124 AskUserQuestion: Proposed commit message:125126 <type>(<scope>): <subject>127128 Options:129 1. Commit as is130 2. Edit message131 3. Cancel132 ```1331347. Handle user response:135 - **Commit as is** → proceed to step 8136 - **Edit message** → ask the user for the corrected message via `AskUserQuestion`, then return to step 6 with the new message137 - **Cancel** → stop, do NOT commit. End the workflow1381398. Execute `git commit` with the confirmed message1409. Post-commit push handling:141 - If `git.skip_push_after_commit = true` in resolved config:142 - Skip push prompt entirely143 - End workflow after successful local commit144 - Otherwise (default behavior), offer to push:145 - Show branch/ahead status: `git status -sb`146 - If the branch has no upstream, use: `git push -u origin <branch>`147 - Otherwise: `git push`148149 ```150 AskUserQuestion: Push to remote?151152 Options:153 1. Push now154 2. Skip push155 ```156157 - **Push now** → execute push command based on upstream status:158 - if branch has no upstream → `git push -u origin <branch>`159 - otherwise → `git push`160 - **Skip push** → end the workflow161162If argument provided (e.g., `/aif-commit auth`):163- Use it as the scope164- Or as context for the commit message165166## Important167168- Never commit secrets or credentials169- Review large diffs carefully before committing170- `/aif-commit` has no implicit strict mode — context gates are warning-first unless user explicitly requests blocking behavior171- Treat the resolved architecture, roadmap, RULES.md, and description artifacts as read-only context in this command172- If staged changes contain unrelated work (e.g., a feature + a bugfix, or changes to independent modules), suggest splitting into separate commits:173 1. Show which files/hunks belong to which commit174 2. Confirm split plan with the user:175176 ```177 AskUserQuestion: Split into separate commits?178179 Options:180 1. Yes, split as suggested181 2. No, commit everything together182 3. Let me adjust the grouping183 ```184185 3. Handle user response:186 - **Yes, split as suggested** → proceed to step 4187 - **No, commit everything together** → proceed to step 5 (propose single commit message)188 - **Let me adjust the grouping** → ask the user for the adjusted grouping via `AskUserQuestion`, then return to step 2 with the new plan189 4. Unstage all: `git reset HEAD`190 5. Stage and commit each group separately using `git add <files>` + `git commit`191 6. Offer to push only after all commits are done192- NEVER add `Co-Authored-By` or any other trailer attributing authorship to the AI. Commits must not contain AI co-author lines
1t1sCooL