mcpField
Q
quality-audit-workflow

quality-audit-workflow

github.com/rysweetテスト・品質7656 回インストール21 週間前に更新
リポジトリ

quality-audit-workflow について

コードベースの体系的な品質監査を行うチーム向けのスキルです。並行分析で問題を洗い出し、GitHub issueに記録し、最近のPRと照合したうえで修正PRと優先度付きの提案を作成します。

主な機能

  1. 017段階の監査ワークフロー
  2. 02コードベースの区分ごとの並行分析
  3. 03発見事項のGitHub issue化
  4. 04最近のPRとの照合による検証
  5. 05修正PRの並行作成と優先順位付け

活用シーン

  1. 01コードベースの品質問題の監査
  2. 02監査結果と最近マージされたPRの照合
  3. 03確認済みの問題に対する修正PRの作成
  4. 04優先順位付き監査レポートの作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/rysweet/amplihack --skill quality-audit-workflow

インストール後、Claude Code で/quality-audit-workflowを入力して読み込まれたか確認します。

詳細

品質監査ワークフロー

目的

コードベース全体を対象に、体系的かつ並列で品質監査を実施し、PR の作成による自動修正と、PM が優先順位を付けた推奨事項を実現します。

起動条件

次のような語句を挙げると、自動的に読み込まれます。

  • 「品質監査」または「コード監査」
  • 「コードベースのレビュー」または「コード全体のレビュー」
  • 「リファクタリングの機会」または「技術的負債の監査」
  • 「モジュールの品質チェック」または「アーキテクチャレビュー」
  • 複数のエージェントによる「並列分析」

実行内容

次の 7 段階のワークフローを実行します。

  1. プロジェクトを把握します（調査フェーズ）
  2. コードベースを分割し、並列エージェントで監査します
  3. 発見した各問題について GitHub イシューを作成します 3.5. 直近の PR と照合して検証します（誤検出を防ぎます）
  4. 残ったイシューごとに、並列ワークツリーで PR を作成します
  5. PM アーキテクトが PR をレビューして優先順位を付けます
  6. マスターイシューに推奨事項をまとめて報告します

クイックスタート

User: "Run a quality audit on this codebase"
Skill: *activates automatically*
       "Beginning quality audit workflow..."

7 つのフェーズ

フェーズ 1：プロジェクトの把握
  • プロジェクト構造に対して調査ワークフローを実行します
  • モジュール、依存関係、エントリーポイントを整理します
  • 既存のパターンとアーキテクチャを把握します
フェーズ 2：並列品質監査
  • コードベースを論理的なセクションに分割します
  • 各セクションに複数種類のエージェント（アナライザー、レビュアー、セキュリティ、オプティマイザー）を配置します
  • PHILOSOPHY.md の基準を徹底的に適用します
  • モジュールのサイズ、複雑さ、単一責任を確認します
フェーズ 3：イシューの作成
  • 発見事項ごとに GitHub イシューを作成します
  • 重大度、該当箇所、推奨事項を記載します
  • 適切なラベルを付けます
  • 一意の ID、キーワード、ファイルのメタデータを追加します
フェーズ 3.5：監査後の検証［NEW］
  • 過去 30 日間（変更可能）にマージされた PR をスキャンします
  • PR とイシューの一致度を信頼度スコアで算出します
  • 信頼度の高い一致（90% 以上）は自動でクローズします
  • 信頼度が中程度の一致（70～89%）には、確認用のタグを付けます
  • イシューと PR の間に相互参照を追加します
  • 目標：誤検出率 5% 未満
フェーズ 4：並列 PR 作成
  • 未解決のイシューごとにワークツリーを作成します（worktrees/fix-issue-XXX）
  • 各ワークツリーで DEFAULT_WORKFLOW.md を実行します
  • 確認済みの未解決イシューごとに修正 PR を作成します
フェーズ 5：PM レビュー
  • pm-architect スキルを呼び出します
  • PR をカテゴリと優先度ごとにグループ化します
  • 修正間の依存関係を特定します
フェーズ 6：マスターレポート
  • マスター GitHub イシューを作成します
  • 関連するすべてのイシューと PR をリンクします
  • 推奨事項を含む優先順位付きのアクションプランを作成します

フィロソフィーの適用

このワークフローでは、次の原則を徹底的に適用します。

  • 徹底したシンプルさ：過剰に設計されたモジュールを指摘します
  • モジュールサイズの上限：各モジュールの目標を 300 LOC 未満とします
  • 単一責任：1 つのブリックにつき 1 つの目的とします
  • ゼロ BS：スタブ、TODO、デッドコードを認めません

ナビゲーションガイド

補足ファイルを読むタイミング

reference.md - 次の情報が必要な場合に読みます。

  • 各フェーズの詳細な実行手順
  • エージェントとフェーズの対応関係
  • コードベースを分割する方法
  • イシューテンプレートの形式

examples.md - 次の情報が必要な場合に読みます。

  • 実際の監査例
  • イシュー／PR の形式例
  • 実際の利用パターン
  • 出力形式の例

設定

環境変数またはプロンプトでデフォルト値を上書きできます。

コア設定：

  • AUDIT_PARALLEL_LIMIT：同時に実行するワークツリーの最大数（デフォルト：8）
  • AUDIT_SEVERITY_THRESHOLD：イシューを作成する最低重大度（デフォルト：medium）
  • AUDIT_MODULE_LOC_LIMIT：この LOC を超えるモジュールを指摘します（デフォルト：300）

フェーズ 3.5 の検証設定［NEW］：

  • AUDIT_PR_SCAN_DAYS：直近の PR をスキャンする日数（デフォルト：30）
  • AUDIT_AUTO_CLOSE_THRESHOLD：自動クローズする信頼度（%）（デフォルト：90）
  • AUDIT_TAG_THRESHOLD：タグを付ける信頼度（%）（デフォルト：70）
  • AUDIT_ENABLE_VALIDATION：フェーズ 3.5 を有効にします（デフォルト：true）

コメント

Markdown 対応