reforge

Reforge

現在、reforge の導入フェーズを実行しています。あなたの役割は、プロトタイプや PoC から 意図 と 教訓 を抽出し、その実装を破棄することです。出力される reforge-seed.md は、新しい本番品質のリポジトリを作成するための、新たな architect セッションに引き継がれます。プロトタイプを改善するのではありません。知見を掘り起こし、新しいシステムが有利な状態でスタートできるようにします。

ヘルパースクリプトの実行

このスキルのヘルパースクリプトは、独自の scripts/ ディレクトリ（この SKILL.md と一緒にインストールされています）に含まれています。SKILL_DIR にこのスキルの絶対パスを設定してください。このファイルの末尾に このスキルのベースディレクトリ として記載されています。その後、プロジェクトのルートからスクリプトを実行します（プロジェクトの .changes/ と CONTEXT.md ファイルを操作します）。

SKILL_DIR="<absolute path to this skill's directory>"

以下の node "$SKILL_DIR/scripts/..." コマンドは、すべてこれに依存します。packages/build/ は参照しないでください。このパスはツールキットの開発用リポジトリにのみ存在し、インストール済みのスキルには存在しません。

基本姿勢

意図的に取捨選択します。次の点を見極めます。

• プロトタイプが実証したこと。 どの機能が動作し、本番環境にも引き継ぐ必要があるか。
• プロトタイプが明らかにしたこと。 作成者が予期していなかった複雑さ、エッジケース、障害モード。
• 引き継いではならないこと。 実装上の近道、誤った抽象化、偶発的なパターン。

率直さが求められます。PoC の作成者は、プロトタイプのパターンに引きずられがちです。実装の先にある根本的な意図を見抜くことが、あなたの役割です。

事前確認

調査、サブエージェントの起動、参考資料の確認を始める前に、目標と観測可能な成果、影響を受ける領域、制約とアンチゴール、要件が具体化済みか、一部具体化済みか、未具体化かを確認します。回答をもとに PoC の調査範囲を定めます。

フェーズ 1：PoC を理解する

調査用サブエージェントを実行して、プロトタイプを理解します。目的は記録を作ることではなく、意図を抽出することです。

調査エージェント 1 — 機能：

「このコードベースを調査してください。何をするものですか？ 実装ではなく、ユーザーやシステムの動作と成果の観点から、その機能を説明してください。どのような問題を解決しますか？ 明確に対象外としていることは何ですか？」

調査エージェント 2 — ドメインの複雑さ：

「このコードベースを調査してください。解決が最も難しかった問題は何ですか？ コードが最も複雑な箇所や、コメントが最も多い箇所はどこですか？ 実装が処理しているエッジケースは何ですか？ 対応を見送ったと思われるエッジケースは何ですか？ 本番環境の負荷や実際のユーザーの利用で、何が問題になりますか？」

調査エージェント 3 — 実装品質：

「このコードベースを調査してください。どのような実装上の近道が使われていますか？ 明らかに PoC 品質のパターン（ハードコードされた値、検証の省略、エラーハンドリングの不足、単一ユーザー前提）は何ですか？ 誤っている、または偶発的に生じたと思われる抽象化は何ですか？ 最初に書き直すべき箇所はどこですか？」

調査結果を提示し、シードを作成する前にユーザーと話し合います。

Phase 2：インタビュー — 意図と教訓

これは短く、要点を絞ったインタビューです。目的は、ユーザー自身の知見によって、調査で得た知見を確認し、さらに深めることです。

質問（1つずつ尋ね、回答に疑問を投げかけます）：

1. PoC の機能のうち、本番システムに必ず備えるべきものは何ですか？（具体的に列挙してください。）
2. 検証したものの、本番システムには含めるべきでない機能は何ですか？（非目標）
3. PoC の構築で学んだ、最も意外だったことは何ですか？
4. 今日からやり直すとしたら、何を根本的に変えますか？
5. PoC にあるドメイン用語や概念のうち、適切に命名されているものはありますか？（これらは用語集に引き継ぎます。）
6. PoC にあるドメイン用語や概念のうち、誤った名前が付けられているもの、または誤ってモデル化されているものはありますか？（これらは新しいシステムで修正する必要があります。）
7. PoC では扱わなかった、本番システムが満たすべき受け入れ基準は何ですか？
8. 本番システムの対象言語／スタックは何ですか？（慣用的な実装パターンを把握するために使います。）

曖昧な回答には具体性を求めます。「アーキテクチャをリファクタリングしたい」では回答になりません。「イベントループのモデルは X が原因で誤っていたので、代わりに Y を使う」が回答です。

対象言語が判明したら、idioms スキルを使って対応するパックを読み込み、実装上のアンチパターンと提案されている本番環境への方向性について、さらに具体性を求めます。対応するパックがインストールされていない場合は、その旨を伝え、パックの指針があると決めつけずに、対象エコシステムで確立された規約やツールを使用します。

Phase 3：reforge-seed.md を作成する

references/templates/reforge-seed.md.tmpl を埋めます。具体的かつ明確な見解を示してください。曖昧なシードからは曖昧なアーキテクチャが生まれます。

慎重に記入する項目：

• 機能上の意図 — 実装方法ではなく、動作と成果を記載します
• 維持必須の機能 — 一般論ではなく具体的に記載します
• 非目標 — 明確にし、その理由を説明します
• 学んだ教訓 — 最も価値のある成果です。実行可能な具体性を持たせます
• 避けるべき実装上のアンチパターン — それぞれ「なぜ問題だったのか、代わりに何をするのか」を対にして記載します
• 既知のドメインの複雑さ — 本番環境でも再び難しくなることを記載します
• 大まかな受け入れ基準 — アーキテクトセッション向けの、行動に関する高水準の要件です
• アーキテクトセッションへの質問 — PoC で浮かび上がったものの、回答されなかった未解決の質問です

保存先：任意の場所を選びます（reforge seed は進行中の変更アーティファクトではなく、出発点です）。

推奨パス：新しいプロジェクトの将来のルートにある reforge-seed.md、またはユーザーが移動できる一時ファイル。

Phase 4：アーキテクトに引き継ぐ

シードをユーザーに提示し、内容を確認します。次の点を確認してください。

• 機能の一覧に漏れがないこと。
• 非目標が率直に記載されていること。
• 学んだ教訓が、アーキテクトで実行可能な課題として扱えるほど具体的であること。
• アーキテクトセッションへの質問が、実際に解決されていない課題であること。

その後、次のように伝えます。

「reforge seed の準備ができました。本番システム用の新しいリポジトリを作成し、そこでこのシードを参照して architect を実行してください。アーキテクトセッションでは、大まかな受け入れ基準と質問を出発点となる課題として使用します。」

対象言語が判明している場合は、次のように伝えます。

「アーキテクトの変更マニフェストを作成するときに manifest.language = <lang> を設定すると、idioms パックが読み込まれます。」

reforge が行わないこと

• CONTEXT.md は作成しません（新しいリポジトリにはまだコードがありません。最初の実装サイクル後に architect が作成するか、最初の動作するバージョンができた後に map が作成します）。
• architect 自体は実行しません。シードを準備するだけです。ユーザーが先に新しいリポジトリを作成します。
• PoC の実装コードを引き継ぐことは提案しません。コードを移植するかどうかはユーザーが決めます。移植を希望する場合は、シードに具体的な質問として記載します。

参考ファイル

• references/templates/reforge-seed.md.tmpl
• references/templates/CONTEXT.md.tmpl — architect が作成するものを参照するため
• references/challenge-protocol.md
• idioms スキル — 対象言語が判明している場合