ci-score

ci-score

CI Score は、CI の速度とゲートの健全性に関するベストプラクティスへの準拠度を測定します。リポジトリのワークフロー設定から算出する、ベストプラクティスのチェック項目に基づくシンプルな合否基準です。 11 個の設定項目はそれぞれ、リポジトリ内の YAML で 1 分以内に自己検証できます。スコア = 合格したチェック項目数 / 該当するチェック項目数です。例外は 1 つだけで、チェック対象のワークフローがない場合は判定できません。レジストリ： references/ci-score-spec.json（固定版 v0.1.4）。基準の解説： references/ci-score-methodology.md。

このスコアが測定するのは速度ではなく準拠度です。実測でより速いリポジトリでも、スコアが低い場合があります。レポートではこの点をカードの横に明記しています。ユーザーがスコアを速度の評価だと受け取らないようにしてください。また、これはセキュリティ監査でもありません。この基準が評価するのはベストプラクティスであり、11 個のチェック項目のうちセキュリティ関連にあたるのは、アクションのピン留めとジョブ単位の OIDC トークンの 2 つだけです。ワークフローのセキュリティについて、それ以上のことを主張するものではありません。

Requirements

• 対象リポジトリのローカル環境への完全なチェックアウト。 スコアの入力対象は、ワークフロー YAML、ローカルの複合アクション、リポジトリのルートにあるビルドツールの設定ファイルの 3 種類です。そのため、API でワークフローだけを取得するなどの部分的な表示では、スコアが気付かないうちに高くなります。コレクターは git チェックアウトの外では処理を拒否します。自分で行う完全なクローンは有効な方法です（入力対象をすべて含むためです。禁止されているのは部分取得であり、クローンではありません）。ネットワークとディスクを使用するため、クローンする前に確認してください。ユーザーが所有していないリポジトリのスコアは、そのユーザーだけが閲覧できるものとし、公開や共有はしないでください。
• PyYAML（pip install pyyaml）。スクリプトはこれが見つからない場合、その案内を明示して終了します。
• ネットワークアクセスは不要であり、使用しません。すべてローカルのツリーを読み取ります。

Flow

以下のパスはすべて、このスキルのディレクトリからの相対パスです。

操作上の契約（手順 0 と 4）。 ユーザーに提示する 2 つの質問は、どちらも構造化された単一の質問です。つまり、1 つの質問に対して、順序が固定された選択肢を提示し、自由回答形式にはしません。また、仕組みについて説明しません。利用可能なプラットフォームの構造化質問ツールを使ってください。Claude Code では AskUserQuestion、Codex では組み込みのユーザー入力リクエストツール（request_user_input / tool/requestUserInput、実験的機能）を使います。公開されている場合は必ず呼び出してください。ツールが存在しないと予測してプレーンメッセージの分岐に直行したため、この契約ではツールがないと決めつけず、まず確認して呼び出しを試すことになっています。これは、実際の ci-score の Codex 実行で起きたことです。ツールが本当に存在しない場合、または呼び出しに失敗した場合に限り、同じ質問を1 つのプレーンメッセージとして尋ねてください。選択肢と順序は同じにし、終了時の保存オプションは最後に置き、文言もそのまま（None, just save the report (.md)）にしてください。対象リポジトリの確認は、キーを 1 回入力するだけで済む形式にします（「<owner/repo> をスコアリングするには y と返信してください。別のリポジトリまたはパスを指定する場合は、その名前を入力してください」）。変わるのは質問の提示方法だけであり、この契約はエージェントに依存しません。この契約全体は ci-speedup の操作上の契約に倣っています。ツール、フォールバックの形式、文言を変えない保存オプションをそろえ、どちらかを変更するときは両方を同じように保ってください。 0. スコアリングの前に対象を確認します。 デフォルトの対象は現在作業中のリポジトリです。git rev-parse --show-toplevel がチェックアウトのルートを示し、GitHub の場合は origin リモートから <owner/repo> を特定できます。対話の契約に従って、構造化された質問を1つだけ提示します（選択肢は2つ以上）。検出した <owner/repo>（GitHub リモートがない場合はパス）を確認する選択肢を1つ、「別のリポジトリまたはパス」を1つ用意します（その選択肢または「その他」で指定された内容を対象にします）。作業ディレクトリが Git のチェックアウトではない場合（git rev-parse が失敗する場合）、確認できるローカルのデフォルト対象はありません。質問は通常のメッセージで尋ねるか、「その他」のみを選ぶ形式で提示します（検出されたデフォルト対象が必要な「確認／別の対象」の2択形式は使えません）。ユーザーに対象（<owner/repo> またはパス）を指定してもらいます。ユーザーがすでに対象を指定している場合、曖昧なとき（指定した対象が、単一のローカルチェックアウトまたは単一のクローン可能な <owner/repo> に解決されないとき）に限り、再確認します。スコアリングはローカルで高速かつ無料ですが、この確認は重要です。適用される修正と、保存後のレポートは、スコアリング対象のリポジトリのルートに配置されるため、作業ディレクトリを間違えると別のプロジェクトに対して操作してしまいます。選択された対象が別のローカルチェックアウトの場合は、そのままスコアリングします。選択された <owner/repo> がまだディスク上にない場合は、Requirements のクローンしてからスコアリングするルールに従います（gh repo view でアクセスを確認します。サンドボックス化されたエージェントシェル（Codex）では、キーリングの認証情報にアクセスできず、gh が誤って失敗する場合があります。アクセス不可と判断する前に、ci-speedup の gh ゲートと同様に、ホストアクセスで再試行します。その後、クローンする前にユーザーに確認します — ネットワークとディスクを使用します）。対象が確定するまで、コレクターを実行しないでください。

1. 収集してスコアリングする（1つのコマンドで結果ドキュメントを書き込みます）。 python3 scripts/collect_config.py --repo <checkout-root> --out <workdir>/findings.json。<workdir> は対象チェックアウトの外にある一時ディレクトリです。セッション用スクラッチパッドがあればそれを使い、なければ mktemp -d を使います。リポジトリごとにサブディレクトリ（<workdir>/<repo-name>/）を使い、別のリポジトリや再実行によって以前の実行ファイルが上書きされないようにします。また、カレントディレクトリをデフォルトにしないでください。リポジトリ内に追跡対象外の findings.json があると、次回の実行でプロベナンスが -dirty になります。 終了コード0 = スコアリング済み、またはスタンプに正直な拒否理由が記録されています。終了コード2 = 収集を拒否しました（チェックアウトではない／解析可能なワークフローがない）。終了コード3 = スコアリングに失敗しました（理由は data_sources.ci_score_error に記録されます）。どの結果もドキュメントにスタンプされています。推測せず、内容を確認してください。
2. レポートをスクラッチ領域に出力します。 python3 scripts/render_report.py --findings <workdir>/findings.json --out <workdir>/report.md — スコアカード、速度ではなく遵守状況を評価する旨の説明に続いて、不合格のチェック項目ごとに推奨事項を1つ提示します。推奨事項は影響度 × リスクの順に並べ、それぞれに修正手順、ベストプラクティスのページ、エージェントへの引き継ぎプロンプトを付けます。ユーザーから依頼されるまで、生成したファイルは <workdir> に置いたままにします（ci-speedup の慣例、そちらの issue #18）。対象リポジトリに書き込むのは、終了時に None, just save the report (.md) が選ばれた場合です。その場合は <workdir>/report.md を ./ci-score-report.md（対象リポジトリのルート）にコピーし、生成されたファイルをどこに保存したかを1つの節で伝えます。これはユーザーが gitignore に追加したり削除したりできる生成物です。自動コミットしたり、ユーザーの .gitignore を編集したりしないでください。それ以外の選択肢では、作業ツリーにレポートを書き込みません。 これにより実行がクリーンに保たれ、保存されないレポートが追跡対象外のファイルとして残って、次回実行のプロベナンスを -dirty にすることがありません。生の findings.json は常に <workdir> に置きます。
3. 提示する前に検証します。 python3 scripts/verify_report.py --findings <workdir>/findings.json --report <workdir>/report.md を実行し、report: OK と出力されることを確認します。失敗した場合はステップ2を再実行して、もう一度検証します（古い report.md や、findings と report の組み合わせ違いがよくある原因です）。それでも失敗する場合、生成されたレポートを安全に提示できません。検証に失敗したこと（ユーザーのリポジトリではなく、スキルの不具合です）を伝え、ci_score スタンプのスコア行を直接読んで結果を知らせ、推奨事項は提示しないでください。違反行は、求められた場合にのみ表示します。
4. 終了処理は終了／開始プロトコルに従います。まず references/close-contract.md を読んでください（以下の「終了契約 — 不変条件」セクションは、その場で参照するための要約であり、プロトコルの全内容ではありません）。同じターン内で、次の2つを両方行います。 (a) 終了メッセージ（バナー → 説明 → 推奨事項 → レポートについての注記）を通常のメッセージとして送ります。質問ツールの呼び出しに含めてはいけません。 (b) 上記の対話の契約に従って、開始時の質問を提示します。構造化質問ツールが使える場合（Claude Code の AskUserQuestion など）は、別途そのツールを呼び出します。使えない場合（Codex の実行の多く）は、質問をそのメッセージの最後のブロックにします。選択肢を番号付きで並べ、固定された選択肢を同じ順序で提示し、保存の選択肢は最後に、原文のまま置き、その選択肢でターンを終えます。どちらのプラットフォームでも、終了メッセージを書いただけでは終了処理は完了しません。完了するのは質問を提示したときだけです（ツール呼び出し、または最後に出力した選択肢一覧）。 (a) の後にターンを終えると、ユーザーには選択肢がまったく提示されません（見落とし事例 #2、quasar 2026-07-29：「最後の選択肢を以下に示します」と書いて終了し、質問は提示されませんでした。ユーザーは選択内容を自由入力する必要がありました）。 デバッグトレース：STARSLING_LOG_LEVEL=DEBUG を設定します（件数、ファイル名、チェック状態を記録します。ファイルの内容は記録しません）。

クローズの契約 — 不変条件

完全なクローズ／キックオフプロトコルは references/close-contract.md に記載されています。これらの譲れない事項は、実際に使う場所に記載したままにします。以前、奥に埋もれていたことで実行中のセッションに不具合が生じたためです。このスキルでは、テキストの位置が動作に影響します。それぞれの事項には1行のインシデント記録が添えられています。プロトコルに従う際は、これらを必ず守ってください。

• バナー：収集ツールの標準出力からそのままコピーします。描き直したり、余白を調整したり、手で書き換えたりしないでください（ライブ実行で手描きのバーにより30個中29個のブロック数を誤りました）。拒否または記録された採点エラーの場合、バナーは出力せず、文章だけのクローズを維持します。空のバーや捏造したバーを含むバナーは出力しません。スコアはci_scoreスタンプから直接読み取ります。空欄を埋めるためにスコアを捏造してはいけません。
• **クローズは、クローズ文を出力し、その後に質問を同じターンで提示します。**クローズ文を書いただけではクローズは完了しません。どちらのプラットフォームでも、質問を提示して初めて完了します。選択肢は質問の中にのみ記載します。プラットフォームに構造化質問ツールがある場合はそのツール（Claude Code のAskUserQuestion）、ない場合は最後に出力する選択肢リストを使います（ほとんどのCodex実行）。質問の前に、選択肢を文章で説明してはいけません（ライブ実行で3回、quasarで2026-07-29に2回、さらにCodexの実行で1回、内容は完璧でしたが質問をまったく提示しませんでした）。
• メニューの形式。最初のクローズでは、修正の選択肢を最大2つ提示します（1回の編集で両方を解決できる組み合わせは1つの選択肢と数えます。各選択肢には、その修正に対する同意の範囲とリスクに関する注記を付けます）。次に別の推奨事項を提示し、最後にNone, just save the report (.md)をそのまま記載します。適用後の再提示では、最初に「このブランチをコミットしてPRを開く」を提示します。この選択肢が、コミット＋プッシュ＋PRの依頼にあたります（2026-07-30の所有者の指摘：開発者は追加作業を始める前に成果を取り込みます）。**リリースの選択肢を選んだらループを終了します。マージは絶対にしません。**マージしたとの報告があった場合は、新しいバナーから始まるラウンドを開始します。マージ後のベースを再採点し、最初のクローズと同じ形式で提示してください。「再採点済み、N/100」とだけ補足するのはやめてください（2026-07-30のライブ実行で発生）。
• レポートを作業ツリーに書き込むのは、保存の選択肢を選んだ場合だけです（<workdir>/report.mdを./ci-score-report.mdにコピーします）。ほかの選択肢では書き込みません。
• **承認1回につき推奨事項は1つだけ提示し、差分の時点で止めます。**適用への「はい」が許可するのは編集だけです。それを根拠にコミット、プッシュ、PRの作成をしてはいけません（ライブセッションで、適用の許可をコミットの許可として扱った事例があります）。再採点後のチェックを完了の判定基準とし、スコアを捏造せず、合格させるためだけにYAMLを変更してはいけません。

**毎回、クローズを作成する前にreferences/close-contract.mdを読んでください。**これは実行可能なプロトコルです（同意範囲のルール、意図的な不在の判定、リリースとマージ後のラウンド、拒否時のクローズ、PR依頼のルールを含みます）。上記の不変条件は、プロトコルに従う際に必ず念頭に置いてください。

注意点

• findings.json または未保存のレポートを対象リポジトリに書き込まないでください — 未追跡ファイルがあると、次回実行時のプロベナンスが -dirty になります（公開プロファイルでは dirty は禁止されています）。どちらも <workdir> に出力されます。ユーザーが明示的に保存を選んだ場合にのみ、レポートが ./ci-score-report.md にコピーされます。保存したレポートが未追跡のまま残っていると、後の実行では正しく -dirty と表示されます。プロベナンスをクリーンな状態で実行する必要がある場合は、まずユーザーに gitignore するか削除するよう伝えてください。
• スコアは速度の評価ではありません — 実測では相関は逆で、キャリブレーションでは最もスコアの低いリポジトリが最速のゲートを持っていました。 カードの横にある免責事項はこのためにあります。表示したままにしてください。
• パスフィルターは唯一、リスクのある推奨事項です — フィルターが誤っていると、実行すべき CI がスキップされ、必須チェックがスキップされるとマージがブロックされる可能性があります。 レポートのリスクに関する注記に記載されています。この修正を適用する際は、その点も繰り返し伝えてください。
• サブディレクトリのパスを指定しても、スコアの対象はリポジトリ全体です — コレクターは git のトップレベルを基準にします（部分的な表示ではスコアが実際より高くなるためです）。 そのため、チェックアウト内のどこで --repo を指定しても同じです。
• -dirty プロベナンスは保守的です — 未追跡ファイルもカウントされます。また、ツリーを検証できない場合（git status の実行に失敗した場合）は、クリーンではなく dirty としてマークされます。

適用範囲

ci-score は設定の健全性を評価します。速度の測定も、削減額の推定も、金額の表示もしません。**この禁止事項は単なる説明上のものではなく、運用上の制約です。**ユーザーがいつでも速度、コスト、実時間について尋ねた場合は、スコアを見た直後の「では、なぜ CI が遅いのですか？」という質問も含め、設定の事実から回答を即興で組み立てないでください（キャッシュがないことは測定結果ではありません）。その旨を一文で伝え、ci-speedup に案内してください。実測の実時間やランナーの実行時間に関する調査は、別のスキルである ci-speedup が担当します。ci-speedup の実行ではスコアは表示されず、このスキルが測定結果を主張することもありません。プロンプトの振り分けに関する契約（各質問にどのスキルが回答するか）： evals/prompt-routing.json。