菜单
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".
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/lee-to/ai-factory --skill aif-commit命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
基于 SOC 职业分类
| name | aif-commit |
| description | 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". |
| argument-hint | [scope or context] |
| allowed-tools | Read Glob Bash(git *) AskUserQuestion Questions |
| disable-model-invocation | false |
Generate commit messages following the Conventional Commits specification.
FIRST: Read .ai-factory/config.yaml if it exists to resolve:
paths.description, paths.architecture, paths.rules_file, paths.roadmap, paths.rules, paths.plan, and paths.planslanguage.ui for prompts and commit message conventionsworkflow.plan_id_format for read-only active plan discovery (slug default; sequential uses numbered full-plan lookup)git.enabled, git.create_branches, and git.skip_push_after_commit for active plan discovery and post-commit push behaviorrules.base plus any named rules.<area> entriesIf config.yaml doesn't exist, use defaults:
.ai-factory/ for context artifacts, .ai-factory/PLAN.md for paths.plan, .ai-factory/plans/ for paths.plansen (English)workflow.plan_id_format: sluggit.enabled: true, git.create_branches: trueskip_push_after_commit: falseRead .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:
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
git status to see staged filesgit diff --cached to see staged changesResolve Active Plan Context (Read-Only, Optional)
@<plan-file-or-directory> argument, when the argument starts with @paths.planspaths.plans, or a single ultra bundle therepaths.plan@, keep treating it as commit scope/context.@<plan-file> syntax remains valid; the broader form additionally
accepts an ultra directory or its index.md.git branch --show-current when git.enabled = true/ with - to get <branch-stem>workflow.plan_id_format = sequential, use Glob for both
paths.plans/[0-9][0-9][0-9][0-9]_<branch-stem>.md and
paths.plans/[0-9][0-9][0-9][0-9]_<branch-stem>/index.mdindex.md
contains exactly one <!-- aif:plan-mode:ultra -->WARN [aif-commit] when
multiple valid candidates exist; if both shapes share the highest prefix,
prefer ultrapaths.plans/<branch-stem>/index.md then
paths.plans/<branch-stem>.md; Read the directory entrypoint before
selection, ignore it unless it contains exactly one ultra marker, and
warn and prefer ultra if both valid shapes exist*.md full plans plus direct child */index.md
entrypoints containing <!-- aif:plan-mode:ultra -->; exclude the resolved fast-plan
path and do not count phase files.<type>(<scope>): <subject>
<body>
<footer>
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
When invoked:
Check for staged changes
Analyze the diff content
Resolve optional active plan context and use ## Commit Plan grouping when available
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:
AskUserQuestion, then return to step 7 with the new messageExecute git commit with the confirmed message
Post-commit push handling:
If git.skip_push_after_commit = true in resolved config:
Otherwise (default behavior), offer to push:
git status -sbgit push -u origin <branch>git pushAskUserQuestion: Push to remote?
Options:
1. Push now
2. Skip push
git push -u origin <branch>git pushIf argument provided (e.g., /aif-commit auth):
/aif-commit has no implicit strict mode — context gates are warning-first unless user explicitly requests blocking behavior## Commit Plan, keep current staged-diff behavior unchanged.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:
AskUserQuestion, then return to step 2 with the new planBefore changing staging, confirm whether each planned group has a disjoint file set, whether any file spans multiple groups, and whether grouped files overlap unstaged worktree paths from git diff --name-only.
If every group has a disjoint file set and no grouped file appears in git diff --name-only, unstage all with git reset HEAD, then stage and commit each group separately using git add <files> + git commit.
If grouped files overlap unstaged worktree paths, preserve each group's original cached patch before unstaging and re-apply only that patch with git apply --cached; otherwise use hunk-level staging or stop before changing staging.
If one file spans multiple groups, use hunk-level staging for each group: stage only that group's hunks with git add -p or git apply --cached, commit, then repeat for the next group.
If hunk-level staging or cached-patch application cannot be applied confidently, stop before changing staging and ask the user to adjust grouping or commit everything together.
index.md as ultra, Read it and require exactly one
<!-- aif:plan-mode:ultra -->; otherwise STOP with a plan-integrity error.<!-- aif:plan-mode:ultra -->; ignore unrelated */index.md files.## Commit Plan, keep current staged-diff behavior unchanged.Use Commit Plan Grouping When Available
If active plan contains ## Commit Plan, parse:
after tasks 1-3 or tasks 4-6Read the plan's ## Tasks or ## Implementation Tasks section to map task ranges to task descriptions and any Files: hints.
For an ultra plan, resolve every task in the current commit group to its
Phase Index/details link, read each corresponding phase file, and build the
staged-path mapping from its ## Files to Change table plus the complete
## Task N specifications. Reading only index.md is insufficient.
If one phase contains tasks from multiple commit groups, use the individual
## Task N sections to distinguish file/hunk ownership; do not assign the
phase's entire file table to every group without task-level evidence.
Compare staged files/hunks with planned groups before changing staging:
git diff --cached --name-onlygit diff --cached when a file may span multiple groupsFiles: hints are guidance, not executable instructionsIf files cannot be mapped to groups, stop and ask the user to adjust grouping.
Before using whole-file staging, compare grouped files with unstaged worktree paths from git diff --name-only.
Only use git add <files> when each planned group has a disjoint file set and no grouped file appears in git diff --name-only.
When one file spans multiple planned groups, use hunk-level staging (git add -p or git apply --cached) for each group.
If grouped files overlap unstaged worktree paths, preserve and apply the original cached patch per group (git diff --cached + git apply --cached), use hunk-level staging, or stop before changing staging.
If hunk-level staging cannot be applied confidently, stop before changing staging and ask the user to adjust grouping or commit everything together.
When a usable grouping exists, ask:
AskUserQuestion: Active plan contains a Commit Plan. How should these staged changes be committed?
Options:
1. Follow Commit Plan
2. Commit everything together
3. Adjust grouping
Follow Commit Plan → confirm the planned groups and messages, then proceed through user-confirmed multi-commit staging/commit flow.
Commit everything together → ignore plan grouping for this run and continue with the current single-message flow.
Adjust grouping → ask the user for the adjusted grouping, then validate it against staged files before committing.
Run Context Gates (Read-Only)
paths.rules_file + rules.base + named rules.<area>) for commit conventionsROADMAP.md, RULES.md) are WARN, not blockers/aif-rules-check; keep /aif-commit gate labels at WARN / ERRORDetermine 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 tasksIdentify Scope
src/auth/ → auth)Generate Message
Offer to push only after all commits are done
Co-Authored-By or any other trailer attributing authorship to the AI. Commits must not contain AI co-author lines