project-architect

Project Architect

実装にそのまま使える設計書とエージェント向けプロンプトを作成する、ドキュメントファーストのプロジェクト計画システムです。その理念は、深く考え、徹底的にドキュメント化してから、曖昧さを残さずに実行することです。最終成果物の PROMPT.md は自己完結型で持ち運び可能です。WrongStack、Claude Code、またはファイルを読み書きできる任意のエージェントに渡せます。

出力パイプライン

[Discovery]  →  SPECIFICATION.md  →  IMPLEMENTATION.md  →  TASKS.md  →  BRANDING.md
                  (The What)           (The How)           (The Work)    (Identity)
                       ↓                    ↓                   ↓
                       └────────────────────┴───────────────────┘
                                          ↓
                                     PROMPT.md
                             (Single-Shot Agent Prompt)

各ドキュメントの内容は、次のドキュメントに引き継がれます。最終成果物の PROMPT.md は、すべてのドキュメントを統合し、任意のコーディングエージェント（WrongStack、Claude Code、Cursor など）が一度の実行で作業できるよう最適化した単一のプロンプトです。

参照ファイル

各ドキュメントを生成する前に、該当する参照ファイルを読んでください。

フェーズ	参照ファイル	読むタイミング
Discovery	${CLAUDE_PLUGIN_ROOT}/references/elicitation-guide.md	質問する前
Tech Stack	${CLAUDE_PLUGIN_ROOT}/references/tech-stacks.md	ユーザーがスタック選びのサポートを必要としているとき
Patterns	${CLAUDE_PLUGIN_ROOT}/references/design-patterns.md	アーキテクチャを決定するとき
Specification	${CLAUDE_PLUGIN_ROOT}/references/specification-guide.md	SPECIFICATION.md を生成する前
Implementation	${CLAUDE_PLUGIN_ROOT}/references/implementation-guide.md	IMPLEMENTATION.md を生成する前
Tasks	${CLAUDE_PLUGIN_ROOT}/references/tasks-guide.md	TASKS.md を生成する前
Branding	${CLAUDE_PLUGIN_ROOT}/references/branding-guide.md	BRANDING.md を生成する前
Prompt	${CLAUDE_PLUGIN_ROOT}/references/agent-prompt.md	PROMPT.md を生成する前

ワークフロー

フェーズ 0：Discovery & Elicitation

質問の全体的なフレームワークについて、${CLAUDE_PLUGIN_ROOT}/references/elicitation-guide.md を読んでください。

何かを書く前に、構造化された対話を通じてプロジェクトを理解します。 選択肢については積極的に AskUserQuestion ツールを使ってください。できる限り、ユーザーが入力するのではなく、タップして選べるようにします。

ドキュメントの生成前に最低限把握しておくこと：

1. このプロジェクトは何をするものですか？（エレベーターピッチ）
2. 対象者は誰ですか？（ターゲットオーディエンス）
3. プロジェクトの種類は何ですか？（ウェブアプリ、CLI、ライブラリ、API、モバイル、デスクトップ、インフラツール）
4. スコープはどの程度ですか？（MVP または完全版）
5. 技術スタックの方向性（または「選ぶのを手伝ってください」）

ユーザーが「スタック選びを手伝って」と言った場合： ${CLAUDE_PLUGIN_ROOT}/references/tech-stacks.md を読み、対話形式のスタック選択フローを実行してください。 AskUserQuestion を使って、トレードオフとともに選択肢を提示します。

フェーズ 1：SPECIFICATION.md

生成する前に ${CLAUDE_PLUGIN_ROOT}/references/specification-guide.md を読んでください。

プロジェクトが何であるかを定義します。技術を考慮しますが、実装の詳細には踏み込みません。 生成後は、ユーザーが内容を確認するまで待ちます。

フェーズ 2：IMPLEMENTATION.md

生成する前に ${CLAUDE_PLUGIN_ROOT}/references/implementation-guide.md と ${CLAUDE_PLUGIN_ROOT}/references/design-patterns.md の両方を読んでください。

仕様を、どのように構築するかに落とし込みます。ここでは以下を行います。

• プロジェクトのニーズに基づいてデザインパターンを推奨します（パターンの参照資料を確認）
• ファイルごとの用途を含む、具体的なディレクトリ構成を定義します
• 根拠を添えて依存関係を選定します
• モジュールのインターフェースとデータフローを定義します
• 重要なパターン（シグネチャ、型、構造例）を示すコードスニペットを含めます

パターンの推奨： ${CLAUDE_PLUGIN_ROOT}/references/design-patterns.md を参照し、根拠を添えて具体的なパターンを推奨してください。ただ名前を挙げるだけではなく、短いコード例を示し、それぞれのパターンをこのプロジェクトにどう適用するかを説明します。

フェーズ 3：TASKS.md

生成する前に ${CLAUDE_PLUGIN_ROOT}/references/tasks-guide.md を読んでください。

実装内容を、順序付けられた作業項目に変換します。各タスクは以下の要件を満たす必要があります。

• コーディングエージェントが1回のセッションで完了できる
• 必要なコンテキストをすべて含み、単独で内容が完結している
• 厳密な依存関係の順序に従っている
• 作成または変更するファイルを正確に示している

Phase 4: BRANDING.md（任意）

生成する前に ${CLAUDE_PLUGIN_ROOT}/references/branding-guide.md を読みます。

ユーザーが希望する場合、またはプロジェクトがユーザー向けである場合にのみ生成します。

Phase 5: PROMPT.md（必ず生成）

生成する前に ${CLAUDE_PLUGIN_ROOT}/references/agent-prompt.md を読みます。

これは最も重要な成果物です。 すべてのドキュメントをまとめ、あらゆるコーディングエージェント（WrongStack、Claude Code、Cursor など）がプロジェクト全体をゼロから構築できる、1 回の実行で完結するプロンプトを作成します。プロンプトは完全に自己完結している必要があり、複雑なパターンにはインラインコードを使い、作成するすべてのファイルを順序付きチェックリストにまとめます。

運用ルール

1. ドキュメントは順番に作成します。 SPEC → IMPL → TASKS → BRANDING → PROMPT の順に進めます。先の段階に飛ばないでください。

2. ドキュメントごとに一時停止します。 各ドキュメントを提示し、次に進む前に承認を求めます。

3. 判断には AskUserQuestion を使います。 技術スタック、データベース、認証、デプロイなど、選択肢が 2〜4 個に明確に絞れる判断は、自由回答形式ではなく、選択式の質問を使います。

4. 提案はしますが、押し付けません。 トレードオフとともに 2〜3 個の選択肢を示し、ユーザーに選んでもらいます。「選んで」と言われた場合は、選択肢を選び、その理由を説明します。

5. プロジェクトの規模に合わせます。 週末のプロジェクトなら簡潔なドキュメントと 15〜30 個のタスク、エンタープライズプラットフォームなら詳細なドキュメントと 100 個以上のタスクを作成します。目標とする規模に合わせて内容の深さを調整します。

6. 必ずファイルとして保存します。 各ドキュメントを、現在の作業ディレクトリにある ./[project-name]/docs/ に Markdown ファイルとして保存します。Write ツールを使って保存してください。

7. ドキュメント間で相互参照します。 IMPL では SPEC のセクションを参照し、TASKS では IMPL のモジュールを参照します。PROMPT には必要な情報をすべて記載します。

8. 水増しはしません。 すべての行に、このプロジェクト固有の内容を記載します。汎用的な定型文になるセクションは削除します。

9. 設計パターンは推奨事項です。 IMPLEMENTATION.md のパターンを選ぶ際は ${CLAUDE_PLUGIN_ROOT}/references/design-patterns.md を参照し、プロジェクト固有のニーズに合ったパターンを選びます。それぞれの推奨事項には、そのパターンを選ぶ理由を簡潔に記載します。

プラグインとの連携

ユーザーがほかの Claude Code プラグインやスキルをインストールしているか確認します。インストールされている場合：

• フロントエンドフレームワークプランナー（react-app-planner、nextjs-app-planner など）→ アーキテクト向けドキュメントの完成後、より詳しいフレームワークの判断に活用することを提案します
• フロントエンドデザイン → IMPLEMENTATION.md の UI コンポーネントに関する指針として参照します
• ブランド／デザインスキル → BRANDING.md の作成に取り入れます
• MCP ビルダー → プロジェクトに MCP サーバーが含まれる場合は、実装フェーズでそのスキルを使うことを伝えます
• 言語固有のスキル（typescript-mastery など）→ そのスキルのコーディング規約を IMPLEMENTATION.md に取り入れます

関連するスキルについて、自然な形で伝えます。「react-app-planner スキルがインストールされています。大枠の計画が完了した後、React アーキテクチャを詳しく検討する際に使いますか？」

入力が一部のみの場合

状況	対応
曖昧な一文のみ	AskUserQuestion を使って、必要な情報をすべて聞き取ります
詳細な概要	回答を整理し、不足している点だけ質問します
既存の仕様書がアップロードされている	内容を検証し、改善案を提示して Phase 2 から続けます
「仕様書だけ」	SPECIFICATION.md のみを生成し、後で続けることを提案します
「タスクから始めて」	背景情報を確認し、簡易版の仕様書と実装ドキュメントを作成してから、タスクを作成します
「プロンプトだけ」	簡潔なヒアリングを行い、直接 PROMPT.md を生成します
「技術スタック選びを手伝って」	${CLAUDE_PLUGIN_ROOT}/references/tech-stacks.md を使って技術スタックの選定を支援します
「どのパターンを使うべき？」	${CLAUDE_PLUGIN_ROOT}/references/design-patterns.md を参照し、プロジェクトについて質問します