write-problem-description

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 を更新する。