| 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)。
- 入力形式や列挙は、構造が崩れにくい書き方を選ぶ。必要ならコードブロックを使う。
3. 転記する
- 本文はできるだけ原文のまま書く。不要な要約や解説を混ぜない。
- 図や色に依存する説明は、画像がなくても通る短い文章を追加する。
- 追加説明は
補足: と明示し、画像や与えられた文面から確実に読める内容だけを書く。
- 既存メモと混在させる必要がある場合でも、問題文部分と考察部分を分離する。
4. notes/notations.md を更新する
- 問題文から主要な入力記号、座標、集合、スコア、制約、状態量を抽出する。
notes/notations.md のテンプレ例を問題固有の記号へ置き換える。- コード上の代表名、Rust の想定型、制約・不変条件を分かる範囲で書く。
- 不明な型や命名は断定せず、未確定であることを明記する。
- 解法考察や仮説は
notes/notations.md へ混ぜない。
5. 最終確認する
- 固有値、制約、座標系、移動記号、評価条件を見直す。
図の通り だけで終わる説明が残っていれば最小限補う。
しないこと
- 解法考察や推測を問題文へ混ぜない。
- OCR の不確実な箇所を断定しない。
- 画像にない情報を創作しない。
- 別ファイルを増やさず、ユーザー指定がなければ project root の
problem_description.txt を更新する。
