git-workflow について
Git での共同開発における、コミット、ブランチ、プルリクエスト、レビュー、AI 支援コーディングのルールを定めるスキルです。リポジトリの作業手順を統一したい開発チーム向けです。
主な機能
- 01Conventional Commits の指針
- 02ステージング前の変更確認
- 03フィーチャーブランチの命名規則
- 04プルリクエストの記載要件
- 05コードレビューと AI コーディングのルール
活用シーン
- 01コミットする変更の準備
- 02機能または修正ブランチの作成
- 03要件に沿ったプルリクエストの作成
- 04AI 生成コードやコントラクト更新のレビュー
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/git-workflowを入力して読み込まれたか確認します。
詳細
Git コラボレーション標準
言語ルール
- 常に、ユーザーが使用している言語で応答してください。 ユーザーが中国語で尋ねた場合は、中国語で応答してください。英語の場合は、英語で応答してください。
コミットルール
Conventional Commits 形式を使用してください：<type>: <short description>
| 種類 | 使用する場面 |
|---|---|
feat: | 新機能またはコントラクト |
fix: | バグ修正 |
refactor: | 動作を変更しないコードの再構成 |
test: | テストの追加または更新 |
docs: | ドキュメントの変更 |
chore: | ビルド設定、依存関係の更新、ツールチェーン |
security: | セキュリティ修正または強化 |
コミットワークフロー
- ステージングする前に
git diffを実行し、すべての変更を確認します - 特定のファイルをステージングします。
.envや成果物のコミットを防ぐため、git add .は避けてください - 何をではなくなぜを説明する、簡潔なコミットメッセージを書きます
Co-Authored-Byの行は絶対に追加しないでください。コミットメッセージには説明のみを記載します- コミットのみを行ってください。明示的に依頼されない限り、
git pushは実行しないでください - main/master に直接プッシュしないでください。必ずフィーチャーブランチを使用してください
ブランチの命名
| パターン | 例 |
|---|---|
feat/<name> | feat/staking-pool |
fix/<name> | fix/reentrancy-guard |
refactor/<name> | refactor/token-structure |
PR の要件
すべての PR に以下を含める必要があります：
| セクション | 内容 |
|---|---|
| 変更の説明 | 何を変更したか、その理由 |
| テスト結果 | forge test の出力（すべて成功） |
| ガスへの影響 | 変更した関数についての forge test --gas-report の差分 |
| デプロイへの影響 | デプロイ済みコントラクトに影響するか。移行が必要か |
| レビューの重点項目 | 慎重なレビューが必要な具体的な箇所 |
コードレビューのルール
| シナリオ | 要件 |
|---|---|
| 通常の変更 | メンテナーによる承認が最低 1 件必要 |
| セキュリティ関連の変更 | メンテナーによる承認が最低 2 件必要 |
| AI が生成したコード | マージ前に手動レビューと forge test の両方に合格する必要があります |
| コントラクトのアップグレード | チーム全体のレビューと、フォーク上でのアップグレードシミュレーションが必要 |
AI 支援のルール
- AI が生成したコードは、コミット前に
forge testに合格する必要があります - AI の出力は、インポートパスの正確さ、適切なアクセス制御、ガスへの影響を必ず確認してください
- より良い結果を得るため、AI へのプロンプトには関連するファイルパスとテストケースを含めてください
- AI がコードを生成した後、書式を統一するために
forge fmtを実行してください
コメント
Markdown 対応