メニュー
Create clean, repo-aware commits from real diffs with focused inspection, selective staging, and minimal tool calls.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | git-commit |
| description | Create clean, repo-aware commits from real diffs with focused inspection, selective staging, and minimal tool calls. |
Commit current repo changes atomically, with accurate messages and no unrelated files.
Use one tool call for the common inspection:
git status --short
git diff --stat
git diff
git diff --cached --stat
git diff --cached
If staged output is empty, ignore it. Check repo message conventions only when unknown: prefer existing context, then obvious files such as .gitmessage, CONTRIBUTING.md, or commit config. Use recent history only when style is still unclear.
Split only for real separate concerns: behavior vs refactor, dependency churn vs code, generated output without source, formatting-only churn, or unrelated docs/tests. Keep directly related tests with the fix/feature.
Stage only intended paths:
git add <specific-files>
Use git add -p only when file-level staging would mix unrelated changes.
If the user asked to commit a clear current change, proceed after inspection. Ask first only when included files, boundaries, risky content, or issue semantics are ambiguous. Keep questions short: included files, excluded files, proposed message, and the ambiguity.
Default format unless repo conventions say otherwise:
type(scope): summary
Types: feat, fix, refactor, perf, docs, test, build, ci, chore. Use a scope when obvious. Avoid update, changes, misc, and wip.
Issue links:
<type>/<desc>-123, issue-123, gh-123, or #123.Fixes #123 only for explicit closing intent or a clearly complete narrow issue.Refs #123 for partial, preparatory, docs-only, cleanup-only, or ambiguous work.Use normal Git so hooks run:
git commit -m "<subject>"
If hooks fail, stop and report. Do not use --no-verify, push, rewrite history, or force anything unless explicitly asked.
Report the final commit hash and whether hooks/checks ran.
Generate a local static interactive D3 walkthrough of a pull request. Use when the user wants a zoomable PR map, graph/canvas PR orientation, or alternate visualization of PR system components, data flow, code dependencies, and user actions.
Bootstrap the issue triage configuration for a repository by analyzing existing issues, labels, and contributors to generate `.github/issue-triage/config.json` and `.github/CODEOWNERS`. Use when setting up triage automation on a new or existing repository for the first time.
Compare a pull request's implementation against spec context in spec_context.md and feed any material mismatches into review.json. Use during PR review when approved or repository spec context is available.
Create a product spec from a GitHub issue in this repository by applying the local shared `write-product-spec` workflow with issue context and output paths. Use when an issue should be turned into a product spec artifact stored under `specs/issue-<issue-number>/product.md` and the agent should prepare file changes only, without creating commits or pull requests itself.
Create a technical spec from a GitHub issue in this repository by applying the local shared `write-tech-spec` workflow with issue context and output paths. Use when an issue should be turned into a tech spec artifact stored under `specs/issue-<issue-number>/tech.md` and the agent should prepare file changes only, without creating commits or pull requests itself.
Repo-specific dedupe guidance . Only the categories declared overridable by the core dedupe-issue skill may be specialized here.