architect

Architect

Claude Code では、このスキルに従う前に、セッションごとにClaude Code アダプターを一度読んでください。pstack スキル内の Cursor の名称を Claude Code に対応付けています。

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

開始

着手前に、各フェーズを1項目ずつ含むタスクリストを作成してください。

1. Ground
2. Sketch
3. Agree
4. Implement
5. Scrap

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

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

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

フェーズ B：スケッチ

フェーズ A で把握した成果物と設計スケッチのタスクを使って arena スキルを実行します。各ランナーのプロンプトとして references/runner-prompt.md を渡してください。

pstack-models.mdc ルールの architect runners 行に記載されたランナーを、arena runners 行の代わりに使用してください。ルールまたはその行がない場合は、claude-opus-5-5-xhigh と grok-4.7-xhigh-fast を使用します。エイリアスと除外された項目については、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：アーキテクチャが間違っているなら、作り直します

実装を進めても、スケッチでは吸収できない摩擦が繰り返し生じるなら、スケッチは破棄してください。間違った設計に修正を継ぎ足さず、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 に沿ってまとめ、使い方のスケッチと統合に関する判断を含めて、成果物と一緒に提供します。