architect

Architect

実装の前に設計します。型、関数シグネチャ、クラスの形、モジュール境界を、not implemented の本体と擬似コードを使ってスケッチします。複数のモデルの視点を統合してから、選んだスケッチに沿ってコードを埋めます。実装によってスケッチが誤りだと判明した場合は、スケッチを破棄して設計し直します。

開始

始める前に、各フェーズを1項目ずつ記した todo リストを作成します。チェックポイントなしの自律モードでは、現在のフェーズをリストで示し、フェーズがいつの間にか抜け落ちないようにします。

1. 問題の把握
2. スケッチ
3. 合意
4. 実装
5. 破棄

フェーズ A：問題を把握する

新しいコードが触れるすべてのシステムについて、実際のメンタルモデルを構築します。関連するサブシステムに対して how スキルを実行します。既存の構造が制約となる場合や、設計でその構造に異議を唱える必要がある場合は、批評モードを使用します。

ファイル名を挙げるだけでは、把握したことになりません。how が定める、追跡に基づくモデルを作成します。設計で所有権やレイヤー構造を再定義する場合は、既存の形状に対して why スキルも実行し、その根拠を推測ではなく制約として扱えるようにします。

周囲のシステムとの統合を必要としない、真にグリーンフィールドの作業である場合に限り、フェーズ A を省略します。

フェーズ B：スケッチ

フェーズ A の把握成果物と設計スケッチタスクを使って、arena スキルを実行します。各ランナーのプロンプトとして references/runner-prompt.md を渡します。各候補は references/rationale-template.md に沿った設計パッケージを作成します。設計パッケージでは、まず呼び出し側の使い方を示し、次に型のスケッチ、関数シグネチャ、モジュールマップ、その内容から導き出される説明を記します。

設定済みの architect ランナーを使用します（デフォルトは claude-opus-4-8-thinking-xhigh、gpt-5.5-high-fast、composer-2.5-fast）。

これは 設計空間を尽くす 原則スキルを具体化したものです。1つの形の中で部分的に修正するのではなく、全体の形が異なる代替案を検討します。

Arena は統合された設計パッケージを1つ返します。統合の判断は、理由付けの「Synthesis decision」セクションに記載します。

フェーズ C：合意（任意）

デフォルトでは、統合された設計を使ってそのまま実装に進みます。人間によるチェックポイントはありません。

呼び出し側が「/architect with checkpoint」「実装前に止めて見せて」など、明示的に求めた場合はチェックポイントを有効にします。その場合、統合された設計を提示し、承認を得るまで一時停止します。

どちらの場合も、統合結果を単独のコミットとして提出できます。これは foundational-thinking 原則スキルの「まず足場を固める」モードです。後続のコミットでは、安定した契約に沿って本体を埋めていく形になります。outcome-oriented-execution 原則スキルに従い、本体を埋める過程で、計画されスコープが定められた破壊的変更が生じても問題ありません。実装前に設計へ敵対的な圧力をかけるには、統合されたスケッチに対して interrogate スキルを実行します。

チェックポイント中またはその後に人間から設計の形状に異議が出た場合は、それをフェーズ A の証拠として扱います。改めて状況を把握し、コードをさらに書く前にフェーズ B を再実行します。

フェーズ D：スケッチに沿って実装する

not implemented の本体をコードに置き換え、擬似コードをロジックに置き換えます。統合されたスケッチが契約です。

スケッチからの逸脱は、黙って吸収するのではなく、表に出す価値のある兆候です。スケッチで想定されていなかったパラメーターが関数に必要になった場合は、スケッチが誤っていたのか、要件を見落としていたのか、実装が範囲を逸脱しているのかを確認します。表に出して検討し、勝手に付け足してはいけません。

フェーズ E：アーキテクチャが間違っているなら作り直す

実装を進めても、スケッチでは吸収できない摩擦が生じ続けるなら、スケッチは破棄してください。間違った設計に修正を継ぎ足すのではなく、redesign-from-first-principles と fix-root-causes の原則スキルに従ってください。

判断の手掛かりは、単発の事例ではなく パターン です。次のような兆候があります。

• 互いに無関係なコードで、同じ形の回避策が繰り返し現れる。
• 互いに無関係な複数のエッジケースすべてに、個別の分岐が必要になる。
• コンパイルするために、型に逃げ道（any、キャスト、実際には常に設定されるオプショナルフィールド）が必要になる。
• スケッチでは状態を共有しないとしていたのに、「ロックが必要だ」と反射的に考えてしまう。
• 抽象化を使うために、呼び出し側がその内部ルールを知る必要がある。
• 実装全体で、同じ形をしたフェーズ D からの独立した逸脱が 2 件以上ある。逸脱を明らかにするのはフェーズ D の役割です。同じパターンの逸脱が繰り返されることが、フェーズ E のきっかけになります。

判断は慎重に行ってください。いくつかのエッジケースがあるからといって、アーキテクチャが駄目になるわけではありません。本当に複雑な問題もあります。データの複雑さは、設計の複雑さではありません。作り直すべき兆候は、難しいケースが単発で現れることではなく、同じ形の摩擦が繰り返されることです。

破棄する場合：

1. how スキルを、構築したものに対して再度実行します。実装から得た教訓は、新しい設計の入力として取り入れ、単なる感覚にとどめないでください。
2. redesign-from-first-principles に従い、新しい制約が初日から前提だったかのように再設計します。
3. subtract-before-you-add の原則スキルに従い、追加する前に削ぎ落とします。新しいスケッチは、拡張する前の段階で古いものより小さくしてください。
4. フェーズ B に戻り、アリーナを再実行します。

成果物

まず呼び出し側の使用方法を記述し、そこから型のスケッチを導き出します。小規模な変更では、新しい型とシグネチャを 1 つのファイルにまとめます。大規模な変更では、モジュールマップと型定義を作成します。根拠は references/rationale-template.md に沿った形式で併せて提出し、使用方法のスケッチと統合に関する判断を含めます。