manifest-generator

ManifestGenerator

プロジェクトの説明を受け取り、現在のディレクトリに次の2つのファイルを生成します。

1. PROJECT_MANIFEST.md — すべてのファクトリーエージェントが読み込む、構造化されたプロジェクトコンテキスト
2. SOFTWARE_FACTORY_MANIFEST.md — 6エージェントによる SDLC パイプラインの設計図

各フェーズを順番に実行してください。フェーズを省略しないでください。必要な入力を得るまで、STOP の先へ進まないでください。

---

FILE_WRITE_GUARD

出力ファイルのいずれかを書き込む前に、この手順を呼び出してください。実際のファイル名に置き換えてください。

FILE_WRITE_GUARD(filename):
  現在のディレクトリにfilenameが存在するか確認する（Read ツールを使用）。
  存在する場合：
    ユーザーに「filename はすでに存在します。上書き、filename.bak に名前を変更、または中止しますか？」と尋ねる。
    上書き → 続行する。
    名前を変更 → 既存のファイル名をfilename.bakに変更してから続行する。
    中止 → 実行を完全に停止する。
  存在しない場合 → 書き込みに進む。

---

Phase 0: Resume Detection

何よりも先に、既存の出力ファイルを確認してください（Read ツールを使用します。存在しない場合は通常どおり「file not found」エラーが返されます）。

1. 現在のディレクトリに PROJECT_MANIFEST.md はありますか？
2. 現在のディレクトリに SOFTWARE_FACTORY_MANIFEST.md はありますか？

両方とも存在しない場合： Phase 1 に進みます。

PROJECT_MANIFEST.md は存在し、SOFTWARE_FACTORY_MANIFEST.md は存在しない場合： PROJECT_MANIFEST.md をコンテキストに読み込みます。Phases 1–5 をスキップします。 ユーザーに「既存の PROJECT_MANIFEST.md が見つかりました — ファクトリーマニフェストの生成に進みます。」と伝えます。 Phase 6 に進みます。

両方とも存在する場合： ユーザーに「両方の出力ファイルがすでに存在します。最初から再生成しますか、それとも中止しますか？」と尋ねます。 再生成 → Phase 1 に進みます（FILE_WRITE_GUARD が上書きを処理します）。 中止 → 停止します。

---

Phase 1: Accept Input

ランタイム検出プローブ： 以下の質問で AskUserQuestion の呼び出しを試みます。 成功した場合 → 対話モード：以降のすべてのフェーズで AskUserQuestion を一問ずつ使用します。失敗した場合（ツールが見つからない場合）→ テキストモード：以降のすべてのフェーズで、未回答の質問を番号付きリストとして表示し、ユーザーの回答を待ってから続行します。

入力チェック（最初の質問／プローブ）：

ユーザーの現在のメッセージまたは呼び出し引数を確認します。

• ファイルパス（例：PROJECT_OVERVIEW.md）が含まれている場合：Read ツールで読み込みます。
  • ファイルが見つからない → ユーザーに伝え、説明を直接貼り付けるよう求めます。STOP。
  • ファイルは見つかったがテキストではないように見える（JSON、バイナリ、package.json など）→ ユーザーに「そのファイルはプロジェクトの説明には見えません。」と伝え、テキストを直接入力するよう求めます。STOP。
  • ファイルが見つかり、テキストである → その内容を説明として使用します。
• プロジェクトの説明（何を構築するかに関する複数の文）が含まれている場合：その内容を使用します。
• どちらも含まれていない場合：「プロジェクトの説明を貼り付けるか、構築するものについて説明してください。何をするものか、誰が使うか、選定済みの技術スタック、制約があれば含めてください。」と尋ねます。

STOP。説明がコンテキストに含まれるまで先へ進まないでください。

---

フェーズ 2：抽出

説明を 11 個の PROJECT_MANIFEST セクションに照らし合わせてください。各セクションに、次のいずれかを割り当てます。

• 抽出済み — プロジェクトに固有の具体的な内容がある（実際の技術名、実際のユーザーロール、具体的な制約、固有名詞）
• 一部あり — 内容はあるが、不完全または曖昧
• 不足 — 関連する内容が見つからない

各セクションで「抽出済み」がどのような状態か判断する際は、WORKED EXAMPLE（このファイルの末尾、HTML コメントマーカーの間）を参考にしてください。例の内容を出力に使用しないでください。

必ず質問するセクション — 「一部あり」または「不足」の場合は質問し、決してデフォルト値を設定しないでください。

セクション 1：概要
セクション 2：技術スタック
セクション 4：ドメインモデル ← 最重要。デフォルト値を生成しないでください
セクション 6：制約
セクション 9：成功基準

デフォルト値を設定できるセクション — 内容が「不足」している場合は、コンテキストに基づいて生成し、ラベルを付けてください。

セクション 3：プロジェクト構成
  → 技術スタックから推測
  → ラベル：(proposed — update when scaffolded)

セクション 5：規約
  → 技術スタックから推測（例：Node.js → kebab-case のファイル名、*.test.ts、
    conventional commits、Python → snake_case、test_*.py など）
  → ラベル：(default — update when scaffolded)

セクション 7：タスク入力
  → ドメインモデルと固定されたパイプライン順序から導出
  → ラベル：(pipeline-critical — verify before running factory)
  → 注意：ドメインモデルが弱いとタスク入力も弱くなります。これはパイプラインの順序を崩します。

セクション 8：接続するサービス
  → 言及がなければ空の表

セクション 10：レビュー基準
  → 検出した技術スタックに適した一般的なルール
  → ラベル：(default — customize for this project)

セクション 11：リリース基準
  → プロジェクトの種類に適した一般的なチェックリスト
  → ラベル：(default — customize for this project)

マッピング後、「必ず質問するセクション」のうち、「一部あり」または「不足」となっているものを特定してください。 フェーズ 3 に進んでください。

---

フェーズ 3：不足情報の補完

「一部あり」または「不足」となっている「必ず質問するセクション」ごとに、的を絞った質問を 1 つしてください。 質問の順序は、概要 → 技術スタック → ドメインモデル → 制約 → 成功基準です。

対話モード： AskUserQuestion を使用し、1 回の呼び出しにつき質問は 1 つにします。次の質問をする前に、回答を待ってください。

テキストモード： 保留中の質問をすべて番号付きリストで表示します。続行する前に、すべての質問に対する回答を待ってください。

すでに「抽出済み」のセクションについては、質問しないでください。

ドメインモデルの特別ルール： ドメインモデルの回答にエンティティ名が含まれていない場合（「データを管理する」「ユーザーがいる」など、曖昧な文が 1 つだけの場合）は、次の追加質問を 1 つしてください。 「中核となるデータエンティティの名前を挙げられますか？ 例：Order、Customer、Staff — システムが追跡して保存する主な『もの』です。」 2 回目の回答は、内容にかかわらず受け入れてください。それでもエンティティ名がない場合は、「入力済み」として扱いますが、ラベル (weak — strengthen Section 4 before running factory) を追加してください。

停止してください。「必ず質問するセクション」がすべて「入力済み」になるまで先に進まないでください。

---

フェーズ 4：検証

11 個すべてのセクションを確認してください。次のいずれかに該当する場合、そのセクションはプレースホルダーです。

• 空である
• 編集されていないテンプレート文（例：[Core entities, their fields...]）が含まれている
• どのプロジェクトにも当てはまる一般的な内容しか含まれていない

プレースホルダーのままの「デフォルト値を設定できるセクション」については、妥当なデフォルト値を生成し、(generated — verify before use) とラベルを付けてください。

プレースホルダーのままの「必ず質問するセクション」については、本来そのような状態にならないはずです（フェーズ 3 で確認済みのため）。万一そうなっていた場合は、ここで的を絞った質問を 1 つしてください。

フェーズ 5 に進んでください。

---

フェーズ 5：PROJECT_MANIFEST.md の作成

FILE_WRITE_GUARD("PROJECT_MANIFEST.md") を呼び出してください。

Write ツールを使い、現在のディレクトリに PROJECT_MANIFEST.md を作成してください。 以下のスキーマセクションで定義されている PROJECT_MANIFEST テンプレートを使用してください。 すべてのセクションを埋めてください。空のセクションやテンプレートのプレースホルダーテキストが残っていてはいけません。

次のように報告してください：「PROJECT_MANIFEST.md を作成しました。説明から N/11 個のセクションを抽出し、Q&A で M 個を入力し、K 個をデフォルト値として生成しました。」

---

フェーズ 6：SOFTWARE_FACTORY_MANIFEST を生成する

コンテキスト内にすでにある PROJECT_MANIFEST の内容を使用します（フェーズ 5 で生成済み、またはフェーズ 0 の再開時に読み込み済み）。ディスクから再読み込みしないでください。

SOFTWARE_FACTORY_MANIFEST の 7 つのセクションを記入します。

セクション 1 — ファクトリー概要 1 段落で、プロジェクト名＋「このファクトリーは 6 エージェントの逐次パイプラインを実行します...」＋プロジェクトマニフェストに基づく技術スタックの概要を記載します。

セクション 2 — パイプラインの順序 固定の 6 エージェントの順序です。プロジェクト名を小文字にし、ハイフンでつないだものを として使用します。

1. Planner
   読み込み：  機能リクエスト + PROJECT_MANIFEST.md
   書き込み：  work-packages/<slug>.md

2. Architect
   読み込み：  Planner のワークパッケージ + PROJECT_MANIFEST.md の Tech Stack セクション
   書き込み：  docs/adr/NNNN-<slug>.md

3. Designer
   読み込み：  Architect の ADR + PROJECT_MANIFEST.md の Domain Model セクション
   書き込み：  design/<slug>-spec.md

4. Coder
   読み込み：  Designer の仕様書 + PROJECT_MANIFEST.md の Conventions セクション
   書き込み：  機能ブランチ <slug>-<feature> の src/

5. Reviewer
   読み込み：  コード差分 + PROJECT_MANIFEST.md の Review Standards セクション
   書き込み：  review-reports/<slug>-review.md

6. Deployer
   読み込み：  Reviewer のレポート + PROJECT_MANIFEST.md の Release Criteria セクション
   書き込み：  release-gates/<slug>-gate.md

セクション 3 — 人間によるゲート

ゲート 1：Architect の後 — Designer の実行前に、人間が ADR を承認します。
ゲート 2：Reviewer の後 — Deployer の実行前に、人間がレビュー報告書を承認します。

セクション 4 — エージェントごとのシステムプロンプトの種 6 つのエージェントそれぞれに、このテンプレートを使用します。

"あなたは{ProjectName}の{Agent}です。PROJECT_MANIFEST.md の{relevant manifest sections}を使用して、{role description}を行います。"

以下を記入します。

• {ProjectName}：プロジェクトマニフェストのセクション 1（概要）から取得
• {Agent}：Planner / Architect / Designer / Coder / Reviewer / Deployer
• {role description}：エージェントの機能に適した説明
• {relevant manifest sections}：そのエージェントが読み込むセクション

各シードには、プロジェクト名とプロジェクトマニフェストのセクション 4（Domain Model）にあるドメインエンティティ名を少なくとも 1 つ含める必要があります。ドメインモデルが弱い（「weak」とラベル付けされている）場合は、各シードに (update with domain entities once Section 4 is strengthened) を追加します。

「Fired Up Pizza」のシードの例：

Planner:   "あなたは Fired Up Pizza の Planner です。PROJECT_MANIFEST.md の
           Domain Model と Tech Stack を使用して、機能リクエストを
           ワークパッケージに分解します。"

Architect: "あなたは Fired Up Pizza の Architect です。PROJECT_MANIFEST.md の
           Tech Stack と Constraints を使用して、アーキテクチャ決定記録を
           作成します。"

Designer:  "あなたは Fired Up Pizza の Designer です。PROJECT_MANIFEST.md の
           Domain Model と Conventions を使用して、UX 仕様と
           インタラクションデザインを作成します。"

Coder:     "あなたは Fired Up Pizza の Coder です。PROJECT_MANIFEST.md の
           Conventions と Task Inputs に従って、機能を実装します。"

Reviewer:  "あなたは Fired Up Pizza の Reviewer です。すべてのコード差分に対して
           PROJECT_MANIFEST.md の Review Standards を適用します。"

Deployer:  "あなたは Fired Up Pizza の Deployer です。Release Criteria に照らして
           リリースを判定します。"

セクション 5 — 品質ゲート プロジェクトマニフェストの Review Standards セクションと Release Criteria セクションをコピーします。6 つの各ステージについて「ステージ N は、[基準]を満たすと合格します：」の形式で整理します。

セクション 6 — オーケストレーターの設定

調整パターン：引き継ぎを伴う逐次パイプライン
障害処理：エージェントで失敗した時点でパイプラインを停止し、エラーを人間に提示する
再試行ポリシー：自動再試行なし（再実行するかどうかは人間が決定）
ブランチ戦略：作業項目ごとに機能ブランチを作成し、Deployer ゲートの通過後にマージする

セクション 7 — 規約リファレンス プロジェクトマニフェストのセクション 5（Conventions）から、一字一句そのままコピーします。

---

フェーズ 7：検証と書き込み

書き込み前に検証します。不合格があれば、コンテキスト内のプロジェクトマニフェストの内容を使ってセクションを再生成し、修正します。

1. Pipeline Sequence の 6 つすべてのエージェントに、空でない Reads と Writes がある — 合格、または修正。
2. Gate 1 は Architect の後、Gate 2 は Reviewer の後（Deployer の後ではない）にある — 合格、または修正。
3. 6 つすべてのシードに、プロジェクト名と少なくとも 1 つのドメインエンティティが含まれている — 合格、または修正。
4. Quality Gates セクションが空でなく、一般論にとどまっていない — 合格、または修正。

FILE_WRITE_GUARD("SOFTWARE_FACTORY_MANIFEST.md") を呼び出します。

SOFTWARE_FACTORY_MANIFEST.md を現在のディレクトリに書き込みます。

次のように報告します：「SOFTWARE_FACTORY_MANIFEST.md を書き込み、検証しました。 両方のマニフェストの準備ができました — 6 エージェントのファクトリーにコンテキストが設定されました。」

---

PROJECT_MANIFEST スキーマ

出力ファイルを次の構造と完全に一致させて作成します。すべてのセクションを埋めてください。

# プロジェクトマニフェスト：[Project Name]

## 概要

[ソフトウェアの機能と利用者を説明する 1 段落。]

## 技術スタック

| レイヤー | テクノロジー | 備考 |
|----------|--------------|------|
| フロントエンド |           |       |
| スタイリング |           |       |
| 状態管理 |           |       |
| ルーティング |           |       |
| バックエンド |           |       |
| データベース |           |       |
| テスト |           |       |
| リント |           |       |

## プロジェクト構成

[トップレベルのディレクトリツリーと注釈。コード作成前の場合は（提案）と明記します。]

## ドメインモデル

[主要なエンティティ、そのフィールド、およびエンティティ間の関係。]

## 規約

- ファイル名：
- テストファイル：
- API ルート：
- コミット：
- ブランチ：

## 制約

- [明示的に対象外とする項目、または禁止するアプローチ。]

---

## タスク入力

| エージェント | 受け取る内容 | 提供元 |
|--------------|--------------|--------|
| Planner      |              |        |
| Architect    |              |        |
| Designer     |              |        |
| Coder        |              |        |
| Reviewer     |              |        |
| Deployer     |              |        |

## 接続するサービス

| サービス | 目的 | 設定 |
|----------|------|------|
|          |      |      |

## 成功基準

### 機能ごとの成功基準

- [ ]
- [ ]

### ファクトリーレベルの成功基準

- [ ]
- [ ]

---

## レビュー基準

### 仕様への準拠

- [Reviewer が Designer の仕様に対して適用するルール。]

### スタイル

- [プロジェクト固有のスタイルルール。]

### セキュリティ

- [プロジェクト固有のセキュリティルール。]

### 重大度の基準

- **低**：見た目に関する問題、軽微な不整合
- **中**：機能上の不足、エッジケースの見落とし
- **高**：データ損失、セキュリティ脆弱性、仕様違反

---

## リリース基準

### 必須（すべて合格すること）

1. [ ]
2. [ ]

### 参考情報（報告するが、リリースを妨げない）

- [指標 1]

---

SOFTWARE_FACTORY_MANIFEST スキーマ

出力ファイルは、以下の構造にしてください。

# ソフトウェアファクトリーマニフェスト：[Project Name]

## ファクトリー概要

[プロジェクト名。このファクトリーは、6 エージェントの逐次パイプライン（Planner →
Architect → Designer → Coder → Reviewer → Deployer）を、2 つの人間による承認ゲートを設けて実行します。
技術スタック：[PROJECT_MANIFEST.md の概要]。]

## パイプラインの順序

1. **Planner**
   - 読み込み：機能リクエスト + PROJECT_MANIFEST.md
   - 書き込み：work-packages/[slug].md

2. **Architect**
   - 読み込み：Planner の作業パッケージ + 技術スタックのセクション
   - 書き込み：docs/adr/NNNN-[slug].md

3. **Designer**
   - 読み込み：Architect の ADR + ドメインモデルのセクション
   - 書き込み：design/[slug]-spec.md

4. **Coder**
   - 読み込み：Designer の仕様書 + 規約のセクション
   - 書き込み：[slug]-[feature] フィーチャーブランチの src/

5. **Reviewer**
   - 読み込み：コード差分 + レビュー基準のセクション
   - 書き込み：review-reports/[slug]-review.md

6. **Deployer**
   - 読み込み：Reviewer のレポート + リリース基準のセクション
   - 書き込み：release-gates/[slug]-gate.md

## 人間による承認ゲート

- **ゲート 1 — Architect の後：** Designer の実行前に、人間が ADR を承認します。
- **ゲート 2 — Reviewer の後：** Deployer の実行前に、人間がレビュー報告書を承認します。

## エージェントごとのシステムプロンプトの種

**Planner：**「[seed]」

**Architect：**「[seed]」

**Designer：**「[seed]」

**Coder：**「[seed]」

**Reviewer：**「[seed]」

**Deployer：**「[seed]」

## 品質ゲート

[PROJECT_MANIFEST.md のレビュー基準とリリース基準から導き出した、ステージごとの合格基準。形式：「ステージ N（AgentName）の合格条件：[criteria]」。]

## オーケストレーターの設定

- 調整パターン：引き継ぎを伴う逐次パイプライン
- 失敗時の処理：エージェントが失敗した時点でパイプラインを停止し、エラーを人間に提示
- 再試行ポリシー：自動再試行なし（再実行するかどうかは人間が判断）
- ブランチ戦略：作業項目ごとにフィーチャーブランチを作成し、Deployer のゲート通過後にマージ

## 規約の参照

[PROJECT_MANIFEST.md の規約セクションをそのままコピー。]

---

作成例：Fired Up Pizza

入力の説明

Fired Up Pizza は、小規模な近隣のピザレストラン向けのウェブアプリです。お客様は メニューを閲覧し、ピザ（サイズ、生地、トッピング）をカスタマイズして、電話番号を使って注文し、 「注文済み → 調理中 → 準備完了 → 配達済み」の進捗を確認できます。スタッフも同じアプリを使って メニュー項目を管理し、ピザが厨房を進むのに合わせて注文ステータスを更新します。電話だけに頼るため 注文を取りこぼし、お客様に状況が伝わらないワークフローに代わるものです。

目標：お客様が電話をかけずに注文と進捗確認を行えること。スタッフがすべての進行中の注文を一画面で確認し、 ワンクリックでステータスを更新できること。npm install && npm run dev で単一マシン上で動作し、 クラウドのセットアップが不要であること。

スタック：React 18 + TypeScript + Vite；Tailwind；Node.js + Express REST API；better-sqlite3 による SQLite； Vitest + React Testing Library。

対象外：オンライン決済（カウンターで支払い）、SMS／プッシュ通知、複数店舗への対応、 ロイヤルティアカウント。

制約：外部認証なし（電話番号でユーザーを識別）、外部 DB サーバーなし、 リアルタイムインフラなし（ポーリングは許容）。

ユーザー：お客様（電話番号で識別され、注文と進捗確認を行う）；スタッフ （進行中の注文キューを確認し、注文ステータスを更新し、メニュー項目を編集する）。

「EXTRACTED」の例（注釈付き抜粋）

セクション 1 — 概要（EXTRACTED）： Fired Up Pizza は、近所の小規模レストラン向けの Web アプリです。顧客はメニューを閲覧し、電話番号を使って注文内容をカスタマイズして注文でき、注文状況を注文済み → 準備中 → 完了 → 配達済みの流れで確認できます。スタッフはリアルタイムの注文キューを確認し、状況を進めます。電話のみのワークフローに代わるものです。 [良い例：プロジェクト名が明記され、具体的な関係者とワークフローが説明されています。]

セクション 2 — 技術スタック（EXTRACTED）： フロントエンド：React 18 + TypeScript + Vite | スタイリング：Tailwind CSS | バックエンド：Node.js + Express（REST）| データベース：better-sqlite3 経由の SQLite（単一マシン、外部サーバーなし）| テスト：Vitest + React Testing Library [良い例：利用可能な場合はバージョンを含め、技術名と制約に関する注記が示されています。]

セクション 4 — ドメインモデル（EXTRACTED）： MenuItem：id、name、description、base_price、available（boolean） Order：id、phone_number、status（placed|preparing|ready|delivered）、created_at OrderItem：id、order_id、menu_item_id、size、crust、toppings[]、unit_price Customer：phone_number で識別（アカウントエンティティなし） Staff：role のみ。独立したエンティティは不要 [良い例：エンティティ名と主要フィールドが示され、関連性も読み取れます。「EXTRACTED」とはこのような状態です。]

セクション 4 — ドメインモデル（PARTIAL）： 「このアプリでは、顧客とスタッフ向けに注文とメニュー項目を管理します。」 [悪い例：エンティティ名（注文、メニュー項目、顧客、スタッフ）はありますが、フィールド、関連性、ステータスがありません。追加質問が必要になります。]

セクション 6 — 制約（EXTRACTED）：

• オンライン決済なし（支払いはカウンターのみ）
• SMS またはプッシュ通知なし
• 複数店舗のサポートなし
• 外部認証なし。本人確認には電話番号のみを使用
• 外部 DB サーバーなし。SQLite、単一マシン
• ポーリングで問題なし（リアルタイムインフラは不要） [良い例：明示的かつ列挙されており、実行に移せる内容です。]

セクション 9 — 成功基準（EXTRACTED）： 機能ごと：顧客が電話をかけずに注文できること。顧客が 4 つのステータス段階を通じて注文状況を確認できること。スタッフがすべての進行中の注文を 1 つの画面で確認できること。スタッフが 1 回のクリックでステータスを進められること。スタッフがメニュー項目を編集できること。 ファクトリーレベル：npm install && npm run dev でアプリを起動できること。クリーンなチェックアウト状態ですべてのテストがパスすること。 [良い例：具体的でテスト可能であり、ファクトリーレベルの基準も含まれています。]