vibe-coding-prompt-template：PRDと技術設計をAI IDEに渡す前段の型
Templates and workflow for generating PRDs, Tech Designs, and MVP and more using LLMs for AI IDEs
ひと目でわかる
- これは何？
- アイデアからPRD、技術設計、AGENTS.mdまでを段階的なプロンプトで固定し、AIコーディングエージェントに渡す前の工程を管理するTypeScript製のワークフロー。CLIと手動貼り付けの2通りがあり、向き不向きがはっきり分かれる。
- 誰に向いている？
- 採用すべきなのは、AI IDEで新規プロジェクトを立ち上げる個人開発者、あるいはPRDと技術設計を書く習慣がまだ社内にない小規模チームだ。逆に、既に要件定義と設計レビューの型が組織にあり、成果物のフォーマットが固定されている現場では、このプロンプト群は二重管理になる。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 5 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
AIはコードを書けるが、何を作るかを決めてくれない
このプロジェクトが置いている前提はREADMEの一文に集約されている。AIはコードを書けるが、何を作るべきかの判断、動くかの確認、壊れたときの復旧は別問題だという立場である。つまり対象は、コーディングエージェントに指示を出す前段、あるいは指示が破綻した後の段階で詰まる人である。
具体的には、思いつきでプロンプトを投げて動くものを得たが、翌週には何を意図してその構造にしたか分からなくなった経験のある個人開発者が主な読者になる。READMEにはvibeworkflow.app、moneyvisualiser.com、caglacabaoglu.com、RealDex Appという4つの参照先が挙げられており、いずれもこのワークフローで作られたと説明されている。ただし各サイトの規模や品質についての記述はなく、成果の程度は読み取れない。
もうひとつの読者は、チームでAI IDEを使い始めたが、メンバーごとに出力の粒度がばらついている現場だ。プロンプトを共有資産として固定するという発想は、このばらつきを減らす方向に働く。
5段階のパイプラインと、フェーズ1とフェーズ2の断絶
READMEが示す流れは線形である。Deep Research、PRD、Tech Design、Agent files、Build。mermaidの図でもアイデアから調査、PRD、技術設計、AGENTS.md、MVPへと一本道で描かれている。
このうち最初の3つはチャットツール側で完結する。リポジトリは不要で、part1-deepresearch.md、part2-prd-mvp.mdといったファイルの中身をコピーしてChatGPT、Claude.ai、Geminiなどに貼る。各ステップには20〜30分、15〜20分という目安が添えられている。
後半2つはAI IDE側に移る。ここで生成されるのがAGENTS.mdとagent_docs/ディレクトリで、以降のビルドは「小さく検証されたパス」で進めると説明されている。
設計上の要点は、前半の成果物をテキストファイルとして保存させ、それを後半の入力にする点だ。research-[YourAppName].mdという命名規則が例示されており、同一チャットを継続する方法と、保存したファイルを新しいチャットに貼り直す方法の両方が案内されている。チャットの文脈に依存させない逃げ道を用意しているのは実用的な判断だ。
npx vibeworkflow と3つのルーティング
CLIとしての入口は npx vibeworkflow の一語に集約されている。READMEの指示は「AIコーディングエージェントを使っているなら、Claude Code、Cursor、Codex、Gemini CLIのいずれかをプロジェクトで開き、Run npx vibeworkflow and follow its instructions と伝えよ」というものだ。
実行するとワークフローは既存の状態を検査し、新規開始、プロジェクトの継続、何かが壊れた、の3方向にルーティングする。プランニングの深度はQuick、Guided、Deepの3段階で、プロジェクトの規模に応じて質問量を調整するとされている。この「既存状態を検査してから分岐する」という挙動は、空のフォルダでも既存アプリでも同じ入口で済むことを意味する。
既存アプリに対しては /vibe-change、/vibe-debug、/vibe-verify というスラッシュコマンドが用意されており、vibeworkflow 0.3.0以降で利用可能と明記されている。ここはバージョン依存が明示されている数少ない箇所なので、導入時にCLIのバージョンを確認する価値がある。
なお、この3コマンドが何を検証し、何を変更するのかの詳細は与えられた資料には書かれていない。名前から用途は推測できるが、挙動の説明はない。
リポジトリ構造が示す、プロンプトを資産として扱う設計
ファイル構成から読み取れるのは、プロンプトをアプリケーションコードと同じリポジトリで版管理するという方針だ。part1-deepresearch.md、part2-prd-mvp.md、part3-tech-design.mdという連番のMarkdownがルートに並び、examples/reading-list/ に実行可能なサンプル、.claude/ にClaude Code向けのスキル定義が置かれている。
主要言語がTypeScriptであることは、CLI部分がNode.jsで書かれていることを示す。プライマリ言語の表記と、npx経由で配布されている事実、topicsにnodejsとnpmが含まれる点は整合している。
この構造の含意は、プロンプトの変更がgitの差分として追えることだ。プロンプトをチャット履歴や個人のメモに置く運用と比べると、変更理由をコミットメッセージに残せる。逆に言えば、プロンプトを直すたびにリポジトリの更新を取り込む運用が必要になり、フォークして独自に書き換えた場合は上流の変更を手で取り込むことになる。
v3系で何が変わったかは、リリース名からしか分からない
公開されているリリースは3件で、v3.1.0がThe Agent-First Release、v3.0.0がThe Contracts Release、v2.4.0がAudit & Hardeningとなっている。日付はそれぞれ2026年8月20日、7月18日、4月9日である。
ここで正直に書いておくと、各リリースの中身を説明するテキストは与えられた資料には含まれていない。リリース名から、v3.0.0で何らかの契約、おそらくエージェントに渡す入出力の取り決めが導入され、v3.1.0でエージェント優先の構成に移ったと推測できる程度だ。v2.4.0のAudit & Hardeningという名前からは、監査と堅牢化が主題だったことがうかがえるが、対象がCLI本体なのかプロンプトなのかは判別できない。
バージョン間でプロンプトのファイル名やAGENTS.mdの構造が変わっている可能性は十分にある。2.x時代の記事やチュートリアルを参照する場合は、手元のCLIバージョンと突き合わせる必要がある。この点は導入前に確認すべき事項のひとつだ。
向かない場面：設計の型が既にある組織と、調査を伴わない小修正
このワークフローが前提としているのは、判断の記録が失われやすい状況である。したがって、既に要件定義書と基本設計書のフォーマットが社内標準として存在し、レビュー工程も回っている組織では、同じ内容を二つの形式で持つことになる。part2-prd-mvp.mdの出力をそのまま標準フォーマットへ転記する手間が発生し、プロンプトを保守する側の負担だけが残る。
もうひとつの失敗モードは、Deep Researchを飛ばしてBuildだけを使う運用だ。READMEの流れは線形で、調査、PRD、技術設計を経てからAGENTS.mdに進む。調査フェーズを省略すると、AGENTS.mdに書かれる前提が本人の頭の中だけに存在することになり、後から読む第三者は判断の根拠を追えない。数行の修正やバグ修正だけが目的なら、/vibe-change や /vibe-debug を単体で使うほうが手数は少ない。ただしこれらのコマンドが前提とするAGENTS.mdの存在については、資料に記述がない。
また、Deep ResearchはWeb検索やソース付きの応答をサポートするツールで使うことが推奨されており、検索機能のない環境では「調査プロンプトを生成する」という代替動作になると説明されている。裏取りのない調査結果がPRDに流れ込む経路がここにあり、生成物をそのまま信じる運用は避けたい。
代替手段との違い：汎用エージェント指示ファイルとの比較
近い用途の仕組みとして、AGENTS.md のようなエージェント指示ファイルを単体で手書きする運用がある。違いは工程の分割にある。AGENTS.md単体の運用では、何を作るか、どのスタックを選ぶか、どこにデプロイするかという決定がすべてこの1ファイルに圧縮される。結果として、決定の理由が残らず、後から読んだ人は制約だけを受け取ることになる。
このプロジェクトは、その上流にDeep Research、PRD、Tech Designという3つの独立した成果物を置き、AGENTS.mdをその出力として位置づけている。決定の根拠が別ファイルに残る点が構造上の差だ。
一方で、汎用の指示ファイル運用には依存関係の少なさという利点がある。npx vibeworkflow の実行も、プロンプトファイルの更新追従も不要で、エージェントが読むファイルは1つで完結する。小規模なスクリプトや、数日で捨てる前提の試作では、この軽さのほうが合理的である。どちらが優れているかではなく、成果物を後から読む人がいるかどうかで選ぶべき話だ。
MITライセンスと、保守コストの見積もり
ライセンスはMITで、リポジトリはアーカイブされていない。最終更新は2026年9月5日であり、v3.1.0の公開から2週間ほど後にあたる。MITであれば、プロンプトを改変して自社のテンプレートに取り込むことや、社内配布することは、著作権表示とライセンス条項を残す限りにおいて一般的に認められる。ただしこれは法的助言ではなく、実際の適用判断は各組織の法務に確認する必要がある。
保守コストとして見ておくべき点は3つある。第一に、プロンプトはコードと同様に更新される。上流のpart*.mdをそのまま使うなら、更新のたびに差分を取り込む判断が要る。第二に、CLIのバージョンとスラッシュコマンドの対応関係がある。/vibe-change などは0.3.0以降と明記されており、バージョンを固定しないと挙動が変わりうる。第三に、生成されるAGENTS.mdとagent_docs/はリポジトリにコミットされる成果物なので、プロンプトを更新した後に再生成するか、既存の生成物を手で直すかの選択が毎回発生する。
プロンプトをフォークして自組織向けに書き換えた場合、上流の改善は自動では入らない。この分岐をどちらに倒すかは、導入前に決めておくべき設計判断である。
編集部の結論
採用すべきなのは、AI IDEで新規プロジェクトを立ち上げる個人開発者、あるいはPRDと技術設計を書く習慣がまだ社内にない小規模チームだ。逆に、既に要件定義と設計レビューの型が組織にあり、成果物のフォーマットが固定されている現場では、このプロンプト群は二重管理になる。導入前に確認すべきは、npx vibeworkflow が生成するAGENTS.mdとagent_docs/の構造が既存リポジトリの慣習と衝突しないか、そしてQuick/Guided/Deepのどのプランニング深度が自分のプロジェクト規模に合うかだ。判断はREADMEの説明だけでは完結しないので、examples/reading-list/ を一度そのまま流して生成物を読むところから始めるのが現実的である。
コミュニティノート