audit-reproducibility

監査の再現性

原稿中の数値に関する主張（点推定値、標準誤差、p値、件数）を、分析パイプラインが実際に生成した出力と比較します。.claude/rules/replication-protocol.mdで定義された許容範囲に基づき、主張ごとに PASS／FAIL を報告します。

基本原則： 論文に ATT = -1.632 (0.584) と記載され、コードが -1.628 (0.591) を生成した場合、その差が文書化された許容範囲内にあるかを数値で検証します。「十分近そう」という目視判断はもう行いません。

一方向ではなく、二方向で確認します。 縦方向では、各主張を、その根拠となった出力と照合します。横方向では、補足資料の表、スライド資料、ポスターなど、同じ数値が記載されたすべての別の成果物と照合します。縦方向の確認は問題なく通っても、スライド資料に先月の数値が記載されていることがあります。それを検出するのは横方向の確認だけです。記載先はパスポートの appears_in リストに記載します。詳しくは、replication-protocol.md → 横方向の確認を参照してください。

使用するタイミング

• 投稿前。 「分析を更新したのに表2の更新を忘れた」というミスを検出します。
• 同じ数値を使って発表または授業を行う前。 最後に再実行した後で更新されていないスライド資料、ポスター、補足資料を検出します。
• 再現パッケージの公開前。 コードが実際に論文の結果を再現することを確認します。
• 大幅な改訂後。 論文が最新のコードと一致していることを確認します。
• /commit の品質ゲート。 原稿と分析の変更に対して、コミット前の実行と組み合わせます。

入力

• $0 — 原稿へのパス（.tex、.qmd、.md、.pdf）。必須です。
• $1 — 出力ディレクトリへのパス。既定値は output/ です。各言語のパイプラインはここに出力します（R、/stata-replication経由のStata、Python）。認識される代替ディレクトリは、_targets/objects/（Rの targets ワークフロー）と、ユーザーが指定した出力が保存される任意のディレクトリです。output/ が存在せず、v2.6より前の scripts/<lang>/_outputs/ が存在する場合は、そちらを使用し、その旨をレポートに記載してください。

ワークフロー

フェーズ0：事前確認

1. replication-protocol.mdを読み、現在適用されている許容範囲を確認します。
2. 出力ディレクトリが存在し、空でないことを確認します。空、または古い（原稿よりも更新日時が前の）場合は、監査の前にパイプラインを再実行するようユーザーに依頼します（例：Rscript scripts/R/00_run_all.R）。
3. 出力ディレクトリに sessionInfo.txt または同等の環境情報の記録があることを確認します。

フェーズ1：原稿から主張を抽出する

原稿を解析して、数値に関する主張を抽出します。照合するパターンは次のとおりです。

• 点推定値＋SE： ATT = -1.632 (0.584)、$\beta = 0.342$ (0.091)、有意性を星印で示した hat{\tau} = 1.28**
• 表のセル： LaTeXの表環境にある & -1.632$^{***}$ & 0.584 &
• 件数： our sample of 2,847 firms、$N = 2{,}847$
• 要約統計量： mean = 0.423、SD = 0.087
• P値： p < 0.01、$p = 0.003$

各主張を次のタプルとして記録します。

{
  claim_id: "Table2_col3_ATT",
  location: "Table 2, Column 3, row 'Treatment'",
  kind: "point_estimate" | "standard_error" | "p_value" | "count" | "percentage",
  reported_value: -1.632,
  uncertainty: 0.584,              # only for point estimates
  significance_stars: 3,            # 0-3 or None
  raw_context: "the ATT estimate of -1.632 (0.584) indicates..."
}

抽出した主張を quality_reports/reproducibility_claims_[manuscript-name].json に書き込み、監査前にユーザーが抽出内容を確認できるようにします。

フェーズ2：出力から結果を抽出する

$1 をスキャンし、対応する値を探します。優先順位は次のとおりです。

1. .rds ファイル — readRDS(path)$coef[["treatment"]] のような参照を使用します。抽出には Rscript -e "saveRDS(summary(readRDS(...)), '/tmp/audit.rds')" を使用できます。
2. .tex 表 — LaTeXの表セルを直接解析し、列見出しと行ラベルを照合します。
3. .csv 要約ファイル — pandas／readrで解析し、キーと値を照合します。
4. .out／.log ファイル（Stata、回帰出力）— 正規表現で抽出します。
5. .json — キーを直接参照します。

抽出した各結果を次のように記録します。

{
  source: "output/results.rds",
  lookup_key: "fit_main$coefficients['treated']",
  value: -1.628,
  uncertainty: 0.591,
  p_value: 0.005
}

フェーズ 2b：宣言された表示をすべて収集する（パスポートモード）

パスポートの各クレームについて、appears_in リストを読み、各エントリでの値を表示どおりに取得します。

{
  claim_id: "C3",
  displays: [
    { path: "manuscript.tex", locator: "Table 1, Col 2", display_precision: 3, shown: 0.342 },
    { path: "Slides/Lecture04_Results.tex", locator: "frame 'Main result'", display_precision: 2, shown: 0.34 }
  ]
}

このパスのルール：

• 主たる location: も表示の1つであり、別個のものではありません。appears_in に同じ場所が繰り返し記載されていても、表示は1つです。
• 宣言された表示を解決できない場合（ファイルが存在しない、または locator に値がない場合）は、shown: NOT_FOUND として記録します。 フェーズ 4c では FAIL になります。決してスキップしないでください。ひそかに一致しなくなった locator にこそ、古くなった数値が潜んでいます。
• appears_in リストのないクレームは、横断的に未チェックであり、問題がないわけではありません。黙って合格にせず、そのように報告してください（フェーズ 5 を参照）。

フェーズ 3：クレームを結果と照合する

ラベルが完全一致しない場合は、ファジーなヒューリスティックを使用します。

• 名前の類似性（"treatment effect" ~ "ATT" ~ "treated"）
• 大きさの類似性（候補値が報告値の 10% 以内にある場合は、SE がより近い候補を優先します）
• クレームの raw_context フィールドにあるコンテキストのヒント（表番号、行ラベル、説明）

すべてのクレームについて、信頼度スコア付きの照合候補を作成します。信頼度が 0.7 未満のクレームには、黙って合格にせず、「UNMATCHED — 手動レビューが必要」のフラグを付けます。

フェーズ 4：許容範囲のチェック

照合できた各クレームに対して、replication-protocol.md のしきい値を適用します。

種類	許容範囲	例
整数（N、件数）	完全一致	2,847 は 2,847 と一致する必要があります
点推定値	abs(reported - computed) < 0.01	-1.632 対 -1.628 → 差 = 0.004 → PASS
標準誤差	abs(reported - computed) < 0.05	0.584 対 0.591 → 差 = 0.007 → PASS
P 値	同じ有意水準	p<0.01 と p<0.01 → PASS、p<0.01 と p=0.03 → FAIL
パーセンテージ	±0.1pp	42.3% 対 42.35% → PASS

ユーザーが replication-protocol.md のフォークに記載した許容範囲の上書きがあれば、それに従ってください（MC のノイズに対して緩和したり、行政データに対して厳格化したりする場合があります）。

フェーズ 4b：判定 — PASS / FAIL / EXPLAINED / UNMATCHED

許容範囲のチェック結果は、次の4つの判定のいずれかになります。

• PASS — 許容範囲内です。
• FAIL — 許容範囲外で、正当化できる代替案が記録されていません。ブロックします（終了コード 1）。
• EXPLAINED — 許容範囲外ですが、差を説明する具体的で名称が明示された代替仕様を著者が記録しています（格下げルールを参照）。レポートに表示され、査読者への回答にも含まれます。ブロックはしません。
• UNMATCHED — 対応する計算結果が見つかりません（フェーズ 3 の信頼度 < 0.7）。自動的に格下げされることはありません。

不一致が自動的に失敗を意味するわけではありません。 応用研究では、許容範囲を外れる結果の多くはバグではなく、正当化できる代替仕様によるものです。たとえば、reghdfe と feols のクラスタリング自由度、異なる帯域幅選択ルール、異なる MC シード／反復回数、表示時の丸めなどです。このスキルの役割は、人間の監査担当者が判断できるように不一致を提示することであり、コードが正しく論文が間違っていると断定することではありません。後述の「Stata 固有の注意事項」にある自由度調整の注記は、名称が明示された代替案の代表例です。

原稿は絶対的な正解ではありません。 計算値が原稿と一致しない場合、コードが正しく論文が古いと決めつけてはなりません。その逆も同様です。リファクタリングによって、以前は正しかった表が壊れている可能性（ディスク上の出力にバグがある可能性）も、論文に古い数値が残っている可能性もあります。計算値は真実ではなく、異議を唱える側です。不一致は「{論文、コード} のどちらかを変更する必要がある。どちらかを特定すること」と報告し、「論文に合わせてコードを戻す」と報告してはいけません。これにより、「再現」させるためだけに本物のバグ修正を取り消す落とし穴を防げます。

降格ルール：FAIL → EXPLAINED

FAIL は、その正確な主張に対する具体的に明記された代替仕様が、パスポートエントリーの notes: フィールド（パスポートモード）または監査レポートの著者メモ列（デフォルトモード）に記録されている場合に限り、EXPLAINED に降格できます。有効なメモの例：

「reghdfe と feols のクラスタリングにおける自由度調整の違い。reghdfe の小標本補正では公表値は −1.19 となり、スクリプトの −1.187 と丸め誤差の範囲で一致します。CODE-CORRECTED を保留中。」

著者とは監査担当者のことです。スキルが両側の比較（報告値と計算値の両方を表示）を準備し、人間が代替仕様を明記した一行のメモを記述します。スキルはそれを記録し、以後それに従います。解決タグは PAPER-CORRECTED、CODE-CORRECTED、または DEFENSIBLE-ALTERNATIVE とします。

最低基準 — EXPLAINED への降格を決して認めないもの：

• 空欄のメモ、「不明」、「問題なさそう」、または具体的な代替仕様を明記していないメモ。
• 比較対象となる計算値がない UNMATCHED の主張。
• 代替案が提示されていない、数値の明白な矛盾。

（引用／存在に関する主張はここでは対象外です。これらは /verify-claims の担当であり、そちらでも同じ具体的な代替案による緩和が適用されます。）

EXPLAINED の繰り返しは兆候です（二度目で警告）

review-paper --adversarial および summary-parity.md の二度目で警告するルールを適用します。同じ主張が、PASS に一度も修正されないまま、連続する2回の監査で EXPLAINED に降格された場合（著者が代替案を引き続き提示する一方、論文もコードも更新しない場合）、ひそかに解決済みとして扱うのをやめます。Phase 5 で目立つように示します — 「この係争中の数値は2回 EXPLAINED とされたものの、修正されていません」 — そうすることで、記録されたメモの陰に継続中の意見の相違がいつまでも隠れないようにします。パスポートモードでは、現在の status／notes を前回の監査結果と比較して検出します。

Phase 4c：横断チェック — 各表示が互いに一致しているか

Phase 4 では主張とコードを比較しました。このフェーズでは、Phase 2b で収集した displays を対象に、主張の各表示を相互にペアごとに比較します。

1. 両方を精度の粗い方に丸めます。 両方の表示を、2つの display_precision 値のうち小さい方に丸めた後に等しくなれば、一致とみなします。スライドの 0.34 と論文の 0.342 は小数第2位で一致しますが、0.29 と 0.342 は一致しません。
2. 許容誤差は適用しません。 tolerance: ブロックは垂直方向の比較、つまり2つの測定値を比較する場合に適用されます。同じ数値を表示する2つの表示は、1つの数値の複製です。手順1で丸めた後、一致するかどうかのどちらかです。
3. Phase 4b の用語で判定します：
   • PASS — すべてのペアが一致します。
   • FAIL — いずれかのペアが一致しない、または表示のいずれかが NOT_FOUND です。EXPLAINED への降格は決してできません。代替仕様を明記することでコードと論文の違いを説明できても、同じ数値の2つの表示が異なる理由は説明できません。ある表示に実際に異なる仕様が示されている場合、それは別の主張であり、独自のパスポートエントリーに記載します。
   • UNCHECKED — 主張に appears_in リストがありません。報告しますが、ブロック対象ではありません。修正するには表示を宣言します。
4. どちらが正しいかではなく、どちらが変わったかを報告します。 他と値が異なる成果物と、最後に更新された時期を示します。スライドが古いのか論文が古いのかは著者が判断します。一方の表示をその同類に合わせて手作業で編集してはいけません。主張が参照している出力から、両方を再導出します（replication-protocol.md → 反パターン）。

Phase 5：レポート

quality_reports/reproducibility_audit_[manuscript-name].md を作成します：

# Reproducibility Audit: [Manuscript Title]

**Date:** [YYYY-MM-DD]
**Manuscript:** [path]
**Outputs directory:** [path]
**Tolerance source:** .claude/rules/replication-protocol.md

## Summary

| Status | Count |
|---|---|
| PASS (vertical and horizontal) | N |
| FAIL (diff > tolerance, no named alternative) | M |
| EXPLAINED (out of tolerance, named alternative recorded) | E |
| UNMATCHED (manual review) | K |
| HORIZONTAL DRIFT (declared displays disagree, or a display not found) | H |
| HORIZONTALLY UNCHECKED (claim declares no `appears_in`) | U |
| **Overall verdict** | **PASS / FAIL** (FAIL iff M > 0 or H > 0; EXPLAINED does not fail the audit) |

## PASS (all within tolerance)
| Claim | Reported | Computed | Diff | Tolerance |
|---|---|---|---|---|
| Table2_col3_ATT | -1.632 (0.584) | -1.628 (0.591) | 0.004 / 0.007 | 0.01 / 0.05 |

## FAIL (outside tolerance — BLOCKER)
| Claim | Reported | Computed | Diff | Tolerance | Location in paper | Author note (name a concrete alternative to downgrade → EXPLAINED) |
|---|---|---|---|---|---|---|

## EXPLAINED (out of tolerance; defensible named alternative recorded — non-blocking, carry into response-to-referees)
| Claim | Reported | Computed | Named alternative (why the gap is defensible) | Resolution |
|---|---|---|---|---|
| Table3_col2_ATT | -1.187 | -1.19 | reghdfe vs feols clustering-df adjustment | DEFENSIBLE-ALTERNATIVE |

## UNMATCHED (manual review)
| Claim | Raw context | Candidate sources |
|---|---|---|

## HORIZONTAL DRIFT (one number, two values — BLOCKER)
| Claim | Display A | Display B | Compared at | Values | Which side moved |
|---|---|---|---|---|---|
| C3 | manuscript.tex — Table 1, Col 2 | Slides/Lecture04_Results.tex — frame 'Main result' | 2 decimals | 0.34 vs 0.29 | deck older than the claim's output_file |

## HORIZONTALLY UNCHECKED (no `appears_in` declared)
| Claim | Primary display | Other artifacts to declare |
|---|---|---|

## Environment
[sessionInfo excerpt]

## Next steps
1. Resolve each FAIL row — either correct the manuscript, rerun the analysis, or (if the gap is a defensible alternative spec) record a concrete named alternative to downgrade it to EXPLAINED.
2. Resolve each HORIZONTAL DRIFT row — regenerate the lagging display from the claim's output, never by retyping the other display's value. A `NOT_FOUND` display is fixed by correcting the `locator`, not by dropping the entry.
3. Review UNMATCHED rows — add explicit lookup keys or widen the search scope.
4. Declare `appears_in` for the HORIZONTALLY UNCHECKED rows — every artifact a reader sees the number in.
5. Review EXPLAINED rows before submission — each should map to a sentence in the response-to-referees.
6. After zero FAILs and zero HORIZONTAL DRIFT (EXPLAINED rows allowed), the paper is replication-ready.

フェーズ 5b: レプリケーションログへの追記

上記のレポートとパスポートは実行のたびに書き換えられるため、どちらも履歴を保持しません。ログは保持します。毎回の実行後 — デフォルトモードとパスポートモードのどちらでも — quality_reports/replication-log.md に 1 つのブロックを追記します。これはコミットされるため、共同執筆者やデータエディターはコードを読むことなく、何が検証されたか、どのコミットに対してか、そして各数値がどのように得られたかを確認できます。

• 追記のみ。 >> で書き込み、過去のブロックを編集したり並べ替えたりしないでください。修正は新しい実行であり、編集ではありません。リポジトリ衛生ゲートは、コミット済みの行を編集または削除するコミットを失敗させます — 最後のコミットに対する pre-commit フックで、そして CI では作業がマージされるブランチに対して。これはどのエントリも編集されていないことを証明するものであり、すべての実行がログに記録されたことを証明するものではありません。開示のための墨消しが唯一の例外です: ALLOW_LOG_REWRITE=1 とコミットメッセージに理由を付けてコミットしてください。
• リビジョンを記録する。 短いコミットハッシュ、および quality_reports/ の外側に未コミットのもの（未追跡ファイルを含む）がある場合は -dirty を付けます — これにより、未コミットのコードに対する判定であることが明示され、監査自身のレポートファイルがそれを引き起こすことはありません。git の外、または最初のコミットより前では、記録は no-commit です。
• 「どのように計算したか」は、フェーズ 2 が使用した正確なアクセサーまたはコマンドです — 他の誰かがその 1 つの数値を再計算するのに十分なものです。
• 制限されたデータ: ログはレポートと同じ数値を保持するため、他の出力と同様、開示のクリアランス後にのみコミットされます（confidential-data.md）。

LOG=quality_reports/replication-log.md
[ -f "$LOG" ] || printf '%s\n' "# Replication log" "" \
  "Append-only record of /audit-reproducibility runs: what was checked, against which commit, and how each number was computed. Never edit a past entry; a correction is a new run." "" > "$LOG"
# -dirty = anything uncommitted outside quality_reports/, untracked files included (the audit writes its own files in quality_reports/)
if REV=$(git rev-parse --short HEAD 2>/dev/null); then
  [ -n "$(git status --porcelain -- . ':(exclude)quality_reports' 2>/dev/null)" ] && REV="$REV-dirty"
else
  REV="no-commit"   # not a git repository, or nothing committed yet
fi
printf '## %s — %s @ %s\n\n' "$(date +%F)" "<manuscript path>" "$REV" >> "$LOG"
# Quoted heredoc: nothing below is expanded, so an accessor's `$` or backtick is written as-is.
cat >> "$LOG" <<'EOF'
Outputs: `<outputs dir>` · Verdict: **<PASS|FAIL>** (<M> FAIL, <H> horizontal drift, <E> EXPLAINED, <K> unmatched)

| Claim | Location | Reported | Computed | How computed | Tolerance | Verdict |
|---|---|---|---|---|---|---|
| Table2_col3_ATT | main.tex: Table 2, col 3 | -1.632 | -1.628 | `readRDS("output/results.rds")$coef[["treatment"]]` | 0.01 | PASS |

EOF

監査対象のクレームごとに 1 行、レポートの順序で。

終了時の動作

• すべて PASS（または PASS + EXPLAINED）: 終了コード 0、サマリーを出力。
• HORIZONTAL DRIFT が 1 つでもある: 終了コード 1、FAIL と同じ扱いです — 1 つの数値に対して 2 つの成果物が異なる値を示すのは、どちらが正しくても欠陥です。HORIZONTALLY UNCHECKED の行は警告（終了コード 0）となり、一覧表示されます。
• FAIL が 1 つでもある: 終了コード 1、サマリーを stderr に出力。これによりこのスキルは /commit の pre-commit ゲートとして使用できます — 強制のパターンについては replication-protocol.md を参照してください。EXPLAINED の行は FAIL としてカウントされず、終了コード 1 を決して引き起こしません — それらは表面化されるものであり、ブロックするものではありません。ゲートは、真の FAIL（名前付きの代替がないもの）および捏造された／UNMATCHED のクレームに対して、その完全な効力を保ちます。
• UNMATCHED > 0（FAIL が 0 の場合）: 警告付きで終了コード 0 — ユーザーが手動でレビューする必要があります。

ソース言語のカバレッジ

このスキルは、原稿のクレームを 3 つのソース言語エコシステムの出力と比較します。3 つとも同じ output/ ディレクトリに書き込みます:

ソース	デフォルトの出力ディレクトリ	出力の読み取り方法	一般的なクレームのソース
R（デフォルト）	output/	readRDS()、arrow::read_parquet()、vroom::vroom()	.rds / .parquet / .csv / tinytable .tex
Stata（v1.9.0）	output/	R からの haven::read_dta()、または Python からの pyreadstat.read_dta()	.dta / esttab .tex / .smcl ログの値
Python	output/（または _targets/）	pandas.read_parquet、pickle.load	.parquet / .pickle / .csv

Stata 固有の注意事項（v1.9.0）:

• .dta 出力は、haven::read_dta()（R）、pyreadstat.read_dta()（Python）を介して、または原稿が引用しているのが表セルの値である場合は対応する esttab .tex を解析することによって読み取られます。
• 原稿のセル \input{output/tab_main.tex} は最も強い来歴のシグナルです — セルの値は .do ファイルから機械的に得られます。.tex 内の位置を 03_analyze.do の回帰呼び出しと一致させてください。
• クラスタリングの df 調整は reghdfe とベースの reg, cluster() で異なることがあります。SE が小数点第 2 位で一致しない場合、replication-protocol.md の許容範囲でカバーされます。小数点第 1 位で一致しない場合は、df 調整を調査してください。

Passport モード（v1.9.0）

quality_reports/passports/<paper-slug>.yaml が存在する場合、スキルは passport モード で動作します。一度限りのレポートを出力する代わりに、passport ファイルを読み取り、更新し、同じ場所に書き戻します。

• passport の各 claims: エントリーについて、デフォルトモードと同じ数値監査を実施します（location にある原稿から報告値を抽出し、source_file:source_line / output_file:output_field にある計算値を特定して、tolerance: と比較します）。その後、エントリーの appears_in リストを対象に、フェーズ 2b および 4c の横断チェックを実施します。
• 各 claim の監査後、status をその場で更新します。
  • PASS → claim が許容範囲内であり、かつ宣言されたすべての表示が、より粗い精度で一致している状態です。
  • FAIL → claim が許容範囲外であり、かつエントリーの notes に具体的な代替仕様が記載されていない場合、または宣言された 2 つの表示が一致しない場合、または appears_in のエントリーをファイル内で見つけられなかった場合です。不一致を notes に記録します。垂直方向の FAIL では報告値と計算値を、横方向の FAIL では 2 つの表示値とそのパスを記録します。処理をブロックします（終了コード 1）。
  • EXPLAINED → claim が許容範囲外であっても、エントリーの notes に 具体的な名称のある代替仕様 がすでに記録されている状態です（空欄や「不明」ではないこと）。次回の実行時にスキルは notes を読み、同じ許容範囲外の claim を FAIL ではなく EXPLAINED として解決します。表示されますが、処理はブロックしません。最低限の基準は引き続き適用されます。UNMATCHED の claim、または代替仕様の名称が記載されていない note は FAIL のままです。
  • STALE → source_file、output_file、または appears_in のいずれかのパスの更新日時が last_verified_on より後の場合、STALE とマークして監査ロジックを再実行します（再実行後、ステータスは PASS / FAIL / EXPLAINED になります。STALE は一時的な状態です）。
• claim ごとに last_verified_on と last_verified_by: "/audit-reproducibility" を更新します。
• トップレベルの paper.last_audit を更新します。

原稿内で、対応する passport エントリーのない claim が検出された場合は、未検証の警告を出力します。誤った推測を避けるため、passport の対象範囲は自動入力ではなく著者が管理するため、著者がその claim を追加する必要があります。

passport モードでは passport エントリーを削除しません。原稿から claim がなくなった場合も、passport エントリーは STALE ステータスのまま残ります。削除（claim の撤回）するか、エントリーの location を更新する（claim の移動）かは、著者が判断します。

また、appears_in エントリーを自動で追加することもありません。横断チェックで偶然見つかった表示、つまり passport で宣言されていないデッキや補足資料内の同じ値は、「HORIZONTALLY UNCHECKED」表に提案として報告されます。著者がその表示を宣言します。前述の自動入力を行わないルールと同じ理由です。実際には異なる量である表示を推測して追加すると、横断チェックで常に失敗することになります。

完全なスキーマと統合箇所（/commit、/review-paper）については、.claude/rules/replication-protocol.md の「Claims Provenance: passport.yaml」を参照してください。

相互参照

• .claude/rules/replication-protocol.md — 許容範囲の契約とパスポートのスキーマです。
• templates/passport-template.yaml — 新しい論文用にコピーするひな形ファイルです。appears_in リストで表示箇所を宣言します。
• .claude/hooks/claim-reconcile.py — イベント駆動の通知機能です。追跡対象のスクリプト、出力、または宣言された表示箇所を書き込むと、再監査対象の主張が特定されます。宣言数を数えるのがこの機能で、比較するのがこのスキルです。
• .claude/skills/review-r/SKILL.md — コードスタイルの問題を検出します。このスキルは数値の再現性を検出します。
• .claude/skills/diagnose/SKILL.md — 主張が FAIL となり、どのパイプライン手順で許容範囲外の値が生成されたかを特定する必要がある場合は、/diagnose に引き継ぎます（単一の主張の根本原因を特定：再現 → 最小化 → 二分探索）。
• .claude/skills/review-paper/SKILL.md — 内容をレビューします。投稿前の完全な監査には、このスキルと併用してください。
• .claude/skills/replication-package/SKILL.md — AEA DCAS への提出物を組み立てる前に、このスキルのチェックを行います。
• .claude/skills/capture-environment/SKILL.md · .claude/skills/disclosure-check/SKILL.md — 後続工程で行う環境の記録と、制限付きデータのスクリーニングです。

このスキルで行わないこと

• 分析を再実行すること。 このスキルは、現在の出力と原稿の主張を比較します。出力が古い場合は、まずパイプラインを再実行してください（事前チェック段階で警告が表示されます）。
• 誤った仕様を検出すること。 正常にコンパイルされ、再現可能な -1.632 を生成する回帰は、再現可能です。-1.632 が正しい推定対象かどうかは、review-paper または分野の査読者が判断する問題です。
• 外部パッケージのバージョンを確認すること。 sessionInfo.txt の記録により、査読者は環境を確認できます。バージョンの固定はユーザーが行います（renv.lock または DESCRIPTION ファイルを使用）。

長時間の一括再実行：Monitor ツールを使用（2026 年 4 月）

/audit-reproducibility で論文中のすべての数値的主張を検証するよう求められた場合、最も安全な方法はパイプライン全体（00_run_all.R または同等のもの）を再実行し、再生成された出力と原稿の値を比較することです。数分以上かかるパイプラインでは、再実行をバックグラウンドで開始し、Anthropic の Monitor ツール（2026 年 4 月 第 15 週）を使用して標準出力をストリーミングしてください。監査では、パイプライン全体の終了を待って失敗した手順に気づくのではなく、実行中にエラーへ対応できます。