Create small, focused Pull Requests by splitting implementations into atomic steps. Prevents direct work on main/master branches and enforces safe Git workflows.
このSkillは、mainブランチでの直接作業を防止し、小さく分割された「アトミック」なPRを作成するための包括的なワークフローを提供します。
問題:
git add .で一括コミット解決策:
このSkillは以下の場合に自動的に発動します：
git commit、git add、git pushを実行しようとした時最初に必ず実行：現在のブランチをチェック
git branch --show-current
判定：
main、master、developの場合
→ 即座に処理を中断
→ featureブランチ作成を促す（Phase 2へ）
featureブランチの場合 → Phase 1へ進む
重要: この保護チェックをスキップしてはいけません。
目的: 実装を小さなステップに分割し、レビュー可能なPRを計画する
以下を確認：
プロンプト例：
「既存のコードを壊さないように、小さなステップでPRを分けて実装したい。
この機能を段階的に実装するための最適な分割案を提案してください。」
分割の原則（重要）：
良い分割の例：
## 機能: ユーザー認証システム追加
### ステップ1（PR#1）
- ドメインオブジェクト（User型）に認証項目を追加するだけ
- 変更ファイル: `types/user.ts`
- リスク: 低（既存機能に影響なし）
### ステップ2（PR#2）
- 新しい認証プロバイダを作成するだけ
- 変更ファイル: `providers/auth-provider.ts`
- リスク: 低（誰も使っていない）
### ステップ3（PR#3）
- 認証UIコンポーネントを作成
- 変更ファイル: `components/Login.tsx`
- リスク: 中（既存機能と統合）
### ステップ4（PR#4）
- 既存のルーティングと統合
- 変更ファイル: `routes.ts`, `App.tsx`
- リスク: 中（既存フローに影響）
悪い分割の例：
❌ ステップ1: ユーザー認証システム全体を実装
- 変更ファイル: 10個以上
- リスク: 高（レビューが困難）
提案した分割案をユーザーに提示し、調整：
前提: Phase 0で保護ブランチを検出した場合、またはPR分割の各ステップで新しいブランチを作成
フォーマット：
(feature|bugfix|hotfix)/<ticket-id>-<description>
例：
feature/TASK-123-add-user-domain
feature/TASK-123-add-auth-provider
bugfix/BUG-456-fix-login-error
hotfix/HOTFIX-789-security-patch
# ベースブランチから作成
git checkout main
git pull origin main
git checkout -b feature/TASK-123-add-user-domain
git branch --show-current
# => feature/TASK-123-add-user-domain
前提: Phase 1で計画したステップに従って実装
現在のステップ（例: ステップ1）の内容だけを実装：
git status
重要: git add -A は絶対に使用しない
変更ファイルを以下のカテゴリに分類：
個別にステージング：
# 機能実装
git add src/types/user.ts
# テスト
git add tests/user.test.ts
# ドキュメント
git add docs/user-model.md
前提: Phase 3でステージングが完了
| Prefix | 用途 | 例 |
|---|---|---|
feat: |
新機能追加 | feat: add User domain model |
fix: |
バグ修正 | fix: resolve login error |
add: |
ファイル・パッケージ追加 | add: install auth library |
test: |
テスト追加・修正 | test: add user model tests |
docs: |
ドキュメント変更 | docs: update auth README |
refactor: |
リファクタリング | refactor: simplify auth logic |
style: |
コードスタイル変更 | style: format auth files |
chore: |
その他の変更 | chore: update dependencies |
フォーマット：
<prefix>: <subject>
<body>
Co-Authored-By: Claude <noreply@anthropic.com>
例：
git commit -m "feat: add authentication fields to User domain model
Added email, passwordHash, and role fields to support authentication.
This is the first step in implementing the user authentication system.
Co-Authored-By: Claude <noreply@anthropic.com>"
前提: Phase 4でコミットが完了
git push -u origin feature/TASK-123-add-user-domain
フォーマット：
## Summary
このPRは[機能名]の実装における[ステップ番号]です。
## このPRでやること
- [変更内容1]
- [変更内容2]
## このPRでやらないこと（意図的に分割）
- [次のステップでやること1]
- [次のステップでやること2]
## なぜ小さく分割したか
- [理由1: 既存コードへの影響を最小化]
- [理由2: レビュー負荷を軽減]
- [理由3: リスクの高い変更を別PRで慎重に扱う]
## 次のステップ
- [ ] PR#[次のPR番号]: [次のステップの内容]
## Test plan
- [ ] [テスト項目1]
- [ ] [テスト項目2]
🤖 Generated with [Claude Code](https://claude.com/claude-code)
gh pr create --title "feat: add User domain model (Step 1/4)" --body "$(cat <<'EOF'
## Summary
このPRはユーザー認証システムの実装におけるステップ1です。
## このPRでやること
- User型に認証フィールド（email、passwordHash、role）を追加
## このPRでやらないこと（意図的に分割）
- 認証プロバイダの実装（Step 2）
- 認証UIの実装（Step 3）
- 既存ルーティングとの統合（Step 4）
## なぜ小さく分割したか
- 既存のUser型を使用しているコードへの影響を最小化
- 型定義だけなので安全で、レビューが超簡単
- 次のステップで認証プロバイダを安全に実装できる基盤を作る
## 次のステップ
- [ ] PR#2: 認証プロバイダの作成
- [ ] PR#3: 認証UIコンポーネントの作成
- [ ] PR#4: 既存ルーティングとの統合
## Test plan
- [ ] TypeScriptのコンパイルが通ることを確認
- [ ] 既存のUserを使用しているテストが通ることを確認
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
enforcing-git-commit-workflow との連携executing-ai-development-workflow との連携git-workflow コマンドとの違いgit-workflow: 包括的なGitワークフロー全体を管理creating-atomic-prs: PR分割とブランチ保護に特化A: 以下を必ず実行してください：
git stash で変更を一時退避git stash pop で変更を復元A: Phase 1-2で明示的にAIに相談してください：
「この実装を、既存のコードを壊さないように、
小さなステップでPRを分けて実装したいです。
どのように分割すればよいか提案してください。」
A: このSkillの目的は「小さく分割」することです。 以下の場合のみ、分割せずに1つのPRで進めることを検討：
git addは個別ファイルのみgit add -A や git add . を使用このSkillを使用することで：
思い出してください: 「PRは1つの機能を完結させるレベルではなく、その機能を実現するための1つのパーツレベルで分割」