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 に定める形式の設計パッケージを作成します。

arena runners の行の代わりに、pstack-models.mdc ルール内の architect runners の行に記載されたランナーを使います。ルールまたは該当する行がない場合は、claude-opus-5-5-max、gpt-5.6-sol-max、grok-4.7-xhigh-fast を使います。エイリアスと却下されたエントリーは、arena スキルのフェーズAにあるランナーのルールに従います。

設計を2回行います。最初の候補で十分だと思えても、統合の前に、構造的に異なる候補を少なくとも2つ用意します。これは exhaust-the-design-space 原則スキルを具体化したものです。1つの形の中で部分的に修正するのではなく、全体構造の異なる案を用意します。

統合の前に、すべての候補を references/design-red-flags.md に照らして確認します。浅いモジュール、情報漏えい、時間軸に基づく分割、単なる受け渡しメソッドを含む候補は、却下するか修正します。

有望な候補をインターフェースの深さで比較します。より多くの複雑さを、より小さくシンプルな公開インターフェースの背後に隠せる設計を優先します。豊富なインターフェースは、レイヤー間に機能を分散させるのではなく、機能を集約することで、呼び出しチェーンを短くできます。

Arena は、統合済みの設計パッケージを1つ返します。統合時の判断は、根拠書の「統合時の判断」セクションに反映されます。

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

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

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

どちらの場合も、統合結果は foundational-thinking 原則スキルの「scaffold first」モードに従い、単独のコミットとして反映できます。outcome-oriented-execution 原則スキルに従い、埋め込み作業中に計画され、範囲が定められた破壊的変更は問題ありません。実装前に設計へ厳しい検証を加えるには、統合済みのスケッチに interrogate スキルを適用します。

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

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

not implemented の本文をコードに置き換え、擬似コードをロジックに置き換えます。統合済みのスケッチを契約とします。

スケッチからの逸脱は、黙って吸収するのではなく、明らかにする価値のある兆候です。スケッチで想定していなかったパラメーターが関数に必要になった場合は、スケッチに誤りがあったのか、要件を見落としたのか、それとも実装が過剰になっているのかを確認します。

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

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

判断の手がかりとなるのは、単発の事例ではなく、パターンです。次の点に注目してください。

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

判断は慎重に行ってください。いくつかのエッジケースだけで、アーキテクチャが誤りだとは限りません。問題によっては、正当に複雑な場合もあります。データの複雑さは、設計の複雑さとは異なります。

作り直す場合は、次の手順に従ってください。

1. これまでに構築したものを対象に、how スキルを再実行します。
2. 新しい制約が初日から前提だったかのように、redesign-from-first-principles に従って再設計します。
3. subtract-before-you-add の原則スキルに従い、追加する前に削ります。新しいスケッチは、発展させる前に古いものより小さくしてください。
4. フェーズ B に戻り、arena を再実行します。

成果物

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