mcpField
F
frontend-review-weekly

frontend-review-weekly

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

frontend-review-weekly について

定期的な AI コードレビューを行うチーム向けの、フロントエンド週次レビュー用オーケストレーターです。レビュー用スキルを調整し、KPI の変化や反復する指摘を追跡して、ソースコードを変更せずにレポートを作成します。

主な機能

  1. 01レビュー用スキルの順次実行
  2. 02複数視点レビューの並列実行
  3. 03KPI の比較と段階的な更新
  4. 04反復する指摘の検出
  5. 05GitHub issue とルールの提案
  6. 06エコシステム動向の監視

活用シーン

  1. 01週次のフロントエンド品質レビュー
  2. 02KPI ベースラインとの回帰追跡
  3. 03反復する指摘のルール化提案

インストール

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

$npx skills add https://github.com/mizchi/skills --skill frontend-review-weekly

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

同梱ファイルREADME.md

詳細

フロントエンドレビュー — 週次オーケストレーター

週次の AI レビューを実行しています。新たな判断を下すことではなく、以下を行います。

  1. すべての frontend-review-* スキルを正しい順序で再実行します。
  2. 5 つの視点別サブスキルを並列で実行します。
  3. KPI を先週のベースラインと比較します。
  4. 繰り返し見つかった問題について、GitHub イシューを起票します。
  5. 3 週以上連続して見られるパターンについて、静的ルールへの昇格を提案します。

手順

フェーズ 1：生データの収集

次の順序で実行します。

  1. frontend-review-triage
  2. frontend-review-ci
  3. frontend-review-hygiene
  4. frontend-review-deps
  5. frontend-review-testing
  6. frontend-review-security

これらはそれぞれ <client-repo>/.frontend-review/report/latest/ に書き込みます。

フェーズ 1.5：アーキテクチャレビュー（問題が疑われる場合に実行）

必要に応じて実行するか、新しいエンゲージメントの初回週次レビューでは必ず実行します。

  1. frontend-review-state
  2. frontend-review-performance

これらは <client-repo>/.frontend-review/report/latest/md/ に書き込みます。

フェーズ 2：視点別レビュー（並列）

dispatching-parallel-agents スキルを使って、5 つの視点別スキルを並行して実行します。それぞれが生の JSON を読み取り、視点ごとの Markdown レポートを作成します。

  • frontend-expert
  • react-expert
  • performance-expert
  • security-expert
  • frontend-ops-expert
フェーズ 3：KPI の差分確認とラチェット

<client-repo>/.frontend-review/report/latest/raw/*.json を <client-repo>/.frontend-review/kpi/baseline.json と比較します。次の項目にフラグを立てます。

  • 悪化（望ましくないもの）— 次回の週次レビューまでに必ず修正します
  • 改善（望ましいもの）— ベースラインを更新します（ラチェットが厳しくなります）
フェーズ 4：繰り返し見つかった問題の検出

今週の指摘を、直近 2 件の report/weekly-*.md ファイルと比較します。3 週すべてに現れる指摘は、静的ルールへの昇格候補です。チェックを自動化するための eslint/biome カスタムルール、codemod、または CI ゲートを提案します。これらの提案は <client-repo>/eslint-rules/proposals/<rule-name>.md に書き込みます（必要に応じてディレクトリを作成します）が、実装はしないでください。実装は別のエンジニアリングタスクです。

フェーズ 5：レポート

<client-repo>/.frontend-review/report/weekly-$(date +%Y-w%V).md に次の内容を書き込みます。

  • KPI 差分テーブル（カテゴリ別）
  • 悪化（修正必須）
  • 改善（ラチェットの更新）
  • 視点別の概要（各視点につき 1 段落）
  • 静的ルールへの昇格（提案へのリンク）
  • 起票したイシュー（gh issue create の出力）

傾向のモニタリング

KPI の差分確認と並行して、エコシステムの変化を早期に検出するため、毎週のサイクルで以下の外部シグナルを確認します。

モニタリング対象
ソース頻度確認する内容
jser.info毎週（日曜公開）プロジェクトの依存関係に影響する主要リリース、RFC、破壊的変更、セキュリティ勧告
State of JS（毎年、約 12 月）年次使用状況／満足度の傾向。満足度が 2 年連続で低下した場合は、切り替えのきっかけとします
State of CSS（毎年）年次CSS の採用傾向、Tailwind／CSS-in-JS に対する評価
JavaScript Rising Stars（毎年、約 1 月）年次GitHub スターの増加。新たなツールの早期シグナル
公式リリースブログリリース時プロジェクトの直接の依存関係（フレームワーク、バンドラー、テストランナー、リンター、TypeScript）の主要リリースを追跡

週次レビューでは、WebFetch で https://jser.info/ にアクセスし、package.json に記載されているパッケージへの言及を確認します。関連する情報があれば、エコシステムのシグナルという見出しの下に記載します。

切り替えのトリガー

次の条件のいずれか2つを満たした場合は、ツールの置き換えを検討することを推奨します。

  1. State of JS / State of CSS の満足度スコアが2年連続で低下している。
  2. 過去6か月間にメジャーリリースがなく、GitHub のイシューが増加傾向にある。
  3. メンテナーの離脱または非推奨の告知が報告された。
  4. 明らかに優れた代替ツールが存在する：機能が同等で、パフォーマンスまたは DX が大幅に向上し、現実的な移行経路がある。

AI と人間の責任分担

AI が人間の事前承認なしで実施できること：

  • 自動修正可能な lint / typecheck エラーの修正
  • 既存のパターンに対するテストカバレッジの拡充
  • 依存関係のバージョン更新（lint とテストの通過後）

人間が判断する必要があること：

  • テスト失敗のトリアージ：仕様、実装、テストのどれが誤っているか？
  • ライブラリの新規追加または削除
  • アーキテクチャの境界の変更（新しい状態管理レイヤー、新しいルーティングパターン、新しい非同期境界）
  • アプリの動作を変える変更（単なる実装方法の変更ではないもの）

人間の判断が必要な領域に踏み込んでいると思われる AI 生成 PR は、週次レポートで報告してください。

境界

  • 時間が足りない場合でも、Phase 1 のドメインスキルを省略しないでください。
  • クライアントリポジトリのソースコードを変更しないでください。
  • 回帰が発生した場合、kpi/baseline.json を黙って更新しないでください。改善があった場合にのみ更新してください。

参考資料

  • チェックリスト：11-ai-review.md、13-kpi-tracking.md
  • フェーズ：week-4-ai-review.md、ongoing.md
  • 関連スキル：すべての frontend-review-* に加え、frontend-expert、react-expert、performance-expert、security-expert、frontend-ops-expert
  • 外部スキル：superpowers:dispatching-parallel-agents

コメント

Markdown 対応