vibe-workflow

アプリワークフロールーター

依頼内容と既存のプロジェクトの状態をもとに、次に有用なアクションを選択します。 成果、制約、現在の実装を把握するために必要なコンテキストだけを読み込みます。 ファイルが存在していても、そのステージが完了しているとは限りません。

• 新規プロダクト： リサーチ、PRD、技術設計のスキルを必要に応じて使います。 クイックモードでは、明確な成果、制約、受け入れまでの流れが必要です。未解決の 統合や重大な決定がある場合は、より詳細な計画が役立ちます。
• 既存プロダクト： 現在のアーキテクチャに沿って、依頼された変更を実装します。 変更用のスキルがあれば使用します。計画書がないからといって、発見プロセスを やり直す必要はありません。
• 動作不良： 不具合を再現し、原因を診断して修正し、検証します。新規プロダクトの ヒアリングをやり直さず、利用可能であればデバッグ用のスキルを使います。
• 指示または引き継ぎのみ： 依頼された成果物を作成し、その限界を報告します。 依頼されていない実装やデプロイを始めないでください。

プロジェクトの指示を作成する場合は vibe-agents、新規実装には vibe-build、 関連するユーザージャーニーには利用可能な検証スキルを使用します。 対象環境に実際に存在するスキルだけを呼び出してください。5 つのステージは有用な 進め方ですが、5 つの承認ゲートでも、編集のたびに必須となる文書一式でもありません。

回答済みの質問と Handoff Context を再利用します。重大な決定に必要な情報が足りない 場合は質問し、それ以外は前提を明示して進めます。安定した制約は AGENTS.md に、 決定事項はプロダクト文書に、プロジェクトで使用している場合は現在の進捗を MEMORY.md に記録します。独立した作業と利用可能なツールによって分担が正当化されない限り、 ビルダーは 1 人で十分です。

関連するチェックと修正を含め、ユーザーが依頼した範囲を完了します。 報告では、実際の結果と未実施のチェックを区別し、具体的な障害があれば明記します。 動作するプロダクトを依頼された場合、最初の実装だけで止めないでください。 ローカル作業が完了したという理由だけで公開することも避けてください。