architect

Architect

Codex では、このスキルに従う前に、スキルごとの注記を含めてプラットフォーム対応表を読んでください。

GitHub Copilot では、このスキルに従う前に、スキルごとの注記を含めてプラットフォーム対応表を読んでください。

Muse では、このスキルに従う前に、スキルごとの注記を含めてプラットフォーム対応表を読んでください。

型、関数シグネチャ、クラスの形、モジュール境界を、本文を not implemented としたうえで、擬似コードも使ってスケッチしてください。複数のモデルの視点を統合してから、選んだスケッチに基づいてコードを埋めてください。

開始

作業を始める前に、各フェーズを1項目ずつ記載したToDoリストを作成してください。

1. グラウンディング
2. スケッチ
3. 合意
4. 実装
5. 破棄

フェーズA：問題のグラウンディング

新しいコードが関わるすべてのシステムについて、実態に即したメンタルモデルを構築してください。関連するサブシステムに対して how スキルを実行してください。ファイル名を挙げるだけではグラウンディングになりません。how が定めるアーキテクチャの説明を作成してください。設計によって所有権やレイヤリングを再定義する場合は、既存の構造に対して why スキルも実行し、その根拠を推測ではなく制約として扱えるようにしてください。

周辺システムとの統合が不要な、真にグリーンフィールドな作業の場合に限り、フェーズAを省略できます。

フェーズB：スケッチ

デザインスケッチのタスクとフェーズAのグラウンディング成果物を使って arena スキルを実行してください。各ランナーのプロンプトとして references/runner-prompt.md を渡してください。

pstack-models.md の architect runners 行に記載されたランナーを使い、arena runners 行の記載に代えてください。シートまたはその行がない場合は、Models のデフォルトを使用してください。エイリアスおよび却下された項目には、arena スキルのフェーズAにあるランナールールを適用してください。

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

すべての候補を統合前に references/design-red-flags.md に照らして確認してください。次の貢献者は、開いたファイルだけを参照し、最も近い例をコピーして、コンパイルできる最短経路を選ぶエージェントだと想定してください。1つのファイルだけを見れば正しく思える変更が、リポジトリ全体でも正しい設計を優先してください。

実行可能な候補をインターフェースの深さで比較してください。より多くの複雑さを、より小さく簡潔なパブリックインターフェースの背後に隠せる設計を優先してください。機能をレイヤー間に分散させず集約すれば、豊富なインターフェースでも呼び出しチェーンを短くできます。

Arena は統合済みの設計パッケージを1つ返します。その統合に関する判断を、根拠の「Synthesis decision」セクションに記載してください。

フェーズC：合意（オプトイン）

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

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

いずれの場合も、foundational-thinking 原則スキルの「scaffold first」モードとして、統合結果を独立したコミットにできます。outcome-oriented-execution 原則スキルに従い、埋め込み作業中に、計画と範囲が明確な変更によってコードが一時的に動作しなくなることは問題ありません。実装前に設計へ敵対的な視点から圧力をかけるには、統合済みのスケッチに対して interrogate スキルを実行してください。

人間がチェックポイント中またはその後に構造へ異議を唱えた場合、それをフェーズAの証拠として扱ってください。再度グラウンディングを行い、さらにコードを書く前にフェーズBを再実行してください。

フェーズ D：スケッチに基づいて実装する

not implemented の本体をコードに置き換え、擬似コードをロジックに置き換えます。統合されたスケッチが契約です。スケッチからの逸脱は、暗黙に吸収するのではなく、明らかにすべき兆候です。スケッチで想定されていないパラメーターが関数に必要になった場合は、スケッチが間違っていたのか、要件が漏れていたのか、実装が範囲を超えているのかを確認してください。

各実装単位を完了する前、またはその契約を次の作業者に引き渡す前に、受け入れられた逸脱を、保存済みの振る舞いの契約、インターフェイス、責任の割り当てと照合します。適切な担当者またはレビューのプロセスが変更を承認したら、既存のスケッチと根拠の該当箇所を更新します。その承認元も記録してください。エラーを発生させる仕様から拒否を返す仕様に変更する場合は、次の単位を開始する前に結果の契約を更新する必要があります。

共有契約に影響しない局所的な逸脱については、設計が依然として成立する理由とともに判断を記録します。局所変数の名前変更でアーキテクチャを書き直す必要はありません。未承認の変更や未解決の意見の相違は、見える状態にしておきます。次の作業者に矛盾する指示が渡る状態では、単位の調整が完了したと見なさないでください。また、実装を正当化するためだけに仕様を編集してはいけません。単位ごとに並行する記録を作るのではなく、既存の設計成果物を使ってください。構造上の逸脱が繰り返される場合は、フェーズ E も実行してください。

フェーズ 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 に沿って、使用方法のスケッチと統合時の判断を含めて併せて提出します。

モデル

ロールの既定値は plugins/pstack/models.json から取得され、スタンプされます（そこを編集し、tools/generate.mjs を再実行してください）。pstack-models.md オーバーライドシートに同じロールの行があれば、実行時に各既定値を上書きします。/setup-pstack はそのシートを書き込み、ランタイムごとにパスを表示します。

• architect runners：opus、fable、sonnet、haiku

推論の強度

オーバーライドシートのロール値では、opus @xhigh のように、モデルの後に推論の強度を指定できます。Claude Code で指定できるレベルは、low、medium、high、xhigh、max です。どのレベルを使用できるかは、モデルによって異なります。@ を含まない値では、シートの default effort 行に指定されたレベル、または session を使用します。その行がない場合も session を使用します。session は推論の強度を指定しないため、通常どおりディスパッチされます。モデルを読み取る前にサフィックスを取り除いてください。inherit-parent または auto では、どのレベルでも model を省略し、モデル名は model として渡します。レベルはディスパッチの推論の強度フィールドに渡し、それ以外は通常使用する subagent_type を維持してください。Claude Code の Agent 呼び出しでは effort、Codex の spawn_agent では reasoning_effort を指定します。Muse では、Workflow の子に effort を指定します。subagent_spawn ディスパッチでは、セッションの推論の強度が維持されます。