git

<essential_principles>

<git_safety> 明示的なユーザーリクエストなしに破壊的なコマンドを実行しないこと:

• main/masterへの git push --force は禁止
• git reset --hard は禁止
• --no-verify フラグ(フック スキップ)は禁止
• プッシュ済みコミットへの git commit --amend は禁止

main/masterへの直接プッシュをしないこと:

• 現在のブランチが main または master の場合、コミット/プッシュ前に新しいブランチを作成する
• 変更内容に基づいた説明的なブランチ名を使用(例: fix/login-bug, feat/add-filter)
• フィーチャー/フィックスブランチへのみプッシュし、デフォルトブランチへ直接プッシュしない

実行前に常に検証すること:

• ステージング前に git status を確認
• コミットスタイルについて git log を確認
• プッシュ前にリモートトラッキングを確認 </git_safety>

<commit_format> すべてのコミットメッセージの末尾に以下を追加します:

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

複数行メッセージにはHEREDOCを使用します:

git commit -m "$(cat <<'EOF'
メッセージ内容

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"

</commit_format>

<pr_format> PRボディの構造:

## Summary
<1～3個の箇条書き>

## Test plan
- [ ] テストアイテム 1
- [ ] テストアイテム 2

🤖 Generated with [Claude Code](https://claude.com/claude-code)

</pr_format>

</essential_principles>

<intake> 何をしたいですか?

1. Commit - 変更をステージングしてコミット
2. Push - コミットをリモートにプッシュ
3. PR - プルリクエストをオープン
4. Ship - 全体ワークフロー: コミット + プッシュ + PR

進める前に回答をお待ちします。 </intake>

<routing> | 回答 | ワークフロー | |----------|----------| | 1, "commit", "stage" | `workflows/commit.md` | | 2, "push", "upload" | `workflows/push.md` | | 3, "pr", "pull request", "open pr" | `workflows/pr.md` | | 4, "ship", "full", "all" | コミット → プッシュ → PR を順番に実行 |

ワークフローを読んだ後、その指示に正確に従ってください。 </routing>

<workflows_index>

ワークフロー	目的
commit.md	変更をステージングし、適切なメッセージでコミットを作成
push.md	コミットをリモートにプッシュ、必要に応じてブランチを作成
pr.md	gh CLIを使用してプルリクエストを作成
</workflows_index>