一键导入
commit
Review all staged changes and create a conventional commit message derived from the actual diff. Use after running git add. Do not invoke automatically.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Review all staged changes and create a conventional commit message derived from the actual diff. Use after running git add. Do not invoke automatically.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Determine the latest Kotlin + AGP versions compatible with BOTH the current Android Studio and the current IntelliJ IDEA (the lagging IDE is the cap), compare against this project's pins, and present a dated inline report. Researches live; report-only — proposes a bump but never edits without confirmation. Do not invoke automatically.
Cut a new release — analyse source changes, recommend the next version, confirm it, then bump gradle.properties, write CHANGELOG.md, and commit. Optionally invoke with a version number to pre-fill the recommendation. Do not invoke automatically.
Run BOTH review lenses over the whole project — the eleven rv-* house-rules specialists and the nine bp-* currency specialists — in parallel waves, then synthesize ONE prioritized, cross-deduplicated review document written to docs/full-review-YYYY-MM-DD.md (findings + a phased fix plan). Heavyweight (twenty subagents); for release gates / periodic full audits, not per-diff. Writes only that doc; makes no other code changes. Do not invoke automatically.
Orchestrate a currency audit of the whole project against the latest official upstream best practices, using the nine bp-* specialist subagents dispatched in parallel waves, then synthesize one prioritized, source-cited review document written to docs/currency-review-YYYY-MM-DD.md (findings + a phased fix plan). Writes only that doc; makes no other code changes (each subagent may persist notes to its own project memory). Do not invoke automatically.
Orchestrate a full house-rules review of the entire project from the eleven rv-* review specialists, dispatched in three parallel waves, then synthesize one prioritized review document written to docs/house-review-YYYY-MM-DD.md (findings + a phased fix plan). Writes only that doc; makes no other code changes (each subagent may persist notes to its own project memory). Do not invoke automatically.
Audit this project's `.claude/` subagents, skills, and hooks against the LATEST official Claude Code docs, then present a dated best-practices report inline. Researches current guidance live (does not rely on memory). Read-then-offer — proposes fixes but does not apply them without confirmation. Do not invoke automatically.
| name | commit |
| description | Review all staged changes and create a conventional commit message derived from the actual diff. Use after running git add. Do not invoke automatically. |
| disable-model-invocation | true |
| allowed-tools | Bash(git diff*), Bash(git log --oneline*), Bash(git commit*) |
!git diff --cached --name-only
!git diff --cached
Review the staged diff above and commit with an appropriate conventional commit message. Do not stage any additional files.
If the staged files list above is empty, stop and tell the user there is nothing staged to commit.
Pick exactly one type based on what the diff does:
| Type | When to use |
|---|---|
feat | New user-visible feature or behaviour |
fix | Bug fix — corrects wrong behaviour |
test | Adding or correcting tests only, no production code change |
refactor | Code restructuring with no behaviour change and no new tests |
build | Build files, dependencies, version bumps (*.kts, libs.versions.toml, gradle.properties) |
ci | CI/CD workflow changes (.github/) |
docs | Documentation only (README.md, CHANGELOG.md, *.md) |
chore | Anything else that doesn't fit the above |
If the diff spans multiple types, pick the one that best describes the primary intent.
Rules:
<type>(<optional scope>): <short description>core-domain, posting-impl, build-logicCo-Authored-By trailer.Display the proposed commit message to the user and ask: "Commit with this message? (yes / edit / cancel)"
Run the commit using a Bash heredoc (not PowerShell syntax):
git commit -m "$(cat <<'EOF'
<subject line>
<body if any>
EOF
)"
After the commit succeeds, show the one-line output of git log --oneline -1 so the user can confirm what was recorded.