| name | write-problem-description |
| description | AtCoder Heuristic Contest の問題文を、貼り付けテキスト、スクリーンショット、公式抜粋から `problem_description.txt` に転記・整理する。公式の文言と節順をできるだけ維持し、画像がないと理解しづらい箇所だけ簡潔に補足する。 |
問題文転記
競技プログラミングの問題文を problem_description.txt に整理して保存する。原文の順序と wording を最大限維持し、画像依存の情報だけを最小限の補足で文章化する。
ワークフロー
1. 入力ソースを確認する
- ユーザーが貼ったテキストを優先し、画像は欠落部分の補完と図の説明把握に使う。
- 既存の
problem_description.txt を読み、追記か全面更新かを決める。
- 判読できない箇所や与えられていない節は推測で埋めない。
2. 構成を揃える
- 公式ページの節順を維持する。
- 少なくとも次を検討する: 問題名、実行時間制限、メモリ制限、問題文、得点、入力、出力、入力生成方法。
- 数式や添字は Markdown / plain text に正規化する。例:
t_i,j, p_i,j, (i,j)。
- 問題文本文では公式記号名を保持する。
N, M は N, M のまま書く。
- 添字だけは
h[i,j] のような配列表記にしてよい。
- 入力形式や列挙は、構造が崩れにくい書き方を選ぶ。必要ならコードブロックを使う。
3. 転記する
- 本文はできるだけ原文のまま書く。不要な要約や解説を混ぜない。
- 図や色に依存する説明は、画像がなくても通る短い文章を追加する。
- 追加説明は
補足: と明示し、画像や与えられた文面から確実に読める内容だけを書く。
- 既存メモと混在させる必要がある場合でも、問題文部分と考察部分を分離する。
4. notes/notations.md を更新する
- 問題文から主要な入力記号、座標、集合、スコア、制約、状態量を抽出する。
notes/notations.md のテンプレ例を問題固有の記号へ置き換える。- 公式記号名は保持する。
N, M, S などの大文字小文字は Rust の命名規約より優先する。
- 添字は 0-based か 1-based かを明記し、実装・会話用には原則 0-based の
a[i], h[i,j] 形式を使う。
- 問題文にない実装用の状態量は、
state[g], X[p,g] のようにコードとの対応が見える名前にする。
- コード上の代表名、Rust の想定型、index 範囲・不変条件を分かる範囲で書く。
- 不明な型や命名は断定せず、未確定であることを明記する。
- TeX は数式構造だけに使い、コードフェンス内に入れない。
- 解法考察や仮説は
notes/notations.md へ混ぜない。
5. 最終確認する
- 固有値、制約、座標系、移動記号、評価条件を見直す。
図の通り だけで終わる説明が残っていれば最小限補う。
しないこと
- 解法考察や推測を問題文へ混ぜない。
- OCR の不確実な箇所を断定しない。
- 画像にない情報を創作しない。
- 別ファイルを増やさず、ユーザー指定がなければ project root の
problem_description.txt を更新する。
