菜单
AHC形式のRust solverから、日本語の再現可能な解説を作る。入力としてチャンピオン実装や提出候補コードが与えられ、コード削除や簡素化で本質を抽出し、必要に応じてsubagentに解説だけから再実装と評価をさせ、japanese-tech-writingに従う技術解説へ仕上げるときに使用する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
AHC形式のRust solverから、日本語の再現可能な解説を作る。入力としてチャンピオン実装や提出候補コードが与えられたときに、Phase 1で削除や簡素化により本質を抽出し、Phase 2でjapanese-tech-writingに従う解説を書き、subagentに解説だけから再実装と評価をさせて品質を検証する。
Rust rollback/delta-state beam search templates for AHC-style solvers. Provides bundled Rust templates for Euler Tour edge traversal, linked-tree traversal, and variable-turn rollback beam search.
AHC形式のRust solverから、日本語の再現可能な解説を作る。入力としてチャンピオン実装や提出候補コードが与えられたときに、Phase 1で削除や簡素化により本質を抽出し、Phase 2でjapanese-tech-writingに従う解説を書き、subagentに解説だけから再実装と評価をさせて品質を検証する。
AHC形式のRustプロジェクトで、problem_description.txtを読み、v000_template.rsに入力・出力・State・操作適用の共通土台をユーザーと段階的に合意して実装する。solver戦略ではなく、問題ルールを安全かつ高速に扱う基盤設計を支援する。
AHC形式のRustプロジェクトで、problem_description.txt と公式 tools/src をもとに、同梱テンプレートから case visualizer / eval viewer / WASM 接続を完成させる。
Rust rollback/delta-state beam search templates for AHC-style solvers. Provides bundled Rust templates for Euler Tour edge traversal, linked-tree traversal, and variable-turn rollback beam search.
| name | explain-ahc-solver |
| description | AHC形式のRust solverから、日本語の再現可能な解説を作る。入力としてチャンピオン実装や提出候補コードが与えられ、コード削除や簡素化で本質を抽出し、必要に応じてsubagentに解説だけから再実装と評価をさせ、japanese-tech-writingに従う技術解説へ仕上げるときに使用する。 |
AHC solver の実装から、読者が方針を再現できる日本語解説を作る。
この skill は、実装をそのまま説明するためではなく、得点に効く構造を抽出して説明するために使う。
problem_description.txtnotes/notations.mdsrc/bin/v000_template.rsscripts/eval.py, scripts/run.sh, Cargo.tomljapanese-tech-writingjapanese-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 が読んだ検証対象本文と同一内容にする。 検証後に差分が残る場合は、表記ゆれ、誤字、句読点、リンク、意味を変えない言い換えのどれに当たるかを分類する。 分類できない差分がある場合は、再検証する。
最終報告では、検証対象本文と最終本文が同一内容かを確認する。 同一でない場合は、差分が意味を変えない編集だけである理由を書く。
新しい solver 候補を複数作って自動比較しない。 AI が作る新規 solver は、1 会話につき 1 本までにする。
複数候補を比較できるのは、ユーザーが明示した既存 solver だけである。
subagent 検証でも同じ制約を守る。 検証 agent には、読んでよいファイル、作ってよい新規ファイル、読んではいけない既存 solver を明示する。
最後に、次を簡潔に報告する。