re0-plan

.re0/iteration/<version>-<workname>/ を開き、re0-loop のサイクルが一行でも実行される前に、同じ作業の中でファイルを書き込みます。

目標

書かれた論点、ゲート一覧、ステップ計画がないサイクルは、最初に持ち出された枠組みへと流されてしまいます。また、何も入っていないフォルダーを開いても、再開したセッションには何も伝わりません。re0-plan は両方の問題を一度に解消します。サイクルでどの重み付けになっても、フォルダーは作成された時点から空ではありません。このスキルは、paperthin パッケージ一式がインストール済みであることを前提とし、兄弟スキルを直接指定します。フォルダーを閉じる re0-release と連携し、このスキルが用意した内容を最初からやり直すのではなく拡張する re0-memo とも連携します。これは汎用的な計画手法ではありません。書き込む形式は、このリポジトリ独自の規約です。

ワークフロー

1. サイクルの重み付けを分類します。実質的な設計の余地がない修正や強化作業は軽量です。議論する価値のある方向性があるサイクルはフルです。
2. .re0/iteration/<version>-<workname>/ を作成し、同じ手順の中で最初のファイルを書き込みます。重み付けに応じて、ファイルを選びます。
   • 軽量 → RETRO.local.md：タスクと、軽量である理由を記した段落を1つ書きます。最後に re0-memo がこの同じファイルを拡張します。新しいファイルを作成することはありません。ここで終了します。
   • フル → DESIGN.local.md：論点、スコープ、品質ゲートを記載します。これは re0-loop の FRAME ターンが求める内容と同じで、セッションが中断されても単独で内容を維持できるだけの情報を含みます。変更が出荷可能な領域に関わる場合、ゲートには必ず AGENTS.md／README の反映確認ゲートを含めます（「ルール」を参照）。readchk で読み取りを確認し、modelchk でティアを見積もります。方向性について本当に判断が分かれる場合に限り、macrothink または別の判断スキルを利用します。
3. （フルのみ）WORKFLOW.local.md を作成します。このビルド固有の手順を、re0-loop のターン順に沿って番号付きで記載します。re0-loop の汎用的なステージを言い換えただけのものにはしません。
4. （フルのみ）EVIDENCE.local.md を作成します。DESIGN.local.md のゲートを、これから埋めるべき証明項目として列挙します。記載するのは基準であり、結果ではありません。
5. 参照資料は REF-<topic>.local.md としてフラットに保ちます。ファイルが2、3個を超えて増えてから、refs/ サブフォルダーに移します。
6. re0-loop に引き継ぎます。ここでは re0-work を呼び出しません。最初からの再開は re0-loop 自身がサイクル途中で呼び出すもので、必要に応じて nba が提示します。セットアップ手順ではありません。

ルール

• フォルダーは作成時に空ではありません。 簡易パスでもフルパスでも、フォルダーの作成と同時に実際の内容を書き込むため、どの時点でセッションが中断しても、そこから再開できます。
• 意図的にポータブルではありません。 他の paperthin スキルを直接参照し、パッケージ全体がインストールされていることを前提とします。このフォルダーにある他のすべてのスキルが従う、自己完結型のデフォルトとは正反対です。これは re0-release および re0-memo と組み合わせるためだけのもので、単独で持ち運ぶものではありません。
• 水増しはしません。 簡易版に DESIGN／WORKFLOW／EVIDENCE は付けず、RETRO.local.md の初期記述は1段落にとどめます。これはタスクのメモであり、WORKFLOW.local.md を装ったものではありません。判断スキルや re0-work を「念のため」無理に追加することもありません。
• フォルダーの <version> は暫定的です。 re0-release と同じマイナー／パッチの判定基準を適用してください。大きさではなく種類で判断します。つまり、成果物のそれ以前の仕様と比べて、この変更は修正（パッチ）なのか、それともユーザーが新たに必要とする機能（マイナー）なのか、ということです。また、サイクルで発生した未解決の分岐があれば、それに応じて変更してください。サイクルで正当化されていない確定的なバージョン更新を、決して事前に決めないでください。スキルを追加する可能性のある分岐がある場合、その分岐が解決するまでは更新を未決定にします。
• ドキュメントは re0-release のリリース時と同様に整合させます。 サイクルでの変更がリリース対象の範囲に及ぶ場合、品質ゲートには必ず AGENTS.md/README の反映ゲートを含め、AGENTS.md のドキュメントの役割分担に従って、各反映先を割り当ててください。内部の仕組み／ルール／構造 → AGENTS.md（LLM と人間向け。指示として注入されます）、ユーザー向けのカタログ／利用体験 → README（人間向けのみ。注入されることはありません）。エージェントへの指示に関する仕組みを README に記載してはならず、ユーザー向けの変更で README への反映を省略してもいけません。これは、re0-release のリリース時の README 手順を補完する計画段階の対応です。
• negatives-as-corpus — このスキルや、このスキルが開始するサイクルで生成されたものは削除しません。うまくいかなかったサイクルは、破棄するのではなく re0-release で退役させます。
• EVIDENCE.local.md の各ゲートは、DESIGN.local.md の該当行に必ず紐付けてください。DESIGN が求めていない証拠の提示を新たに求めてはいけません。

検証

完了前に、以下を確認してください。

1. どちらのパスでも、フォルダーは存在した時点から実際の内容を含んでおり、空のディレクトリがないこと。
2. フルパスの場合：DESIGN.local.md に主旨、範囲、ゲートが記されていること。WORKFLOW.local.md の手順がこのサイクルに固有であること。EVIDENCE.local.md のすべてのゲートが DESIGN.local.md に紐付いていること。
3. 簡易パスの場合：RETRO.local.md の初期記述に、タスクと理由が1段落で記されていること。
4. 根拠がない限り、参考資料がフラットな構成のままであり、refs/ サブフォルダーを追加していないこと。
5. どのパスを選んだか、その理由とともに報告すること。