プラットフォームスイープ — フルプラットフォームヘルスチェック + 修正パイプライン

5 つの並列監査トラックを実行し、結果を 1 つの優先度付きレポートに統合し、ユーザー承認後、すべての問題を並列 git ワークツリーで自動的に修正するメタオーケストレータです。

設計原則：再発明するな、構成する

このスキルは、可能な限り検証済みの既存スキルに処理を委譲します。既存スキルでカバーできない場合にのみカスタムエージェントを追加します。これにより、スキルは保守しやすく、サブスキルの改善から自動的に恩恵を受けられます。

トラック	プライマリ委譲	カスタム補足
UX 監査	/fulltest-skill	Lighthouse スコア
コード整理	/codebase-cleanup	インライン無効コードスキャン
セキュリティレビュー	/cto (セキュリティスコープ)	--
依存関係監査	/tech-audit	--
パフォーマンスレビュー	/cto (パフォーマンススコープ)	Lighthouse パフォーマンスメトリクス

---

セッション状態と再開性

アクティベーション時は、常に既存の状態をまず確認してください：

cat .platform-sweep-state.json 2>/dev/null

状態ファイル形式

{
  "feature": "Platform Sweep",
  "startedAt": "ISO-8601",
  "currentPhase": "audit|consolidate|approval|fix|verify|complete",
  "config": {
    "url": "auto-detect|<url>",
    "tracks": ["ux", "cleanup", "security", "deps", "performance"],
    "fixMode": "auto|manual|report-only",
    "merger": "git-merge|gh-pr"
  },
  "audit": {
    "trackA_ux": {
      "status": "pending|running|complete|skipped|failed",
      "reportPath": null
    },
    "trackB_cleanup": {
      "status": "pending|running|complete|skipped|failed",
      "reportPath": null
    },
    "trackC_security": {
      "status": "pending|running|complete|skipped|failed",
      "reportPath": null
    },
    "trackD_deps": {
      "status": "pending|running|complete|skipped|failed",
      "reportPath": null
    },
    "trackE_performance": {
      "status": "pending|running|complete|skipped|failed",
      "reportPath": null
    }
  },
  "consolidation": {
    "status": "pending|complete",
    "reportPath": null,
    "totalFindings": 0,
    "bySeverity": { "P0": 0, "P1": 0, "P2": 0, "P3": 0 }
  },
  "approval": {
    "status": "pending|approved|partial|rejected",
    "approvedTracks": [],
    "approvedAt": null
  },
  "fix": {
    "groups": {},
    "status": "pending|running|complete"
  },
  "merge": {
    "status": "pending|running|complete|failed",
    "mergedGroups": [],
    "verifyPassed": false
  }
}

再開ロジック

IF .platform-sweep-state.json が存在:
  状態を読み込む
  IF currentPhase == "audit" → 監査を再開（完了したトラックをスキップ）
  IF currentPhase == "consolidate" → 統合を再実行
  IF currentPhase == "approval" → レポートを改めて承認用に提示
  IF currentPhase == "fix" → 修正を再開（完了したグループをスキップ）
  IF currentPhase == "verify" → 検証 + マージを再開
  ユーザーに通知: "プラットフォームスイープを {phase} から再開しています。{context}。"
ELSE:
  フェーズ 0 から新規開始

すべてのチェックポイントで状態を更新します。すべてのコミットを fix.groups[name].commits に追跡し、/revert-track で潜在的にリバートします。

---

フェーズ 0：設定とプリフライトチェック

0.1 引数をパース

--url <url>           UX/Lighthouse トラック用のサイト URL（デフォルト：自動検出）
--tracks <list>       カンマ区切り：ux,cleanup,security,deps,performance（デフォルト：all）
--fix-mode <mode>     auto | manual | report-only（デフォルト：auto）
--merger <method>     git-merge | gh-pr（デフォルト：git-merge）

0.2 環境検出

# プロジェクトタイプを検出
ls package.json pyproject.toml go.mod Cargo.toml 2>/dev/null

# 利用可能なブラウザツールを検出
~/.local/bin/browse status 2>/dev/null && echo "browse:available" || echo "browse:unavailable"

# 実行中の開発サーバーを検出（UX トラック用）
curl -s -o /dev/null -w "%{http_code}" http://localhost:3000 2>/dev/null
curl -s -o /dev/null -w "%{http_code}" http://localhost:5173 2>/dev/null
curl -s -o /dev/null -w "%{http_code}" http://localhost:8000 2>/dev/null

# デプロイスキルを検出
ls ~/.claude/skills/deploy-*/SKILL.md 2>/dev/null

# git 状態を確認
git status --short
git stash list

0.3 URL 解決

--url が auto-detect の場合：

1. 開発サーバーが既に実行されているか確認（localhost:3000, 5173, 8000, 4200, 8080 をプローブ）
2. 実行されていない場合、package.json スクリプトで dev/start/serve コマンドを確認
3. 見つかった場合、ユーザーに尋ねる："開発サーバーが検出されません。{command} で起動しますか？ [Y/n]"
4. Web プロジェクトが検出されない場合、トラック A（UX）と Lighthouse 補足をスキップ

0.4 設定カード

ユーザーに提示してから進めます：

/platform-sweep -- Configuration
---
トラック:        [ux] [cleanup] [security] [deps] [performance]
URL:           http://localhost:3000 (自動検出)
修正モード:      auto (承認後に修正)
マージ方法:      git-merge
プロジェクトタイプ: Node.js + TypeScript (Next.js)
ブラウザ:        browse CLI 利用可能
デプロイスキル:   /deploy-staging 検出

推定時間: 5-10 分（監査）+ 3-5 分（修正）
推定コスト: 約 $7-12 合計

[1] 進める
[2] 設定を変更
[3] トラックをスキップ（どのトラックか指定）

ユーザー確認を待ちます。agent-spawned コンテキストでは、プロンプトをスキップしてデフォルトで進めます。

---

フェーズ 1：並列監査

すべての選択されたトラックを同時に起動します。まず作業ディレクトリを作成してください：

mkdir -p .platform-sweep

トラック A：UX 監査

委譲： Skill ツール経由で /fulltest-skill を呼び出します。

Skill(skill="fulltest-skill", args="<url> --report-only")

fulltest-skill は agent-spawned コンテキストで実行されます（最小限の詳細度、構造化出力）。以下を実行します：

• すべてのページをマップ
• コンソールエラー、ネットワーク障害、リンク切れ、CSS 問題をテスト
• 構造化結果を返す

補足 — Lighthouse 監査：

ブラウザツールが利用可能な場合、メイン URL と最大 3 つの主要ページで Lighthouse を実行します：

# プライマリ: Chrome DevTools MCP
mcp__chrome-devtools__lighthouse_audit(url="<url>", categories=["performance", "accessibility", "seo", "best-practices"])

# フォールバック: browse CLI
browse goto "<url>"
browse lighthouse --categories performance,accessibility,seo,best-practices

結合結果を .platform-sweep/track-a-ux.md に書き込みます：

# トラック A：UX 監査

## ブラウザテスト（/fulltest-skill 経由）

[fulltest-skill の構造化結果をペースト]

## Lighthouse スコア

| カテゴリ       | スコア | 主要な問題                                |
| ----------- | ---- | -------------------------------------- |
| Performance | 72   | 大きな画像、レンダリングブロック CSS    |
| Accessibility | 89 | 不足している alt テキスト (3)、低コントラスト (1) |
| SEO         | 95   | /blog にメタディスクリプションなし      |
| Best Practices | 85 | コンソールエラー、非推奨 API 使用       |

## 結果

[正規化された結果リスト：重要度 | ページ | 問題 | 推奨事項]

モデルティア： fulltest-skill は独自のティアを使用（Sonnet オーケストレータ、Haiku テスター）。Lighthouse 補足はオーケストレータでインライン実行されます。

スキップ条件： URL が利用可能でなく、開発サーバーを起動できない場合、このトラックをスキップして、レポートに注記します。

---

トラック B：コード整理

委譲： Skill ツール経由で /codebase-cleanup を呼び出します。

Skill(skill="codebase-cleanup", args="<project-root>")

codebase-cleanup スキルは agent-spawned コンテキストで実行されます。以下を実行します：

• 孤立したファイル、一時/バックアップファイル、空のファイル、重複をスキャン
• 信頼度ティア（high/medium/low）でレポート

補足 — インライン無効コードエージェント（Sonnet）：

スキル呼び出しと並列で Sonnet サブエージェントを起動します：

Agent(model="sonnet", prompt="""
ソースコードのインライン無効コードをスキャンしてください。テストファイル、node_modules、dist、build、.git は除外してください。

チェック対象：
1. console.log / console.debug / console.warn（非テストソースファイル内）
   - grep -rn "console\.\(log\|debug\|warn\)" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" --exclude-dir=node_modules --exclude-dir=dist --exclude-dir=build --exclude-dir=__tests__ --exclude-dir=test
   - catch ブロック内の行を除外（正当なエラーログ）

2. TODO / FIXME / HACK / XXX コメント
   - grep -rn "TODO\|FIXME\|HACK\|XXX" --include="*.ts" --include="*.tsx" --include="*.py" --include="*.js" --exclude-dir=node_modules --exclude-dir=.git

3. コメントアウトされたコードブロック（コードのように見える 3 行以上の連続コメント）
   - パターンを探す：// で始まる連続行がコード構文（=、()、{}、;、import、export、function、const、let、var、if、for、while、return）を含む

4. 未使用のインポート（TypeScript の場合）：
   - ファイル内で参照されていないインポートをチェック

結果フォーマット（結果ごと）：
重要度 | ファイル:行 | カテゴリ | コンテンツ | 推奨事項

重要度ガイド：
- P2: 本番コード内の console.log
- P3: TODO/FIXME コメント（情報提供）
- P2: コメントアウトされたコードブロック
- P1: 未使用のインポート（潜在的なビルド問題）

レポートを .platform-sweep/track-b-inline.md に書き込み
""")

両方のレポートを .platform-sweep/track-b-cleanup.md にマージします。

モデルティア： codebase-cleanup = Sonnet。インラインスキャンエージェント = Sonnet。

---

トラック C：セキュリティレビュー

委譲： Agent ツール経由でセキュリティ専用スコープで /cto を呼び出します。

Agent(model="opus", prompt="""
あなたはプラットフォームスイープのセキュリティ専用モードで CTO スキルとして実行しています。

このコードベースの焦点を絞ったセキュリティレビューを実行してください。/cto スキルからのセキュリティアナリスト
チェックリストに正確に従ってください：

- 認証 & 認可：認証フロー、バイパスの確認、RBAC サーバー側検証、
  大量割り当て、IDOR
- インジェクション & 入力処理：SQL インジェクション、ヘッダーインジェクション、ログインジェクション、パストトラバーサル
- タイミング & 暗号化：タイミング攻撃、定時間比較、弱いプリミティブ、JWT 検証
- API セキュリティ：認証エンドポイントのレート制限、API レイヤーの大量割り当て、SSRF、HTTP セキュリティヘッダー
- シークレット & 設定：ハードコードされた認証情報、.env in git、ログ内のシークレット
- エージェントシャシーセキュリティ（AI 統合の場合）：シークレットインジェクション、トラスト境界、監査ログ

また依存関係脆弱性チェックも実行してください：
- npm audit / pip-audit / cargo audit（適用可能なものを使用）
- 直接依存関係の既知 CVE をチェック

レポートフォーマット：
重要度 (P0/P1/P2) | ファイル:行 | カテゴリ | 問題 | 推奨事項

P0 = 悪用可能な脆弱性（認証バイパス、インジェクション、シークレット露出）
P1 = セキュリティ弱点（レート制限の欠落、弱い暗号化、ヘッダー欠落）
P2 = セキュリティ衛生（TODO セキュリティアイテム、軽微な設定問題）

レポートを .platform-sweep/track-c-security.md に書き込み
""")

モデルティア： Opus — セキュリティレビューは model-tier-strategy あたりの深い推論が必要です。

---

トラック D：依存関係監査

委譲： Skill ツール経由で /tech-audit を呼び出します。

Skill(skill="tech-audit", args="critical")

critical モードの tech-audit スキルは EOL/セキュリティ問題に焦点（最速モード）。以下を実行します：

• すべてのパッケージマニフェストをスキャン
• Sonnet リサーチエージェントを起動して、Web 検索で現在のバージョンを確認
• 重要度ティアと更新ウェーブでレポート

スキルは独自のレポート（TECH-AUDIT-{YYYY-MM}.md）を書き込みます。完了後、関連結果を .platform-sweep/track-d-deps.md に正規化形式でコピーします。

モデルティア： tech-audit は Opus オーケストレータ + Sonnet リサーチエージェント（ネイティブティア）を使用。

---

トラック E：パフォーマンスレビュー

委譲： Agent ツール経由でパフォーマンス専用スコープで /cto を呼び出します。

Agent(model="sonnet", prompt="""
あなたはプラットフォームスイープのパフォーマンス専用モードで CTO スキルとして実行しています。

このコードベースの焦点を絞ったパフォーマンスレビューを実行してください：

- データベース：N+1 クエリ、インデック欠落、最適化されていないクエリ、接続プール設定
- キャッシング：キャッシュレイヤー欠落、キャッシュ無効化問題、静的アセットキャッシング
- バンドル：大きな依存関係、ツリーシェイク機会、コード分割ギャップ
- API：遅いエンドポイント、ページングの欠落、無制限クエリ、圧縮の欠落
- メモリ：メモリリーク、大きなオブジェクト保持、エフェクト/リスナー内のクリーンアップ欠落
- 並行処理：メインスレッドのブロック操作、欠落している async/await、ワーカー機会

レポートフォーマット：
重要度 (P1/P2/P3) | ファイル:行 | カテゴリ | 問題 | 推奨事項 | 推定影響

P1 = 測定可能なユーザー向け影響（遅いページロード、タイムアウトリスク）
P2 = スケーラビリティの懸念（負荷下で低下）
P3 = 最適化の機会（あると良い）

レポートを .platform-sweep/track-e-performance.md に書き込み
""")

補足 — Lighthouse パフォーマンスメトリクス：

URL が利用可能で Lighthouse がトラック A で実行された場合、パフォーマンス固有のメトリクス（LCP、FID、CLS、TTFB）を抽出してパフォーマンストラックレポートに追記します。Lighthouse を再実行しないでください — トラック A の結果を再利用してください。

モデルティア： Sonnet — パフォーマンスレビューは判断作業であり、アーキテクチャ決定ではありません。

---

並列実行戦略

すべての 5 つのトラックを同時に起動します。Task ツールをバックグラウンド実行で使用：

# すべてのトラックを並列起動
TaskCreate(description="トラック A：UX 監査", ...)         # run_in_background
TaskCreate(description="トラック B：コード整理", ...)      # run_in_background
TaskCreate(description="トラック C：セキュリティレビュー", ...)   # run_in_background
TaskCreate(description="トラック D：依存関係監査", ...)  # run_in_background
TaskCreate(description="トラック E：パフォーマンスレビュー", ...) # run_in_background

Monitor を使用して完了を監視：

Monitor(
  description: "プラットフォームスイープトラック完了監視者",
  timeout_ms: 600000,
  persistent: false,
  command: '''
    while true; do
      complete=0
      total=0
      for track in a-ux b-cleanup c-security d-deps e-performance; do
        total=$((total + 1))
        [ -f .platform-sweep/track-${track}.md ] && complete=$((complete + 1)) && echo "TRACK_COMPLETE: ${track}"
      done
      [ "$complete" -eq "$total" ] && echo "ALL_TRACKS_COMPLETE" && exit 0
      sleep 3
    done
  '''
)

各トラック完了後に状態を更新します。

---

フェーズ 2：統合

すべてのトラックが完了後、オーケストレータは結果を統合します。

2.1 すべてのトラックレポートを読み込み

cat .platform-sweep/track-a-ux.md
cat .platform-sweep/track-b-cleanup.md
cat .platform-sweep/track-c-security.md
cat .platform-sweep/track-d-deps.md
cat .platform-sweep/track-e-performance.md

2.2 正規化と重複排除

各トラックの結果を統一された構造にパース：

{
  id: "finding-001",
  severity: "P0|P1|P2|P3",
  tracks: ["security", "performance"],  // 複数トラックにまたがる可能性
  file: "src/api/auth.ts",
  line: 45,
  category: "auth-bypass|injection|dead-code|outdated-dep|perf-bottleneck|...",
  issue: "問題の説明",
  recommendation: "修正方法",
  fixGroup: "security|cleanup|deps|performance|ux",
  effort: "low|medium|high"
}

重複排除ルール：

• 同じファイル + 同じ行 + 重複する問題の説明 = 1 つに統合、すべての関連トラックでタグ付け
• セキュリティ（CVE）と deps（期限切れ）の両方でフラグ付けられた同じ依存関係 = 統合、最高の重要度を使用
• ファイルが複数の修正グループに現れる場合、最高の重要度グループに割り当て（ファイルの所有権は ワークツリー分離のため排他的でなければならない）

2.3 統合レポートを書き込み

プロジェクトルートに PLATFORM-SWEEP-{YYYY-MM-DD}.md を書き込み：

# プラットフォームスイープレポート

**日付：** {date}
**プロジェクト：** {project-name}
**トラック：** {実行されたトラック}
**期間：** {total-time}

## エグゼクティブサマリー

| 重要度      | 数量   | トラック         |
| --------- | ----- | -------------- |
| P0 (致命的) | {n}   | {どのトラック} |
| P1 (高)   | {n}   | {どのトラック} |
| P2 (中)   | {n}   | {どのトラック} |
| P3 (低)   | {n}   | {どのトラック} |
| **合計**   | **{n}** |                |

## 致命的な結果（P0）— すぐに修正してください

{重要度でソートされ、トラック別グループ化された結果}

### セキュリティ

| # | ファイル | 問題 | 推奨事項 |
| - | ---- | ----- | -------------- |

### UX

| # | ファイル/ページ | 問題 | 推奨事項 |
| - | --------- | ----- | -------------- |

## 優先度の高い結果（P1）— このスプリントで修正してください

{同じテーブル形式}

## 中優先度（P2）— このクォーターで修正してください

{同じテーブル形式}

## 低優先度（P3）— バックログ

{同じテーブル形式}

## 依存関係ステータス

| パッケージ | 現在のバージョン | 最新 | 重要度 | CVEs | アクション |
| ----- | ------- | ------ | -------- | ---- | ------ |

## Lighthouse スコア（利用可能な場合）

| ページ | Performance | Accessibility | SEO | Best Practices |
| ---- | ----------- | ------------- | --- | -------------- |

## 修正計画

承認された場合、修正は並列ワークツリーで適用されます：

| 修正グループ       | 結果 | ファイル   | 推定作業量 |
| --------------- | -------- | ------- | -------- |
| fix/security    | {n}      | {files} | {effort}  |
| fix/cleanup     | {n}      | {files} | {effort}  |
| fix/deps        | {n}      | {files} | {effort}  |
| fix/performance | {n}      | {files} | {effort}  |
| fix/ux          | {n}      | {files} | {effort}  |

ファイル所有権は排他的です — 2 つの修正グループが同じファイルに触れません。
統合順序：security > deps > performance > cleanup > ux。

2.4 クロストラックインサイト

結果ごとのレポートを書き込んだ後、クロストラックインサイトセクションを追加：

• システム的パターン： 3 つ以上のファイルに現れる同じ問題タイプ（例えば、すべての API ルートで入力検証が欠落）
• 根本原因チェーン： パフォーマンス機会による引き起こされたセキュリティ問題（例えば、速度のため認証チェックをスキップ）、またはバグを隠している無効コード
• アップグレードチェーン： セキュリティ CVE も修正し、パフォーマンスも改善する依存関係更新

---

フェーズ 3：承認ゲート（ハードゲート）

ユーザーが明示的に承認するまで、フェーズ 4 に進まないでください。

統合レポートの要約を提示して尋ねます：

プラットフォームスイープが完了しました。{total} 個の問題が見つかりました（{P0} 個が致命的、{P1} 個が高優先度、{P2} 個が中、{P3} 個が低）。

完全なレポート：PLATFORM-SWEEP-{date}.md

オプション：
[1] すべて修正 — すべての修正を並列ワークツリーで適用
[2] 選択的に修正 — どの修正グループを実行するかを選択
[3] レポートのみ — 修正は手動で対応します
[4] トラックを再実行 — 別のスコープで特定のトラックを再監査

fix-mode が report-only の場合、このゲートをスキップしてフェーズ 2 後に終了します。

fix-mode が manual の場合、レポートを提示して終了します。

fix-mode が auto の場合、レポートを提示して承認を待ちます。ユーザーが「approve」、「fix all」、「go」と言うか、オプション 1/2 を選択した場合にのみ進めます。

オプション 2 の場合、どのグループか尋ねます："どの修正グループですか？[security, cleanup, deps, performance, ux]"

---

フェーズ 4：ワークツリーでの並列修正

4.1 ワークツリーを作成

承認された修正グループごとに、分離された git ワークツリーを作成：

# 作業ツリーがきれいであることを確認
git stash --include-untracked -m "platform-sweep: 修正前にスタッシュ"

# ワークツリーを作成
git worktree add .worktrees/fix-security -b fix/security
git worktree add .worktrees/fix-cleanup -b fix/cleanup
git worktree add .worktrees/fix-deps -b fix/deps
git worktree add .worktrees/fix-performance -b fix/performance
git worktree add .worktrees/fix-ux -b fix/ux

4.2 修正エージェントを起動

各修正エージェントは、排他的なファイル所有権で独自のワークツリーで動作する Sonnet エージェントです。

修正エージェントテンプレート：

Agent(model="sonnet", prompt="""
あなたはプラットフォームスイープの {group-name} 修正エージェントです。

作業ディレクトリ：{worktree-path}

割り当てられた結果（これらのみを修正）：
{file:line、問題、推奨事項のリスト付き結果}

ファイル所有権：これらのファイルのみを修正できます：
{exclusive-file-list}

他のファイルに触れないでください。他の修正グループがそのファイルを所有しています。

結果ごと：
1. ファイルを読みコンテキストを理解
2. 推奨事項に従って修正を適用
3. 修正が正しいことを確認（新しい問題を引き起こさない）
4. 次の結果へ

すべての結果が修正されたら：
1. このワークツリーで検証トリプルを実行：
   - 型チェック（利用可能な場合）
   - テスト（利用可能な場合）
   - ビルド（利用可能な場合）
2. 検証エラーを修正
3. メッセージですべての変更をコミット：
   fix({group}): {適用された修正の要約}

   プラットフォームスイープ修正：
   - {結果 1 要約}
   - {結果 2 要約}
   ...
4. 完了を報告

修正サマリーを {worktree-path}/.fix-complete.json に書き込み：
{
  "group": "{group-name}",
  "status": "complete|partial|failed",
  "findingsFixed": N,
  "findingsSkipped": N,
  "skippedReasons": ["..."],
  "commit": "sha",
  "verifyResult": "pass|fail"
}
""")

修正グループ固有の指示：

修正グループ	特別な指示
fix/security	既存のセキュリティコントロールを弱めないでください。認証を修正する場合、既存のチェックをすべて保持してください。変更後に npm audit / pip-audit を実行して新しい脆弱性がないか確認してください。
fix/cleanup	ファイル削除の場合、ファイルがゼロインポータを持つことを確認してから削除してください。console.log 削除の場合、catch ブロック内の console.error を保持してください。TODO 解決の場合、TODO が大量の作業を必要とする場合は、それを残して報告に注記してください。
fix/deps	各承認されたパッケージに対して npm update <pkg> または同等のものを実行してください。更新後、完全なテストスイートを実行してください。テストが失敗した場合、その特定の更新をリバートして注記してください。明示的に承認されない限り、メジャーバージョンを更新しないでください。
fix/performance	マイグレーションファイル経由でインデックスを追加し、生の SQL ではなく。適切な TTL でキャッシング追加。API コントラクトを変更しないでください。
fix/ux	CSS/JS 修正のみ。結果で明示的に承認されない限り、コンポーネント構造またはレイアウトを変更しないでください。

4.3 修正完了を監視

Monitor(
  description: "プラットフォームスイープ修正エージェント完了",
  timeout_ms: 600000,
  persistent: false,
  command: '''
    while true; do
      complete=0
      total=0
      for wt in .worktrees/fix-*; do
        [ -d "$wt" ] || continue
        total=$((total + 1))
        [ -f "${wt}/.fix-complete.json" ] && complete=$((complete + 1)) && echo "FIX_COMPLETE: $(basename $wt)"
      done
      [ "$complete" -eq "$total" ] && [ "$total" -gt 0 ] && echo "ALL_FIXES_COMPLETE" && exit 0
      sleep 3
    done
  '''
)

4.4 修正エージェント結果を収集

すべての修正エージェントが完了後、各 .fix-complete.json を読みコンパイル：

修正結果：
- fix/security: 5/5 修正済み、検証：PASS
- fix/cleanup: 12/14 修正済み（2 スキップ：複雑なリファクタリング必要）、検証：PASS
- fix/deps: 8/8 更新済み、検証：PASS（1 メジャーバージョンスキップ）
- fix/performance: 3/3 修正済み、検証：PASS
- fix/ux: 4/4 修正済み、検証：PASS

---

フェーズ 5：検証とマージ

5.1 段階的なマージ

優先度順に修正ブランチをマージします。各マージ後、検証を実行：

マージ順（優先度の高い順）：
1. fix/security
2. fix/deps
3. fix/performance
4. fix/cleanup
5. fix/ux

各グループについて：

# メインにマージ
git merge fix/{group} --no-ff -m "merge: platform-sweep fix/{group}"

# マージ後に検証
# (Skill ツール経由で /verify を呼び出し)

マージ後の検証が失敗した場合：

1. 競合または後退を特定
2. 自動修正を試みる（Sonnet エージェント、最大 2 回試行）
3. 自動修正が失敗した場合、ユーザーに報告して一時停止

merger スロットが gh-pr の場合、直接マージの代わりに各修正グループに対して PR を作成：

git push -u origin fix/{group}
gh pr create --title "fix({group}): プラットフォームスイープ修正" --body "..."

5.2 最終検証

すべてのマージが完了後：

# 完全な検証を実行
Skill(skill="verify")

# ワークツリーをクリーンアップ
git worktree remove .worktrees/fix-security
git worktree remove .worktrees/fix-cleanup
git worktree remove .worktrees/fix-deps
git worktree remove .worktrees/fix-performance
git worktree remove .worktrees/fix-ux

# スタッシュをポップ（早期にスタッシュした場合）
git stash pop 2>/dev/null || true

# 作業ファイルをクリーンアップ
rm -rf .platform-sweep

5.3 オプションのデプロイ

デプロイスキルがフェーズ 0 で検出された場合：

デプロイスキルが検出されました：/deploy-staging
ステージングにデプロイしますか？ [Y/n]

すべての検証チェックが合格し、ユーザーが承認した場合のみデプロイを提供します。

---

フェーズ 6：レポートと完了シグナル

統合レポートを更新

修正結果を PLATFORM-SWEEP-{date}.md に追記：

## 修正結果

| グループ       | 修正された結果 | スキップ | 検証 | マージ |
| ----------- | ---------- | ------ | ---- | ------ |
| security    | 5/5        | 0      | PASS | YES    |
| cleanup     | 12/14      | 2      | PASS | YES    |
| deps        | 8/8        | 0      | PASS | YES    |
| performance | 3/3        | 0      | PASS | YES    |
| ux          | 4/4        | 0      | PASS | YES    |

**合計：34/32 個の結果を修正しました。2 個は遅延（以下の backlog を参照）。**

### 遅延アイテム

| 結果                           | 理由                                   | 推奨アクション          |
| ----------------------------- | ---------------------------------------- | ------------------------- |
| 認証ミドルウェアのリファクタ（P2） | 複雑なリファクタリング、専用スプリント必要 | GitHub issue を作成      |
| React を v20 にアップグレード（P2） | メジャーバージョン、破壊的変更          | マイグレーションを別途計画 |

完了シグナル

{
  "status": "complete|partial|blocked|failed",
  "summary": "プラットフォームスイープ：{N} 個の結果、{M} 個修正済み、{K} 個遅延",
  "phases": {
    "audit": { "tracks": 5, "completed": 5, "duration": "4m 32s" },
    "consolidation": {
      "totalFindings": 34,
      "bySeverity": { "P0": 2, "P1": 8, "P2": 16, "P3": 8 }
    },
    "fix": { "fixed": 32, "skipped": 2, "groups": 5 },
    "verify": "PASS",
    "merge": "complete"
  },
  "reports": ["PLATFORM-SWEEP-{date}.md"],
  "totalDuration": "12m 45s"
}

---

選択的なトラック実行

ユーザーはトラックのサブセットを実行できます：

/platform-sweep --tracks security,deps

トラックをフィルタした場合：

• 選択されたトラックのエージェントのみを起動
• 結果のないフェーズ 4 修正グループをスキップ
• レポートは完全なテンプレートを使用しますが、スキップされたトラックを「監査されていません」とマーク

一般的な組み合わせ：

コマンド	トラック	ユースケース
/platform-sweep	全 5	完全な監査
/platform-sweep --tracks security	C のみ	迅速なセキュリティチェック
/platform-sweep --tracks security,deps	C + D	セキュリティ + 依存関係監査
/platform-sweep --tracks cleanup,performance	B + E	コード健全性パス
/platform-sweep --tracks ux	A のみ	UX 専用監査（URL 必須）
/platform-sweep --fix-mode report-only	全 5	修正なしの監査

---

モデルティア戦略

エージェント	モデル	理由
オーケストレータ（このスキル）	Opus	クロストラック統合、深い推論
トラック A：fulltest-skill	Sonnet + Haiku	サブスキルが独自のティアを使用
トラック B：codebase-cleanup	Sonnet	サブスキルのネイティブティア
トラック B：インラインスキャンエージェント	Sonnet	コードパターンの判断
トラック C：セキュリティレビュー	Opus	セキュリティは深い推論が必要
トラック D：tech-audit	Opus + Sonnet	サブスキルが独自のティアを使用
トラック E：パフォーマンスレビュー	Sonnet	判断作業、アーキテクチャ決定ではない
修正エージェント（全グループ）	Sonnet	コード作成 + 判断
検証（/verify）	Haiku	機械的チェック

---

エラーハンドリング

トラック障害

トラック（サブスキルエラー、タイムアウト、ブラウザ利用不可）が失敗した場合：

1. 状態に障害をログ
2. 残りのトラックを続行
3. レポートで失敗したトラックを「失敗 — エラーを参照」とマーク
4. 他のトラックをブロックしない

修正エージェント障害

修正エージェントが失敗した場合：

1. .fix-complete.json から部分的な結果をログ（書き込まれた場合）
2. どの結果が未修正かを報告
3. 他のグループのマージを続行
4. 失敗したグループの再試行を提供

マージ競合

マージが競合した場合：

1. 自動解決を試みる（Sonnet エージェント）
2. 自動解決が失敗した場合、競合を報告してユーザーに尋ねる
3. 強制マージをしない

---

フェーズ 7：スキル結晶化

プロジェクトの最初の成功したスイープの後、プロジェクト固有のスイープスキルを生成して、学習した内容をすべてエンコードします。

なぜか

汎用的な /platform-sweep は、すべての実行でプロジェクト構造、URL、技術スタック、一般的な問題、修正パターンを発見します。結晶化されたスキルはすべての発見をスキップ — プロジェクトを知って、プロジェクト固有の知識をベイクしたスキルで直接監査/修正に進みます。

トリガー

結晶化は、フェーズ 6（検証 + マージ）が正常に完了した後に自動的に実行されます。--no-crystallize でスキップできます。

エンコードされるもの

生成されたスキルはエンコード：

1. プロジェクト識別 — 名前、リポジトリ、技術スタック（フロントエンドフレームワーク、バックエンド言語、DB、インフラ）
2. URL — 本番、ステージング、ローカル開発サーバーコマンド
3. デプロイスキル — どのデプロイスキルを呼び出すか（例：/deploy-full）
4. 既知の問題パターン — このスイープで発見された繰り返しの問題（例：「components/ の console.logs」、「データページでエラー境界がない」）
5. ファイル所有権マップ — どのディレクトリがどのトラックに属するか（例：apps/admin/src/ = フロントエンド、apps/api/src/ = バックエンド）
6. カスタムチェック — 汎用トラックでカバーされていないプロジェクト固有チェック（例：「すべての API ルートが APIResponse ラッパーを使用していることを確認」、「すべてのページがスケルトンローダーを持っていることをチェック」）
7. 除外パス — スキップするディレクトリ（例：node_modules/、.venv/、生成されたファイル）
8. 前回の結果ベースライン — このスイープの問題数。次の実行が delta（新しい問題対解決済み問題）を報告できるため

生成されるスキル構造

~/.claude-setup/skills/platform-sweep-{project}/
  SKILL.md          # プロジェクト固有のスイープスキル

SKILL.md テンプレート

生成されたスキル：

---
name: platform-sweep-{project}
description: "{Project} プラットフォームスイープ — 既知のパターン、URL、デプロイ統合を含むプロジェクト固有のヘルスチェック。{date} に /platform-sweep で生成。"
user-invocable: true
context: fork
model: opus
effort: high
skills: [platform-sweep]
---

本文は以下を含めます：

# プラットフォームスイープ — {Project}

{date} に `/platform-sweep` の実行から自動生成。
親スキル：`/platform-sweep`（すべての汎用ロジックを委譲）。

## プロジェクトプロフィール

| フィールド      | 値                  |
| --------------- | -------------------- |
| 名前            | {project name}       |
| リポジトリ      | {repo URL}           |
| フロントエンド  | {framework + version}|
| バックエンド    | {language + framework} |
| データベース    | {DB type}            |
| デプロイ        | `/{deploy-skill}`    |
| 本番 URL        | {url}                |
| ステージング URL | {url}               |
| 開発サーバー    | `{command}`          |

## 既知の問題パターン

これらのパターンは過去のスイープで発見されました。まず再発生をチェック：

{スイープからのパターンのリスト、例えば：

- 本番コンポーネントに残された console.log
- APIResponse ラッパーが欠落している API エンドポイント
- ExcelJS スタイルの Node.js ライブラリがブラウザバンドルにインポート
- データフェッチングページでエラー境界が欠落
  }

## カスタムチェック（プロジェクト固有）

5 つの汎用トラックに加えて、これらのプロジェクト固有チェックを実行：

{結果から派生、例えば：

- apps/api/src/api/routes/ のすべての新規 API ルートが require_admin_or_manager を使用していることを確認（require_master_admin ではなく）
- apps/admin/src/hooks/api/ のすべてのフロントエンド API フックが正しいベースパスを使用していることを確認（/admin/ ルート以下でない限り /admin/ プリフィックスなし）
- apps/admin/nginx.conf と K8s ConfigMap が同期していることをチェック
  }

## ベースライン（{date}）

| トラック        | 見つかった問題 | 修正済み | 残り |
| --------------- | -------------- | ------- | ---- |
| UX              | {n}            | {n}     | {n}  |
| Cleanup         | {n}            | {n}     | {n}  |
| Security        | {n}            | {n}     | {n}  |
| Dependencies    | {n}            | {n}     | {n}  |
| Performance     | {n}            | {n}     | {n}  |

## 実行方法

このスキルはプロジェクト固有のオーバーライド付きで `/platform-sweep` に委譲：

- URL はプリセット済み（自動検出の必要はない）
- 既知のパターンはまず最初にチェック（より高速な監査）
- カスタムチェックは汎用トラックに加えて実行
- デプロイは自動的に `/{deploy-skill}` を使用

実行するだけ：
/platform-sweep-{project}

命名規約

• 汎用：/platform-sweep
• ExampleProject：/platform-sweep-example
• ProjectB：/platform-sweep-projectb
• ProjectC：/platform-sweep-projectc

進化

プロジェクト固有スキルの後続の各実行：

1. 見つかった結果をベースラインと比較
2. 新しい問題（後退）対解決済み問題（改善）を報告
3. 修正後にベースラインを更新
4. このスイープで発見された新しい既知パターンを追記
5. 新しいプロジェクト固有の問題が見つかった場合、カスタムチェックを更新

これは累積的な知識ループを作成 — 各スイープは次のスイープをより賢くします。

---

ルール

• 承認なしに修正するな — フェーズ 3 は hard gate です（report-only モード以外。これは修正しません）
• 修正フェーズでの排他的なファイル所有権 — 2 つのワークツリーが同じファイルに触れません
• 構成する、再発明するな — 既存スキルに委譲、カスタムエージェントはギャップにのみ
• 優雅な低下 — 前提条件が欠落した場合トラックをスキップ（URL なし = UX をスキップ、ブラウザなし = Lighthouse をスキップ）
• すべてを状態化 — すべてのチェックポイントで .platform-sweep-state.json を更新
• クリーンアップ — 完了後にワークツリーと作業ファイルを削除
• 生成コードで不要なコメントや jsdoc はない
• TypeScript 修正で any または unknown タイプなし
• すべての修正グループ後に検証トリプルを実行 マージ前
• 最初の成功したスイープ後に結晶化 — プロジェクト固有スキルを自動生成
• プロジェクトスキルは複合 — 各実行がパターン、ベースライン、カスタムチェックを更新