vibe-coding-standard-workflow

Vibe Coding Standard Workflow

大まかなアイデアを、管理されたデリバリーループに変えます。このスキルを使って、ドキュメントを先に作成する計画、明確な確認、小さくテスト可能な実装ステップ、後の引き継ぎに活用できる永続的なプロジェクトメモリを徹底します。

対象となる成果物

次のファイルを作成し、維持します。

• PRD.md：一時的なアイデア記録ファイル
• memory-bank/design-document.md
• memory-bank/tech-stack.md
• memory-bank/implementation-plan.md
• memory-bank/progress.md
• memory-bank/architecture.md
• エージェント環境に応じて AGENTS.md および／または CLAUDE.md

ブートストラップ段階を終えた後は、memory-bank/ を長期的な信頼できる情報源として扱います。

ブートストラップのワークフロー

1. 最初のアイデアを整理する

まず、次の内容をまとめた簡潔な PRD.md を作成します。

• 製品名
• 対象ユーザー
• ユーザーの課題
• 主なユーザーフロー
• 主要な機能
• 主な制約または前提条件

軽量な内容にとどめます。目的は、詳細な確認を進めるための十分な骨組みを作ることであり、仕様を完成させることではありません。

2. PRD を正式な設計ドキュメントにする

PRD.md を読み、design-document.md を作成する前に、的を絞った確認質問をします。PRD がまだ曖昧なまま、設計ドキュメントの作成に進んではいけません。

作成する設計ドキュメントは、実装上の決定を可能にする内容にします。少なくとも次の項目を扱います。

• 対象範囲と対象外
• ユーザージャーニー
• 機能の動作
• エッジケース
• データまたは状態のモデル
• 受け入れ基準

ユーザーから段階的に回答があった場合は、設計書に沿って実装できる状態になるまで、ドキュメントを継続して改善します。

3. 技術スタックを推奨する

推測ではなく、design-document.md をもとに tech-stack.md を作成します。流行や幅広さより、シンプルさと堅牢さを優先します。

主要なレイヤーごとに、実用最小限のスタックを選びます。

• アプリケーションフレームワーク
• バックエンド／ランタイム
• ストレージ
• 認証
• デプロイ
• テスト

選定理由は簡潔かつ明確に記載します。

4. プロジェクトメモリとエージェント向け指示を準備する

設計とスタックが安定したら、次の作業を行います。

• ワークフローまたはユーザーの指示で許可されている場合、不要になった PRD.md を削除する
• 環境が対応している場合、リポジトリの初期化フローを実行する
• AGENTS.md および／または CLAUDE.md に、必須の memory-bank ルールが含まれていることを確認する
• memory-bank/ を作成する
• design-document.md、tech-stack.md、implementation-plan.md を memory-bank/ に移動する
• 空の memory-bank/progress.md と memory-bank/architecture.md を作成する
• ファイルの移動後、ドキュメント内のパスを修正する

AGENTS.md と CLAUDE.md のどちらか一方しか存在しない場合は、そのファイルを更新します。両方存在する場合は、内容を一致させます。

次のブロックを追記します。

## 重要提示

- 写任何代码前必须完整阅读 memory-bank/@architecture.md
- 写任何代码前必须完整阅读 memory-bank/@design-document.md
- 每完成一个重大功能或里程碑后，必须更新 memory-bank/@architecture.md

5. 実装計画を作成する

design-document.md と tech-stack.md をもとに、implementation-plan.md を作成します。

計画の各ステップは、次の条件を満たす必要があります。

• 小さい
• 具体的
• 順序立てられている
• コードを含まない
• 個別に検証可能

各ステップには、それぞれの検証方法またはテストの期待結果を記載します。「バックエンドを構築する」「フロントエンドを完成させる」のような曖昧なステップは認めません。

6. 実行可能になるまで計画を改善する

memory-bank/ 全体を読み、計画を明確にするために必要な質問をします。別のエージェントが製品の意図を再確認せずに実行できるほど、実装計画が明確になるまで続けます。

確認を行うたびに、ドキュメントを更新します。

実行ループ

7. 一度に計画のステップを1つだけ実行する

コードを書く前に、次を読みます。

• memory-bank/architecture.md
• memory-bank/design-document.md
• memory-bank/implementation-plan.md
• memory-bank/progress.md

そのうえで、現在の計画ステップだけを実行します。

ユーザーがテストの実行を明示的に委任しない限り、ユーザーがテストの判定者であると想定します。現在のステップの検証が完了するまでは、次のステップに進みません。

ユーザーがステップを確認した後は、次の作業を行います。

• 簡潔な記録を memory-bank/progress.md に追記する
• 新規または変更されたファイルと、そのファイルが存在する理由を memory-bank/architecture.md に記載する

8. 新しいコンテキストを読み込んで繰り返す

以降の各ステップに進む前に、memory-bank/ ファイルと最新の progress.md を再読み込みしてください。コンテキストの品質が低下している場合は、記憶に頼らず、明示的にコンテキストをクリアして再構築してください。

必ず守るルール

• 要件が不明確な場合は、確認の質問をしてください。
• implementation-plan.md にコードを含めないでください。
• ステップ N の検証が完了する前に、ステップ N+1 を開始しないでください。
• progress.md は実行ログとして保ち、設計ドキュメントにしないでください。
• architecture.md は、重要なファイルとその役割を示す最新のマップとして保ってください。
• Git が利用可能で、ユーザーが復元ポイントを希望する場合は、ブートストラップ後や主要なマイルストーンの後にチェックポイントコミットを行うことを優先してください。
• ユーザーが別の規約を明示的に希望しない限り、このワークフローのファイル名を維持してください。

エージェント固有のメモ

• Codex 固有の動作とパッケージ化に関する注意事項は、references/codex.md を読んでください。
• Claude Code 固有の動作とマーケットプレイスに関する注意事項は、references/claude-code.md を読んでください。
• ワークフローの各段階ですぐに送信できるプロンプトテンプレートが必要な場合は、references/prompts.md を読んでください。