メニュー
Plans and executes git commits with optional TICKET_ID prefix. Analyzes staged changes, proposes optimal commit structure (single or multiple), generates descriptive messages with technical context, and executes after user approval. Use when committing code changes, creating atomic commits, or splitting large changesets.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | git-commit |
| description | Plans and executes git commits with optional TICKET_ID prefix. Analyzes staged changes, proposes optimal commit structure (single or multiple), generates descriptive messages with technical context, and executes after user approval. Use when committing code changes, creating atomic commits, or splitting large changesets. |
| allowed-tools | Bash(git diff:*) Bash(git status:*) Bash(git log:*) Bash(git show:*) |
Analyze staged changes and create optimal commit plan, then execute after user approval.
$ARGUMENTS may contain a TICKET_ID (e.g., JIRA-123, GH-456).
TICKET_ID: git status --porcelain
Show user:
Ask user to confirm scope:
If nothing to commit (no staged + no changes) → inform and exit.
Run in parallel:
git diff --staged --stat
git diff --staged --name-only
git log --oneline -5 # for message style reference
Assess:
Single commit when:
Multiple commits when:
Title format (max 60 chars):
TICKET-123: Add user authenticationAdd user authentication middlewarePrefixes: Add, Fix, Update, Refactor, Remove, Implement
Body (technical context for future readers):
Target ~50-150 words. Audience: technical people reading git history to understand WHY.
Style:
Anti-patterns:
Example:
TICKET-123: Fix memory leak in cache service
Cache entries weren't being cleaned up when TTL expired, causing
memory to grow unbounded under sustained load. This adds reference
counting to track active cache users and a cleanup routine in the
TTL handler that only removes entries with zero references.
Format:
COMMIT PLAN
===========
Files: X | Lines: +Y/-Z
Commit 1: [message title]
file1.js (new)
file2.ts (modified)
Body:
[technical explanation]
[If multiple commits, show each]
Approve? (yes/no/modify)
After approval:
Single commit:
git commit -m "title" -m "body"
Multiple commits:
git reset (unstage all)git add [specific files]git commit -m "title" -m "body"git log --oneline -3
git log -1 --format=medium
Show:
Reviews code changes before merging, through a correctness/security lens and an SRE operational-risk lens. Use when reviewing PRs, checking staged changes, reviewing diffs, code review, merge readiness check, assessing deploy or rollback risk, or validating changes before commit/push.
Dispatches a task to a Claude Fable 5 subagent with a prompt written the way Fable 5 wants to be prompted, and holds a back-and-forth with it across turns. Use when the user says /ask-fable, ask fable, fable, fable 5, send this to fable, hand this off to fable, get a Fable second opinion, or when a task sits at the top of the difficulty range: multi-hour or multi-day implementations, deep debugging, whole-repo review or bug hunts, dense technical screenshots, or ambiguous multithreaded requests where first-shot correctness matters.
Drafts a copy-pasteable prompt for Claude Fable 5 without dispatching anything. Use when the user says /prompt-fable, write me a fable prompt, draft a prompt for fable, help me prompt fable 5, or wants to hand a prompt to Fable somewhere else (the web app, another session, a colleague). For actually running the task, use the ask-fable skill instead.
User-invoked codebase recon via an ant-colony pattern. The moderator carves a large or unfamiliar codebase into disjoint territories, fans out cheap Haiku scout subagents that explore in parallel and dump full findings to /tmp scratchpads (returning only terse pointers), then one Sonnet verifier cross-checks every claim against the repo before reporting. Use to map an unfamiliar codebase or locate where something lives without bloating the main context.
User-invoked breadth check — convenes 3 specialist subagent personas to pressure-test a plan/decision/diff from angles you might have missed, surfacing framed positions + a dissent log. Intended to run AFTER the user has already reasoned through the problem, as a final "did we miss anything" sweep.
Serialize the current brainstorm/design discussion into a structured implementation spec and delegate the build to the cheaper "executor" subagent (Sonnet). Use when the user says to dispatch, delegate, hand off, or offload implementation to the executor after designing an approach together.