marketplace-health-check

マーケットプレイスのヘルスチェック

並列ファンアウトの動的ワークフローを使用して、この Claude Code スキルのマーケットプレイスリポジトリを包括的かつ証拠に基づいてヘルスチェックします。独立したインスペクターを使って、以下の項目を並行して確認してください。

1. コードとスクリプトの安全性 — 危険な削除、NO-FALLBACK のシークレット漏えい、ハードコードされた実在パス、裸の except、インジェクション、シバンの欠落
2. ドキュメント／SSOT の整合性 — 権威あるドキュメントの確認、リリースポリシーの整合性、参照切れ、派生値のずれ
3. セキュリティ／PII — gitleaks では検出できないキーワードに依存しない漏えい（実名、プライベートドメイン）、一般的なシークレットスキャン、ケースファイルの監査
4. オープン PR のトリアージ — すべての PR を分類（マージする価値あり／変更が必要／プロモーションとして却下）
5. オープン issue のトリアージ — 実際のバグとスキルリクエストとプロモーションの分類、および壊れたインストールコマンドのバグクラス
6. マーケットプレイスマニフェストの整合性 — check_marketplace.sh と check_doc_skill_lists.py、孤立項目、スイートへの登録

その後、あなた自身で重大な所見を確認し、優先度順に報告してください。オーケストレーションにはバンドルされたスクリプト（scripts/repo-health-check.workflow.js）を使用してください。このファイルに実行方法と結果の解釈方法が記載されています。

ワークフローを使う理由 — そしてインラインで実行しなければならない理由

各項目は互いに独立しているため、複数のエージェントに並列に割り当てることで、1つのエージェントが順番にすべてを確認するよりはるかに高速になります。また、各インスペクターは専用の構造化出力を使い、1つの懸念事項に集中できます。

ファンアウトの前に、スクリプトで明示されている最大タスク予算と実行時の拒否条件を使用してください。インスペクターを追加したり予算を変更したりする前に、使用コストを確認してください。現在の項目数から上限を算出しないでください。

このスキルはインラインで実行する必要があります（context: fork は使用しないでください）。 このスキルは Workflow ツールを介して並列エージェントをオーケストレーションしますが、フォークされたサブエージェントはサブエージェントを起動したり、ワークフローを開始したりできません。フォークして実行すると、ファンアウトが気付かれないまま機能しなくなります。また、Workflow ツールを使うにはユーザーによる明示的な許可が必要です。「ヘルスチェックを実行して」というユーザーの依頼はその許可に当たるため、そのまま進めてください。

実行方法

ステップ 1 — 現在の規模を調査し、結果をすべてのインスペクターと共有する

ワークフロースクリプトは args オブジェクトを受け取るため、各エージェントが個別に規模を調べ直すことなく、全エージェントが正確なスナップショットを共有できます。以下を収集します。

このスキルのインストール先／ソースディレクトリを <health-skill-dir> として解決し、選択したリポジトリのルートを確認してから、次を実行します。

python3 "<health-skill-dir>/scripts/scout_repository.py" --repo "<owner/name>" --root "<repo-root>"

ヘルパーの JSON と終了ステータスを確認してください。出力と終了ステータスの仕様は、ヘルパーの --help が正となります。このヘルパーはマニフェストのメタデータを JSON として解析し、PR と issue についてはgithub-ops の GraphQL ページネーション手順に従い、重複を除いた項目数をサーバー上の総数と照合します。完全な出力をソースツリーの外に保存し、インスペクターが参照できるようにしてください。その正確なパスと簡潔な対象範囲の要約を scale に含めます。インスペクターがインストール済みバンドルを解決できない場合は、ヘルパーの絶対パスも指定してください。インベントリの取得に失敗した場合も部分的な項目は not_checked として保持し、その項目を ALL として報告したり、リクエストの失敗をゼロ件として報告したりしないでください。後続のインスペクターは、同じヘルパーを使って該当する未取得のインベントリを補完し、新たに検証された結果を使用できます。

公開リリースに関する PII の判断を適用する前に、identity.isPrivate: false を確認してください。公開状態が取得できない場合、その判断は不明のままにします。対象がプライベートの場合は、実際のプライバシー境界を適用してください。調査を準備済みに見せるために、アカウント、権限、またはグローバル設定を変更しないでください。

Step 2 — ワークフローを起動する

同梱スクリプトを読み込み、その内容を渡して script パラメーターを使い、インラインで起動します（スキルのインストール場所に依存しません）。

Workflow({
  script: <full contents of scripts/repo-health-check.workflow.js>,
  args: { repo: "<owner/name>", scale: "<one-line summary from Step 1>" }
})

これによりモデルの並列処理が起動し、現在のプランの使用量を消費することをユーザーに伝えてください。固定の所要時間やトークン数を保証として提示しないでください。ホスト側の実際の権限ゲートは維持してください。保存済みスクリプトを編集する前に、利用可能であれば Claude Code の /workflow-authoring 同梱 Skill を読み込んでください。ホストの前提条件とスクリプトの制限については、公式の Workflow 契約を参照してください。

起動と完了を区別してください。最初の error は、実行によって監査結果が生成されなかったことを意味します。async_launched は起動を確認しただけです。その実行の最終完了イベントを待ち、返されたレポートを確認してください。失敗、キャンセル、または Workflow ツールを利用できない場合は、監査が未完了であることと、不足している前提条件を報告してください。起動確認やスカウトを、完了した監査として扱ってはいけません。

最終ペイロードは { complete, checks: [...] } です。予想される各ディメンションにつき 1 行を維持し、dimension、status（checked / not_checked）、既存の health、summary、findings[]、stats フィールドを保持してください。complete は、重大な欠陥の報告も含め、すべてのディメンションのレポートが完了したことを意味します。リポジトリの状態が健全であることを意味するものではありません。インスペクターが見つからない、失敗した、または無効な場合は、health: needs-attention を設定した空の not_checked プレースホルダーにしてください。スキーマ上有効な部分レポートでは、同じ保守的なヘルス値を維持しつつ、調査結果と統計を残してください。リポジトリ全体の健全性は未確定であることを説明してください。網羅性が不完全でも、すでに確認された調査結果を取り下げてはいけません。通常どおり、重大度別に反証レビューを行い、報告してください。

実行中はほかの有用な準備を行えますが、インスペクターが読み取り中のファイルの編集は開始しないでください。

Step 3 — 報告する前に重大な調査結果を反証レビューする

エージェントの調査結果は結論ではなく仮説です。決してそのまま伝えてはいけません。 high / critical の調査結果はすべて、簡単なコマンドで自分でも確認してください。漏えいした値を grep する、壊れているとされる行を sed -n で表示する、主張された状態を gh repo view で確認するなどして、（a）実際に問題が存在すること、（b）エージェントが指摘した場所にあること、（c）誇張された指摘ではないことを確かめてください。こうすることで、誤検知だけでなく、実際には誤りであるエージェントの推奨事項も見つけられます。（このスキルの基になったセッションでは、セキュリティインスペクターが実際の非公開ドメインを公開 .gitleaks.toml に追加するよう推奨しました。これは避けるべき対応として却下する必要がありました。手法の参照先を参照してください。）

すべての調査結果を、次の質問でふるいにかけてください。発生確率（本当に起こるのか）、コスト（修正する場合と無視する場合のコスト）、実際のシナリオ（実運用で問題になるのか）、検証可能性（1 行のコマンドで確認または反証できるのか）。

レポート形式

まず表を示し、その後、優先度順に内容を重ねてください。分類して報告し、調査結果をそのまま羅列しないでください。

• 一行の判定 + ディメンション表。ステータス、健全性、対象範囲を含め、予想される行をすべて残してください。not_checked の場合は「未チェック」と明記し、不足している証拠と復旧方法を示してください。全体として健全という判定は避けてください
• 🔴 必須対応 — 検証済みの high / critical をそれぞれ、正確な場所と具体的な修正方法を示して記載
• 🟠 バックログ — PR / issue のトリアージ結果と未完了のチェック（対応方針を含む。外部のコントリビューターに影響する場合は明記）
• 🟢 任意対応 — 重要度の低い指摘や情報レベルの小さな指摘を 1 行ずつ記載
• 💡 重要な知見 — 特筆すべきメタレベルの調査結果（ツールの構造的な見落とし、繰り返し発生するバグの種類）

報告する項目にはそれぞれ ✅ 実在 / ⚠️ 一部該当 / ❌ 誤検知 のタグを付けてください。エージェントの生の出力の大半はノイズです。オーナーがまだ把握していない実際のリスクを示すことがあなたの役割であり、オーナーに選別を任せるために生の調査結果を転送することではありません。

判断原則

調査結果を解釈し、修正を提案する際は、以下を適用してください。それぞれの詳細な理由と実際の失敗事例については、references/health-check-methodology.md を参照してください。PII や PR／Issue の調査結果に対応する前に、必ず読んでください。

• 避けるべき対応：PII の漏えいを、実際の値を公開の許可リスト（例：リポジトリ独自の .gitleaks.toml）に列挙して「修正」してはいけません。実際の資産を列挙する公開リスト自体が漏えいになります。値はその場でサニタイズしてください。実際の非公開値に対する検出ルールは、この公開リポジトリではなく、所有者の非公開グローバルガードに設定してください。
• 履歴に関する注意：作業コピーをサニタイズすれば、現在のバージョンはクリーンになりますが、既存の漏えいは git の履歴に残ります。履歴が公開されていることを正直に報告してください。履歴の書き換え（force-push）は、すべてのフォークに影響する別個の高リスクな判断です。促されていない限り、決して実行してはいけません。
• 公開スキャンの証拠：マーカーの解釈と分離スキャンについては、方法論のリファレンスに従ってください。一般的なチェックに加え、サンプルを意味的に読み取ってください。ローカルの記録がないことや、任意の非公開アセットルールがないことは、公開パッケージが未スキャンまたは安全でないことの根拠にはなりません。
• リリースと貢献に関する判断：最新の リリース責任者のガイド と CONTRIBUTING.md を読んでください。変更の分類、登録済みプラグインの識別情報、メンテナーのフォローアップ規則を適用してください。メンバー向けのバージョンを独自に作成したり、すべての貢献者にメンテナー向けの事務処理を求めたりしてはいけません。外部からの PR のマージには、人間である所有者の判断が必要です。
• プロモーションは原則として辞退：サードパーティのディレクトリ／ツール／マーケットプレイスへの掲載を促す PR や Issue は辞退してください。このリポジトリは個人がキュレーションするマーケットプレイスであり、エコシステムのディレクトリではありません。辞退ポリシーのテンプレートは、リポジトリのルートにある参考ドキュメントです（このスキルのバンドル外）。

同梱リソース

• scripts/repo-health-check.workflow.js — 並列調査を行う Dynamic Workflow です。Workflow ツールの script パラメーターから実行してください（ステップ 2）。調査項目を追加または廃止する場合は、これを編集してください。
• scripts/scout_repository.py — 読み取り専用の JSON スカウトです。引数と終了時の動作については、--help を参照してください。
• references/health-check-methodology.md — Counter-Review、プライバシー、分離スキャンの処理、貢献ポリシーの解釈について説明しています。
• tests/test_health_check.py — スカウトと Workflow 本文の契約を検証する決定的なテストです。python3 -m unittest discover -s "<health-skill-dir>/tests" -v で実行してください。このテストは、ネイティブの Workflow 実行やモデルによる判断の代わりにはなりません。

次のステップ

未解決の調査範囲も含め、読み取り専用のレポートを提出してください。ユーザーがすでに許可した範囲内でのみ修正を続けてください。リポジトリへの書き込み、外部へのコメント、サードパーティによるマージ、履歴の書き換えについて許可が不足している場合は、追加の許可を得てください。監査の依頼だけでは、これらの操作は許可されていません。