Codexによるread-onlyローカルレビューを実行する。Triggers on: '/codex-review', 'Codexでレビューして', 'クロスモデルレビューして'
cross-repo-verify
実装が他リポジトリのコードの挙動に依存する仮定を、依存先の実コードで確証する。クロスリポジトリ依存が無い場合は使用しない。Triggers on: '/cross-repo-verify', 'クロスリポジトリ依存を確認', 'クロスリポジトリの確証'
含まれるファイル(1)
- SKILL.md4.7 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
クロスリポジトリ依存の確証
実装が他リポジトリのコードの挙動(API の副作用・導出・判定ロジック等。例:「A を同期すれば B が作られる」)に依存する仮定を含む場合に、その仮定を依存先リポジトリの実コード(判定箇所・書き込み箇所)で確証する手順です。
クロスリポジトリ依存が無い場合はこのスキルを使用しない。
手順
1. コミット SHA の解決
取得前にコミット SHA を固定する。ブランチ名のまま取得すると、取得中にブランチが進んだ場合に本文と記載する根拠 SHA がずれ得るため、先に対象ブランチの HEAD SHA を解決する:
gh api "repos/{owner}/{repo}/commits/{branch}" --jq '.sha'
2. 依存先実コードの取得
依存先の clone は不要。Step 1 で解決した SHA を ref に指定して gh api で対象ファイルの本文を read-only に取得し、判定箇所・書き込み箇所のコードを直接確認する:
gh api -H "Accept: application/vnd.github.raw+json" "repos/{owner}/{repo}/contents/{path}?ref={SHA}"
3. 根拠の記載形式
根拠はStep 1 で解決したコミット SHA を記載する。ref の省略やブランチ名のままの記載は不可とし、repo/file:line だけでは後から別版のコードが根拠扱いになり得るため、repo@コミットSHA/file:line 形式で統一する。
4. 確証結果テーブル
確証結果は以下の形式で設計成果物または PR 本文に記載する:
## クロスリポジトリ依存の確証
| 仮定 | 確証結果 | 根拠(repo@コミットSHA/file:line) |
|------|---------|--------------------------|
| {API X を呼ぶとテーブル B が導出される} | ✅ 確証 / ⚠️ 未確証 | {owner/repo}@{コミットSHA}/{path}:{行} |
後述「確証の独立再照合」によって ✅ 確証から格下げされた行の表記ルールは同節を参照。
規律
- 自リポジトリのモックテストが green であることは、仮定の検証とみなさない。モックは「X を呼んだこと」しか検証できず、「X を呼んだら何が起きるか」は検証対象外
- 確証できない場合は「未確証の仮定」として明示し、仮定が誤っていた場合の影響(実装が no-op になる等)を添える
確証の独立再照合
確証結果テーブルが実際に生成された場合(行が1行以上存在する場合)にのみ、テーブルの行ごとに claude-harness:attestation-verifier を Task ツールで独立に spawn し、確証の真正性を反証させる。確証した本人(このスキルを実行している自分自身)が取得済みのファイル内容を懐疑者に代弁させて信用させてはならない — 懐疑者は根拠に記載された SHA から自分で対象ファイルを取得し直す前提で設計されている。テーブルの行が複数ある場合は並列 spawn してよい。
各行の spawn には以下を渡す:
- 仮定
- 確証結果(✅ 確証 / ⚠️ 未確証)
- 根拠(
{owner/repo}@{SHA}/{path}:{行})
呼び出し例:
Task(
subagent_type: 'claude-harness:attestation-verifier',
prompt: "以下のクロスリポジトリ依存確証の1行を独立に反証してください。\n仮定: {仮定}\n確証結果: ✅ 確証\n根拠: {owner/repo}@{コミットSHA}/{path}:{行}"
)
返ってきた verdict が not_supported(引用は仮定を支持しない。反証成立)または unverifiable(判定不能)の行は、確証結果テーブルの ✅ 確証を外し「⚠️ 未確証の仮定」へ格下げする(表記は既存の2値のまま統一し、新しい記号は追加しない)。格下げした行は、テーブルの下に - {仮定}: 独立再照合により未確証へ格下げ(reason: {懐疑者の reason}) の形式で注記を列挙し、同内容を PR 本文にも明示する。supported(引用は仮定を支持する)verdict の行は、元の ✅ 確証のまま確証結果テーブルに残してよい。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
調査(read-only)または雑務(workspace-write)をCodexへ委譲し、結論をJSONで受け取る。Triggers on: '/codex-task', 'Codexで調べて', 'Codexにやらせて', 'Codexへ委譲'
Conventional Commits形式でコミットする。Triggers on: '/commit', 'コミットして', 'commit changes'
恒常的な設計決定を ADR として記録する(退役する機能仕様から ADR 昇格の要否を判定するモードを併せ持つ)。定常フローの必須ステップではなく、必要時に呼ぶ。Triggers on: '/create-adr', 'ADRを書いて', '設計判断を記録', 'ADR昇格を判定'
仕様(チケットの完了条件・受入基準)からE2Eテストを実装する(非対話)。Triggers on: '/create-e2e', 'E2Eテストを書いて', 'E2Eテストを追加して'
機能仕様ドキュメントから要件チケットを作成する、または親要件チケットを実装チケット群に分解する。Triggers on: '/create-ticket', 'チケットを作成', 'Issueを作って', 'create ticket', '実装チケットに分解'