| name | explain-ahc-solver |
| description | AHC形式のRust solverから、日本語の再現可能な解説を作る。入力としてチャンピオン実装や提出候補コードが与えられ、コード削除や簡素化で本質を抽出し、必要に応じてsubagentに解説だけから再実装と評価をさせ、japanese-tech-writingに従う技術解説へ仕上げるときに使用する。 |
explain-ahc-solver
AHC solver の実装から、読者が方針を再現できる日本語解説を作る。
この skill は、実装をそのまま説明するためではなく、得点に効く構造を抽出して説明するために使う。
必ず読むもの
problem_description.txtnotes/notations.md- 対象 solver
src/bin/v000_template.rs- 評価に使う
scripts/eval.py, scripts/run.sh, Cargo.toml
japanese-tech-writing
japanese-tech-writing は、解説本文を書く前に読む。
解説本文は、その規範に従って一文一行で書く。
作業の入口
ユーザーが対象 solver、目標スコア、出力する解説ファイル名を指定している場合は、それに従う。
指定が足りない場合は、既存の評価ログとプロジェクト規約から合理的に補う。
ただし、対象 solver が曖昧な場合だけ確認する。
本質を抽出する
まず対象 solver を読み、次の分類を作る。
- 本質構造：得点の大部分を支える構成、状態表現、探索の形、評価の考え方。
- 運用上の工夫：時間配分、候補数、近似評価、本評価への回し方。
- 非本質な残骸：呼ばれていない旧探索、ログ、統計、デバッグ用の型、過去案の補助関数。
- 危険な細部：削ると目標を割る可能性が高い後処理、補正、検証、時間管理。
コード削除や簡素化で本質を確認する場合は、simplification.md に従う。
解説を書く
解説は、実装順ではなく読者が方針を作れる順で書く。
最初に問題のどの圧力へ対処しているかを書く。
次に、その圧力に対してどの構造を置くかを書く。
その後、構造を成立させるための候補生成、近似評価、本評価、時間管理を書く。
説明では「何をするか」だけで終えない。
その操作がなぜ必要か、削ると何が壊れるか、推定と本評価の役割がどう違うかを書く。
seed、特定ケース名、たまたま効いた候補数、実装上の配列サイズは、再現性に必要な場合だけ書く。
検証セットへの過適応に見える情報は、本文に入れない。
検証前に文章を点検する
subagent に渡す解説は、文章点検後の本文でなければならない。
点検前の粗い本文で成功しても、その後に本文を整えれば検証対象が変わる。
解説を書いたら、subagent 検証の前に writing-checklist.md を使う。
ここで、japanese-tech-writing に反する文体、空虚な強調、過度な実装名の羅列、確認していない断定を落とす。
ただし、文章点検で手順、条件、因果、候補選別、本評価への回し方、パラメータの意味が変わった場合は、その本文を新しい検証対象とする。
文章点検は、検証済みの本文を後から別物へ置き換える工程ではない。
検証する
解説の良さは、読者がその文章だけから十分な solver を作れるかで測る。
必要に応じて新規 subagent を使い、対象 solver を読ませずに、問題文、v000_template.rs、解説だけから再実装と評価をさせる。
手順は subagent-validation.md に従う。
検証で使った本文を固定する。
可能なら shasum -a 256 <解説ファイル> などで、検証対象の内容を記録する。
検証で閾値を下回った場合は、subagent の実装を読むだけで終えない。
解説のどの文が誤読を誘ったか、どの判断が書かれていなかったかを特定して本文へ戻す。
検証に成功しても、試行錯誤が多い場合は解説がまだ弱い。
評価後のチューニング回数、full 評価回数、曖昧だった判断を確認する。
検証後の編集を扱う
subagent 検証後に、解説本文の意味を変える編集をした場合、その検証結果は失効する。
意味を変える編集には、手順の入れ替え、条件の追加や削除、因果説明の変更、候補選別や評価方法の変更、パラメータの扱いの変更が含まれる。
検証後に許されるのは、表記ゆれ、誤字、句読点、リンク、意味を変えない言い換えなどの小さい修正だけである。
迷う場合は意味が変わったものとして扱い、再度 subagent 検証を行う。
最終成果物は、原則として最後に subagent が読んだ検証対象本文と同一内容にする。
検証後に差分が残る場合は、表記ゆれ、誤字、句読点、リンク、意味を変えない言い換えのどれに当たるかを分類する。
分類できない差分がある場合は、再検証する。
最終報告では、検証対象本文と最終本文が同一内容かを確認する。
同一でない場合は、差分が意味を変えない編集だけである理由を書く。
生成AI利用ルールを守る
新しい solver 候補を複数作って自動比較しない。
AI が作る新規 solver は、1 会話につき 1 本までにする。
複数候補を比較できるのは、ユーザーが明示した既存 solver だけである。
subagent 検証でも同じ制約を守る。
検証 agent には、読んでよいファイル、作ってよい新規ファイル、読んではいけない既存 solver を明示する。
最終報告
最後に、次を簡潔に報告する。
- 作成または更新した解説ファイル
- 簡素化した solver がある場合、そのファイルと評価結果
- subagent 検証の有無、再実装 solver、評価コマンド、スコア
- subagent が読んだ解説ファイル、可能なら checksum、最終解説ファイルとの同一性
- 解説に残る曖昧点
- 本文へ反映した改善点
- 反映しなかったパラメータやケース固有情報と、その理由
