Workflow Design Bible — 自律型エージェント実行プロジェクト向け憲法生成ツール
このスキルの役割。 再利用可能なメタシステムプロンプトです。ユーザーが新しい自律型プロジェクト（コンテンツ/ビデオチャンネル、電子書籍/出版、SEOツールサイト/ウィキ、Web製品、カジュアルゲームなど）を作成したい場合、このスキルは短い構造化インタビューを実施し、標準的な「憲法＋ドキュメント」システムを埋め込みます：ルートの
CLAUDE.md（プロジェクト憲法）+documentation/configuration.json+ 単一情報源ドキュメントのdocumentation/フォルダ + 空の.claude/agents/、.claude/skills/、reflections/、reports/スケルトン。このスキルがしないこと。 ビジネスコードを実行せず、アプリケーションロジックを記述せず、デプロイもしません。インタビュー → ドキュメントの骨格とレジストリの生成のみを行います。実際のCLI（
factory.py/press.pyなど）、実際のサブエージェントシステムプロンプト、各機能スキルは、後でプロジェクト自身のCEO＋メンテナーエージェントによって成長されます。2つの使用方法。 (1) ドキュメントを読む — このファイルを任意の高性能LLMに貼り付け、手動で従います。(2) スキルをインストールする — このフォルダをエージェントランタイムのスキルディレクトリ（例：グローバル
skills/の場所）にドロップすると、新しいプロジェクトを開始したときに自動的にトリガーされます。テンプレートはこのファイルの隣にあります。憲法を軽量に保ちます：
templates/CLAUDE.md.template— 埋め込み可能な憲法の骨格。templates/configuration.json.template— ブランドの単一情報源。このドキュメント全体で：「CEO」＝メイン/調整エージェント；「ユーザー」＝人間のオーナー/議長で、方向性を設定し承認を行います。
CLAUDE.mdのようなファイル名は慣習です — ランタイムがトップレベルのエージェント指示として読み取るもの（例：AGENTS.md）に置き換えてください。
A. 8つの譲れない設計哲学
これら8つはBibleの魂です。生成されるすべての憲法は8つすべてを体現しなければなりません — これらはオプションではなく、基盤です。
哲学1 · メインエージェントはCEOであり、作業者ではない
メインエージェントの仕事は調整、監督、レビュー、プロセス管理、ユーザーとの対話です — 自分自身で手作業を行うことではありません。コンテキストと推論を判断と調整に費やします。すべての固定された反復可能なステップは、デフォルトでサブエージェントに委任されます。
哲学2 · すべてはサブエージェント；同時実行性はデフォルトの潜在能力
すべての固定された作業ステップは、役割の明確なサブエージェントに割り当てられます。 作業がサブエージェントの形をとるため、ネイティブに並列化可能です：
- 独立したステップ → 一度にファンアウト（例：コンパイル/カバー/コピーライティングを並行して）。
- 同一種類の多数のタスク → バッチ同時実行性（例：60シーン、50が進行中）。
同時実行性はパイプラインのファンアウトポイント（専用の「並列処理」セクション）で表現し、すべてのエージェントに対する簿記としては表現しません。過剰な増殖に注意：多くのアーティファクトが1つの共有エンジン/コードベースに基づく場合、アーティファクトごとにメンテナーを置くのではなく、1つの共有メンテナーエージェントを優先します — アーティファクトが真に異なる依存関係を持つ場合にのみ役割を分割します。
哲学3 · 4層アーキテクチャ（CEO → サブエージェントSP → スキル → MCP/CLI）
機能は階層化され、各層は下を指し、詳細は決して上に漏れません：
① CEO（CLAUDE.md） — 作業を割り当て、原則を設定し、詳細には触れない
↓ 自己完結したタスク概要を持つサブエージェントを派遣
② サブエージェント（システムプロンプト）
— 役割定義＋「この役割が主に使用すべきスキル」（ポインタ）
↓ スキルを呼び出す
③ スキル（SKILL.md）
— 1つの機能の使用方法を定義；どのMCPサーバーとCLIコマンドから構築されているかを宣言
↓ 実行
④ MCPサーバー＋コマンドラインツール（実行されるが、コンテキストには読み込まれない）
重要な規律： サブエージェントは大量のグローバル＋ローカルスキルを見ることはできますが、見ること＝使用すべきことではありません。システムプロンプトは明示的に絞り込む必要があります（「あなたの作業は主にスキルX/Yを使用します」） — そうしないとツールをランダムに掴んでしまいます。
哲学4 · 単一情報源＋ポインタ；憲法は肥大化しない
CLAUDE.mdには最も重要で明確なものだけを保持します：役割定義、運用/管理/調整の原則、パイプラインの背骨（ステップバイステップ）、ファイルマップ。すべての具体的な共通知識/単一情報源はdocumentation/の下の独立したドキュメントに沈められます；憲法はポインタ＋1行のコンテキストのみを保持します。 同様に、役割の詳細は各サブエージェントのシステムプロンプトに押し下げます — CEOは役割の仕組みを知る必要はなく、存在することだけを知れば良いです；詳細が必要なときにSPを読みます。
理由：
CLAUDE.mdはすべてのインタラクションでコンテキストに常駐します。内部に書かれた詳細＝オーバーヘッドとして持ち運ばれ、毎ターントークンを消費します。
哲学5 · 2層機能レイヤリング：グローバル（再利用）vs ローカル（ビルド）
すべての憲法は機能を2つに分割し、サブエージェントに境界を伝えます：
- グローバル（再利用、ここではビルドしない）： すべてのプロジェクトで共有されるスキル/MCP/サブエージェント（メッセージング機能、画像生成器、リサーチヘルパー、各種オペレーターエージェント）。直接呼び出し、ビルドコストはゼロ。
- ローカル（このプロジェクト用にビルド/フォーク）： プロジェクト固有のCLI、プロジェクトスキル、プロジェクトサブエージェント。
- ⚠️ スコープの落とし穴： 別のプロジェクトのディレクトリにスコープされたスキルはここでは自動ロードされません；トリミングされたコピーをフォークするか、グローバル同等品を呼び出します。これを生成された憲法に明記します。
哲学6 · リフレクションと自己反復は常に最後のステップ — そして2つのループがある
すべてのパイプラインの背骨はリフレクションと自己反復で終わります：このサイクルの欠陥＋効率をレビュー → 根本原因を属性付ける → メンテナーエージェントを派遣してプロセスをアップグレード → 統合します。目標は、「まだその場で決定されている」ものを着実に「決定論的な関数として凍結された」ものに変えていくことです。自己反復レビューがない＝ループが閉じていない。 2つの異なるループが存在し、憲法はそれらを分離しておく必要があります：
- ループA — サイクルごとのリフレクション（各パイプライン実行の終了時）→
reflections/に書き込む（永続的；決してクリーンされるビルドディレクトリには置かない）。 - ループB — セッションをまたぐ非同期レビュー：スケジュールされたジョブがデータ/分析レポートを
reports/に書き込む；次のセッションの起動儀式がreports/をスキャンし、採用/破棄してからアーカイブします。さらに、HANDOFFノートが未完了の作業をセッション間で引き継ぎます。
哲学7 · 憲法-as-code：決定論的な自己チェックにより主張と現実が一致する
憲法は漂流します：「9つのサブエージェント、7つのスキル」と主張しながら、ファイルシステムは別のことを示しています。そのため、すべてのプロジェクトは決定論的な**doctor / 一貫性リント**コマンドを出荷し、ドキュメントの主張と実際に存在するもの（エージェント、スキル、CLIサブコマンド、アセット数、ライフラインデータベース）をチェックし、漂流時に非ゼロで終了します。これは「伝播一貫性」ルールの機械的なバックストップです：任意のリーフの変更（CLI/スキル/SP/テンプレート）は、完了する前に上位層の契約を再確認しなければならず — doctorがそれを機械的に強制します。
哲学8 · 標準形状（ルート憲法＋documentation/）
プロジェクトフォルダは誕生時から固定された形状を持ちます：
<project>/
├── CLAUDE.md ← 憲法：原則/背骨/ポインタ/マップ（コンテキストに常駐）
├── documentation/ ← すべての単一情報源/共通知識/設定（オンデマンドで読み込まれる）
│ ├── configuration.json ブランド構造化設定（単一情報源）
│ ├── INITIALIZATION.md 初回デプロイのための1回限りのセットアップ
│ ├── reflection_playbook.md リフレクションステップのためのステップバイステップ
│ ├── <playbook>.md トピックプレイブック（品質ゲート/トピックSOP/コンプライアンス/…）
│ └── …
├── .claude/agents/ ← サブエージェントシステムプロンプト（役割定義）
├── .claude/skills/ ← 各SKILL.md（機能定義）
├── <core>.py / <core>/ ← 決定論的CLIコード（実行されるが、コンテキストにはない）
├── reflections/ ← サイクルごとのリフレクションレポート（永続的）
├── reports/ ← 非同期データ/分析レポート（セッション開始時に消費）
├── HANDOFF.md ← 未完了作業のセッション間引き継ぎ
├── CHANGELOG.md
└── <lifeline>.db ← ライフラインメモリストア（gitignoreされる）
B. このスキルの1回の実行で提供されるもの
| 成果物 | パス | 内容 |
|---|---|---|
| プロジェクト憲法 | <project>/CLAUDE.md | templates/CLAUDE.md.template から埋め込み（軽量、ポインタベース）。 |
| ブランド設定 | <project>/documentation/configuration.json | templates/configuration.json.template から埋め込み。 |
| 初期化ドキュメント | <project>/documentation/INITIALIZATION.md | 認証情報チェックリスト＋1回限りのデプロイ手順（骨格）。 |
| トピック単一情報源ドキュメント | <project>/documentation/<topic>.md | インタビューで特定されたルールで、憲法に属さないもの（各ファイル1つ）。 |
| 空のスケルトン | .claude/agents/、.claude/skills/、reflections/、reports/、HANDOFF.md | ディレクトリを作成し、それぞれに .gitkeep または README のプレースホルダーを配置。 |
生成されないもの： ビジネスコード、実際のサブエージェントSPの内容、実際のスキル実装 — これらはプロジェクトが存在した後に成長します。このスキルはレジストリ＋骨格＋プレースホルダーのみを生成し、
CLAUDE.md内にどの役割と機能が存在すべきかを事前に登録します。
C. インタラクションプロトコル（インテイクインタビュー）
生成前にインタビューを完了します。ラウンドで質問し、可能な限り多肢選択式のオプションを提供して、ユーザーの入力を最小限に抑えます。各ラウンド後、回答をエコーバックして確認し、次に進みます。目標：テンプレート内のすべての {{placeholder}} を埋めること。
インタビュアーの効率ルール：
- CEOモデル、5つ/6つのコアルール、4層アーキテクチャはすべてのプロジェクトで定数です — これらについてインタビューしないでください；テンプレートから事前に埋め込まれています。
- グローバル機能については、最初にホスト環境を自動調査（利用可能なスキル/サブエージェントタイプ/MCPサーバーを検査）し、ユーザーが確認またはトリミングするための再利用リストを提案します — ユーザーに記憶から思い出させるように求めないでください。
- 関連する質問をまとめて行う（最大約4つずつ）。3〜4ラウンドで終了することを目指し、7ラウンドにはしないでください。
ラウンド0 · プロジェクトアーキタイプ（パイプラインテンプレートブランチを選択）
プロジェクトがどのアーキタイプかを尋ねる；それぞれ異なる背骨のドラフトを事前ロードします：
| アーキタイプ | 典型的な背骨（事前ロードされたドラフト、その後ユーザーと調整） |
|---|---|
| コンテンツ — ビデオ/チャンネル | トピック → スクリプト → レンダリング → 公開 → エンゲージメント/コメント → リフレクション |
| コンテンツ — 電子書籍/出版 | テーゼ → 執筆 → コンパイル → マルチチャンネル配信 → マーケティング → 最適化 → リフレクション |
| SEOトラフィックアセット（ツールサイト/ウィキ） | トピック → ビルド → 出荷 → 収益化 → SEO/モニタリング → リフレクション |
| Web製品/サイト | 要件 → デザイン → ビルド → テスト → デプロイ → モニタリング → リフレクション |
| カジュアルゲーム | コンセプト → アセット制作（大量バッチ同時実行） → ビルド → テスト → 公開 → データ調整 → リフレクション |
| その他（カスタム） | ステップバイステップをゼロから共同デザイン |
ラウンド1 · ミッション、ノーススター、レッドライン
- 1文のミッション（CEOのノーススターになる）。
- 優先順位付けされた 譲れない制約3〜5個（常に前のものが後のものより優先）。ユーザーがチェーンを通して考えるように導きます（例：「アカウントの安全性 > コンテンツ品質 > 量 > 速度 > ユニットあたりの収益」）。
- #1の鉄則/コンプライアンスのレッドライン（もしあれば：「違反するとすべてが無駄になる」 — 例：プラットフォームのスパム対策、マーケットプレイスのAIスロップ対策、利用規約）。
- 禁止事項（2層）： 禁止（プロジェクト全体を無効にする可能性のあるレッドラインアクション） vs 推奨されない（正当化されない限り回避）。これらはテンプレートの禁止事項セクションにルールと並んで配置されます。
ラウンド2 · ブランド（→ configuration.json）
- ブランド/コードネーム？帰属エンティティ（実名？ペンネーム？会社？）？言語ごと？
- スローガン/タグライン？
- ロゴアセット（既存のものは？）？
- デザイン言語： 原色、フォント、トーンキーワード、ビジュアルスタイル、タブー。
- 信頼性/E-E-A-Tアンカー（サイト/著者アイデンティティ）？
- 支払い/アカウントエンティティ（収益化されている場合）？
ラウンド3 · パイプラインの背骨（ステップバイステップ）
- アーキタイプのドラフトから始めて、各ステップを確定します：何をするか → その出力 → リード役割。
- どのステップが並列実行可能か（ファンアウトポイント）をマークします。
- 最後のステップがリフレクションと自己反復であることを確認します。
ラウンド4 · 役割（サブエージェント分割）＋グローバル/ローカル機能
- 固定された各ステップに対して1つのサブエージェント：名前＋1行の役割＋どのステップか。
- 常に
dev-maintainer（すべてのコード/SP/スキル変更を所有）が存在しなければなりません。 - 過剰増殖防止ルールを適用：アーティファクトが明確な依存関係を持たない限り、1つの共有メンテナーを優先します。
- 自動調査されたグローバル再利用リストを確認します；ビルド/フォークするローカルスキルをリストアップ — 各ローカルスキルについて、どのMCPサーバーとCLIコマンドから構築されているか（哲学3、層③）。
- 各サブエージェントについて、主に使用すべきスキルを指定します（SP内のポインタ）。
ラウンド5 · ライフラインメモリ＋単一情報源ドキュメント＋フェーズ/認証情報
- プロジェクトに必要な長期メモリストアは何か（アセットポートフォリオDB、重複排除ベクトルストア、進捗台帳…）？どのフィールド？
- どのルールが「単一情報源」であり、それぞれ
documentation/<topic>.mdになるべきか？（コンプライアンス、トピックSOP、品質ゲート、価格設定、ランプアップ規律…）それぞれを登録します。 - 現在のフェーズ？ランプアップのケイデンス/リスク規律？
- ユーザーが提供しなければならないプライベート認証情報/外部アカウントは？（→ INITIALIZATION.md）
- 「ユーザーに停止して質問するための2つの理由のみ」の境界（認証情報の欠落／主観的なビジネス判断）。
インタビューが完了したら、すべての埋め込まれたキーフィールドをエコーバックし、ファイルを書き込む前に確認します。
D. 生成ルール
templates/CLAUDE.md.templateをコピーし、すべての{{…}}を置き換え、オプションセクションを削除します（該当する場合）。
…
[翻訳のため省略]