Anthropic Claude個人生産性⭐ リポ 0品質スコア 50/100

git-pr-workflows-git-workflow

Name: git-pr-workflows-git-workflow
Author: sickn33

コードレビューからPR作成までの包括的なgitワークフローを、品質保証・テスト・デプロイ準備に特化したエージェントを活用しながら統合的に管理します。モダンなgitのベストプラクティスに基づき、各工程を自動化することで、一貫性の高い開発フローを実現します。

description の原文を見る

Orchestrate a comprehensive git workflow from code review through PR creation, leveraging specialized agents for quality assurance, testing, and deployment readiness. This workflow implements modern g

SKILL.md 本文

マルチエージェントオーケストレーションを用いた完全な Git ワークフロー

コードレビューから PR 作成まで、包括的な git ワークフローをオーケストレーションします。品質保証、テスト、デプロイ準備のための専門的なエージェントを活用します。このワークフローは、従来のコミット、自動テスト、構造化された PR 作成を含む最新の git ベストプラクティスを実装しています。

[Extended thinking: このワークフローは複数の専門的なエージェントを連携させ、コミットがリポジトリに入る前にコード品質を確保します。code-reviewer エージェントが初期品質チェックを実行し、test-automator がすべてのテストをパスさせ、deployment-engineer が本番環境への準備状況を確認します。これらのエージェントをコンテキストの受け渡しとともに順序立てて調整することで、破損したコードがリポジトリに入るのを防ぎながら、高速な開発速度を維持します。このワークフローは trunk-based と feature-branch の両方の戦略をサポートし、異なるチームニーズに対応するための構成可能なオプションを提供します。]

このスキルを使用する場合

マルチエージェントオーケストレーションを含む完全な git ワークフローのタスクまたはワークフローに取り組む場合
完全な git ワークフローのマルチエージェントオーケストレーションに関するガイダンス、ベストプラクティス、またはチェックリストが必要な場合

このスキルを使用しない場合

タスクが完全な git ワークフローのマルチエージェントオーケストレーションと無関係である場合
このスコープ外の異なるドメインまたはツールが必要な場合

指示

目標、制約、必要な入力を明確にする
関連するベストプラクティスを適用し、結果を検証する
実行可能なステップと検証を提供する
詳細な例が必要な場合は、resources/implementation-playbook.md を開く

設定

ターゲットブランチ: $ARGUMENTS (指定されない場合は 'main' がデフォルト)

サポートされるフラグ:

--skip-tests: 自動テスト実行をスキップ (注意して使用)
--draft-pr: PR をドラフトとして作成 (作業中の場合)
--no-push: すべてのチェックを実行するがリモートにプッシュしない
--squash: プッシュ前にコミットをスカッシュ
--conventional: Conventional Commits フォーマットを厳密に強制
--trunk-based: Trunk-based 開発ワークフローを使用
--feature-branch: Feature branch ワークフローを使用 (デフォルト)

フェーズ 1: コミット前レビューと分析

1. コード品質評価

Task ツールを使用し subagent_type="code-reviewer" で実行
プロンプト: "コミットされていないすべての変更をコード品質の問題についてレビューしてください。以下を確認してください: 1) コードスタイル違反、2) セキュリティ脆弱性、3) パフォーマンスの懸念、4) エラーハンドリングの欠落、5) 不完全な実装。行ごとの詳細なフィードバック付きで、深刻度レベル (critical/high/medium/low) を含むレポートを生成してください。出力形式: {issues: [], summary: {critical: 0, high: 0, medium: 0, low: 0}, recommendations: []} を含む JSON"
予想される出力: 次のフェーズ用の構造化されたコードレビューレポート

2. 依存関係と破損変更の分析

Task ツールを使用し subagent_type="code-reviewer" で実行
プロンプト: "変更について以下を分析してください: 1) 新しい依存関係またはバージョン変更、2) 破損する API 変更、3) データベーススキーマの変更、4) 設定の変更、5) 下位互換性の問題。前回のレビューからのコンテキスト: [問題のサマリーを挿入]。マイグレーションスクリプトまたはドキュメント更新が必要な変更を特定してください。"
前回からのコンテキスト: 破損変更を示す可能性があるコード品質の問題
予想される出力: 破損変更の評価とマイグレーション要件

フェーズ 2: テストと検証

1. テスト実行とカバレッジ

Task ツールを使用し subagent_type="unit-testing::test-automator" で実行
プロンプト: "変更されたコード用のすべてのテストスイートを実行してください。以下を実行: 1) ユニットテスト、2) 統合テスト、3) 必要に応じてエンドツーエンドテスト。カバレッジレポートを生成し、テストされていないコードパスを特定してください。レビューの問題に基づいて: [critical/high の問題を挿入]、テストが問題領域をカバーしていることを確認してください。テスト結果を {passed: [], failed: [], skipped: [], coverage: {statements: %, branches: %, functions: %, lines: %}, untested_critical_paths: []} の形式で提供してください。"
前回からのコンテキスト: テストカバレッジが必要な重要なコードレビューの問題
予想される出力: 完全なテスト結果とカバレッジメトリクス

2. テストの推奨事項とギャップ分析

Task ツールを使用し subagent_type="unit-testing::test-automator" で実行
プロンプト: "テスト結果 [サマリーを挿入] とコード変更に基づいて、以下を特定してください: 1) 不足しているテストシナリオ、2) カバーされていないエッジケース、3) 検証が必要な統合ポイント、4) 必要なパフォーマンスベンチマーク。リスク別に優先順位付けされたテスト実装の推奨事項を生成してください。特定された破損変更を考慮してください: [破損変更を挿入]。"
前回からのコンテキスト: テスト結果、破損変更、テストされていないパス
予想される出力: 優先順位付けされた追加テストの必要性リスト

フェーズ 3: コミットメッセージの生成

1. 変更分析と分類

Task ツールを使用し subagent_type="code-reviewer" で実行
プロンプト: "すべての変更を分析し、Conventional Commits 仕様に従って分類してください。主な変更タイプ (feat/fix/docs/style/refactor/perf/test/build/ci/chore/revert) とスコープを特定してください。変更: [ファイルリストとサマリーを挿入]、これが単一のコミットか複数のアトミックコミットであるべきかを判断してください。テスト結果を考慮: [テストサマリーを挿入]。"
前回からのコンテキスト: テスト結果、コードレビューのサマリー
予想される出力: コミット構造の推奨事項

2. Conventional Commit メッセージの作成

Task ツールを使用し subagent_type="llm-application-dev::prompt-engineer" で実行
プロンプト: "分類に基づいて Conventional Commits フォーマットのメッセージを作成してください: [分類を挿入]。フォーマット: <type>(<scope>): <subject> で、空行の後に <body> (何と理由を説明、方法ではなく)、その後 <footer> に BREAKING CHANGE: がある場合は記載してください。以下を含めてください: 1) 明確なサブジェクト行 (最大 50 文字)、2) 根拠を説明する詳細なボディ、3) 問題/チケットへの参照、4) 該当する場合は共著者。影響を考慮: [破損変更がある場合は挿入]。"
前回からのコンテキスト: 変更の分類、破損変更
予想される出力: 適切にフォーマットされたコミットメッセージ

フェーズ 4: ブランチ戦略とプッシュ準備

1. ブランチ管理

Task ツールを使用し subagent_type="cicd-automation::deployment-engineer" で実行
プロンプト: "ワークフロータイプ [--trunk-based または --feature-branch] に基づいて、ブランチ戦略を準備してください。Feature branch の場合: ブランチ名が (feature|bugfix|hotfix)/<ticket>-<description> パターンに従うことを確認してください。Trunk-based の場合: 必要に応じてフィーチャーフラグ戦略で main へのダイレクトプッシュを準備してください。現在のブランチ: [ブランチを挿入]、ターゲット: [ターゲットブランチを挿入]。ターゲットブランチとのコンフリクトがないことを確認してください。"
予想される出力: ブランチ準備コマンドとコンフリクト状況

2. プッシュ前検証

Task ツールを使用し subagent_type="cicd-automation::deployment-engineer" で実行
プロンプト: "最終的なプッシュ前チェックを実行してください: 1) すべての CI チェックがパスすることを確認、2) コミットに機密データがないことを確認、3) 必要な場合はコミット署名を検証、4) ブランチ保護ルールを確認、5) すべてのレビューコメントに対応していることを確認。テストサマリー: [テスト結果を挿入]。レビュー状況: [レビューサマリーを挿入]。"
前回からのコンテキスト: すべての前回の検証結果
予想される出力: プッシュ準備確認またはブロック問題

フェーズ 5: プルリクエスト作成

1. PR 説明の生成

Task ツールを使用し subagent_type="documentation-generation::docs-architect" で実行
プロンプト: "以下を含む包括的な PR 説明を作成してください: 1) 変更のサマリー (何と理由)、2) 変更タイプのチェックリスト、3) [テスト結果を挿入] から実施したテストのサマリー、4) UI 変更がある場合はスクリーンショット/記録、5) [デプロイメントの考慮事項を挿入] からのデプロイメント notes、6) 関連する問題/チケット、7) 破損変更セクション (該当する場合): [破損変更を挿入]、8) レビュー担当者チェックリスト。GitHub 風 Markdown として形式化してください。"
前回からのコンテキスト: すべての検証結果、テスト成果、破損変更
予想される出力: Markdown 形式の完全な PR 説明

2. PR メタデータと自動化のセットアップ

Task ツールを使用し subagent_type="cicd-automation::deployment-engineer" で実行
プロンプト: "PR メタデータを構成してください: 1) CODEOWNERS に基づいて適切なレビュー担当者を割り当て、2) ラベルを追加 (type、priority、component)、3) 関連する問題をリンク、4) 該当する場合はマイルストーンを設定、5) マージ戦略を構成 (squash/merge/rebase)、6) すべてのチェックがパスした場合、自動マージをセットアップ。ドラフト状況を考慮: [--draft-pr フラグ]。テスト状況を含める: [テストサマリーを挿入]。"
前回からのコンテキスト: PR 説明、テスト結果、レビュー状況
予想される出力: PR 設定コマンドと自動化ルール

成功基準

✅ すべての critical および high 深刻度コード問題が解決
✅ テストカバレッジが維持または改善 (目標: >80%)
✅ すべてのテストがパス (ユニット、統合、e2e)
✅ コミットメッセージが Conventional Commits フォーマットに準拠
✅ ターゲットブランチとのマージコンフリクトがない
✅ PR 説明が完全で、すべての必須セクションを含む
✅ ブランチ保護ルールを満たす
✅ セキュリティスキャンが完了し、critical 脆弱性がない
✅ パフォーマンスベンチマークが許容範囲内
✅ API 変更については、ドキュメントが更新されている

ロールバック手順

マージ後に問題が発生した場合:

即座のリバート: git revert <commit-hash> でリバート PR を作成
フィーチャーフラグの無効化: フィーチャーフラグを使用している場合は、すぐに無効化
ホットフィックスブランチ: 重大な問題の場合は、main からホットフィックスブランチを作成
コミュニケーション: 指定されたチャネル経由でチームに通知
根本原因分析: postmortem テンプレートで問題を文書化

ベストプラクティスリファレンス

コミット頻度: 頻繁にコミットしますが、各コミットはアトミックであることを確認
ブランチ命名: (feature|bugfix|hotfix|docs|chore)/<ticket-id>-<brief-description>
PR サイズ: 効果的なレビューのため、PR を 400 行以下に保つ
レビュー対応: レビューコメントに 24 時間以内に対応
マージ戦略: Feature branch ではスカッシュ、release branch ではマージ
サインオフ: main ブランチの変更には最低 2 つの承認が必要

制限事項

このスキルは、タスクが上記の説明されたスコープと明確に一致する場合にのみ使用してください
出力を環境固有の検証、テスト、または専門家レビューの代替として扱わないでください
必要な入力、権限、安全境界、または成功基準が不足している場合は、停止して説明を求めてください。

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者: sickn33
リポジトリ: sickn33/antigravity-awesome-skills
ライセンス: MIT
最終更新: 不明

GitHubで原本を見る →フィードバックを送る

Source: https://github.com/sickn33/antigravity-awesome-skills / ライセンス: MIT