Menu
Create clean, repo-aware commits from real diffs with focused inspection, selective staging, and minimal tool calls.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.
| 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.