メニュー
Analyze all changes and split them into small, focused, reviewable commits grouped by logical concern. Use when the user wants to commit with best practices, create atomic commits, split changes into multiple commits, or make their PR easier to review.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Adopt Fable-class working discipline for this session — outcome-first communication, finish-the-turn autonomy, parallel tool use, faithful reporting. Use when the user says "/fable", "fable mode", "act like fable", or wants a smaller model (Opus, Sonnet) to work with the discipline of a Mythos-class model. Also invocable from other skills as a style preamble for long or high-stakes tasks.
Full workday recap across all tools — Jira, GitHub, Slack, Confluence, Google Docs, and Claude Code activity. Stores all data in SQLite with Turso sync for remote access. For Claude-only activity tracking, use /daily-review-v2 instead.
Claude Code activity tracking with SQLite/Turso storage — standup, weekly rollups, project reports, brag doc, friction tracking, goal tracking, heatmap, export. Data syncs to Turso for remote access. For full workday recap across all tools, use /daily-recap-v2 instead.
Transform a work-specific or company-specific skill/config into a generic, portable version. Replaces proprietary tools, internal URLs, and company references with generic equivalents while preserving the useful patterns and structure. Use when porting a work skill to the public config repo.
Sync ~/.claude/ global configs into this repo, sanitizing work-specific content (LinkedIn plugins, Captain MCP, work email, internal URLs). Use when the user wants to refresh this repo from their global Claude configs, pull in newly added skills/commands, or update sanitization rules. Two-pass flow with diff review before commit.
Deep discussion mode. No code changes, no file edits, no commands — pure thinking, exploration, and idea bouncing. Use when you want to explore a concept, design something, debate tradeoffs, or just think out loud. Claude will push back, ask questions, and present alternatives. Changes only happen if you explicitly say so.
| name | pr-smart-commit |
| description | Analyze all changes and split them into small, focused, reviewable commits grouped by logical concern. Use when the user wants to commit with best practices, create atomic commits, split changes into multiple commits, or make their PR easier to review. |
Analyze all current changes and organize them into the smallest possible logical commits without breaking functionality. This makes code reviews faster and easier.
Gather all changes:
git status
git diff --stat # unstaged changes
git diff --cached --stat # staged changes
Read the full diff:
git diff HEAD
Group changes into logical buckets:
Analyze the diff and propose a commit plan. Group by:
Rules for grouping:
Present the commit plan to the user:
Show a structured plan like:
Proposed commit plan (3 commits):
Commit 1: feat(auth): add JWT token validation middleware
- src/middleware/auth.js (new file)
- src/routes/index.js (lines 12-18: add middleware to protected routes)
Commit 2: test(auth): add unit tests for JWT middleware
- tests/middleware/auth.test.js (new file)
Commit 3: chore(deps): add jsonwebtoken dependency
- package.json
- package-lock.json
Does this look right? Should any groups be merged or split differently?
Wait for user approval before proceeding. They may want to:
Execute each commit in order:
For each commit in the approved plan:
a. Stage only the relevant files/hunks:
git add <file>git add -p <file> logic — read the file and stage only the relevant sections by constructing a precise patchb. Verify staged content:
git diff --cached --stat
git diff --cached
Confirm the staged diff matches exactly what was planned for this commit.
c. Generate a commit message following Conventional Commits:
<type>(<scope>): <subject> ← max 50 chars, imperative mood
<body> ← wrap at 72 chars, explain WHY
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
d. Show the message and ask for approval.
e. Commit:
git commit -m "$(cat <<'EOF'
<message>
EOF
)"
f. Confirm: git log -1 --oneline
Handle partial file staging (hunk-level splitting):
When a file has changes that belong to different commits:
git add -p interactively OR create a temporary patch file approach:
git diff <file> > /tmp/full.patch
# Then stage only specific hunks
git apply --cached /tmp/partial.patch
git diff --cached that only the intended changes are stagedFinal summary + push:
git log --oneline -<n> where n = number of commits createdgit push (or git push -u origin <branch> if no upstream set)gh pr view --json number,url 2>/dev/null
pr-update skill to refresh the PR title and description/pr-create| Type | When to use |
|---|---|
feat | New feature or behavior |
fix | Bug fix |
refactor | Code restructure, no behavior change |
test | Adding/updating tests |
docs | Documentation only |
style | Formatting, whitespace (no logic change) |
chore | Dependencies, build config, tooling |
perf | Performance improvement |
ci | CI/CD configuration |