Communityコーディング&開発github.com

バイブビルド

ゼロからソフトウェアを構築するための完全なエンドツーエンドの「バイブコード」ワークフローです。リサーチ、ブートストラップ、計画、構築、検証、出荷までをエージェントが自律的に実行するため、ユーザーはプロセスを説明する必要がありません。新規プロジェクトの開始時や「これを作って」といった指示に最適です。

バイブビルド とは?

このスキルは、AIエージェント(Claude Code, Cursor, Codex等)がソフトウェアプロジェクトをゼロから完全に自律的に構築するための包括的なワークフローを提供します。ユーザーは「何を構築するか」という製品上の意思決定のみを行い、プロセスの詳細はすべてエージェントが管理します。スキルは6つのフェーズ(ブートストラップ、計画、構築、検証、出荷、一時スキルの後片付け)で構成され、各フェーズでエージェントは具体的なアクションを実行します。特に、プロジェクト開始時に自動的に`AGENTS.md`を生成してプロジェクトの憲法とし、以降のすべての構造的決定においてそれを参照することで、ユーザーがコンベンションを再説明する手間を省きます。また、テスト規律、依存関係の最小化、トークン消費の最適化など、プロフェッショナルなソフトウェア開発のベストプラクティスを内蔵しており、シンプルなスクリプトから本格的なWebアプリケーションまで幅広く対応します。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Ryuki0x1/vibe-build/tree/main/skills/vibe-build

Installed? Explore more コーディング&開発 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

バイブビルド は何をしますか?

エージェントが自律的に実行する完全なビルドワークフロー。ユーザーは製品上の意思決定を行い、あなたはプロセス上の意思決定を行います。ワークフローの説明をユーザーに求めないでください。それに従ってください。ユーザーに尋ねるのは、何を構築するか、好み、およびゲートでの承認についてのみです。

ただ一つのルール

製品上の意思決定 = ユーザー入力。プロセス = あなたのもの。ユーザーに何かを尋ねる前に、それが製品上の意思決定かどうかを確認してください。そうでない場合は、自分で判断して先に進みます。

フェーズ0 — ブートストラップ(新規プロジェクトのみ)

  1. スタックを特定します。プロジェクトがまったく定義されていない場合は、正確に1つの質問をしてください。「何を構築しますか?(一文で十分です)」 インタビューはしないでください。
  2. スタックを自分でリサーチします:現在のフレームワークバージョン、推奨セットアップ、標準的なプロジェクトレイアウトを、Web検索とフレームワークドキュメント(プロジェクトのドキュメント検索機能またはWeb検索を使用)を使って調べます。決定事項を最大5行で要約します — リサーチの壁をユーザーに貼り付けないでください。
  3. プロジェクトルートにAGENTS.mdを書き込みます。references/agentsmd-template.mdのテンプレートを使用します。これがプロジェクトの憲法です:以降のすべてのフェーズは、構造的な決定を行う前にそれを読み、ユーザーがコンベンションを再説明する必要がなくなります。
  4. プロジェクトに必要な一時スキル(最大5つ)をインストールします。references/temp-skills.mdに従ってください。プロジェクトが単純であるか、既存のスキルでカバーできる場合は、スキルのインストールを完全にスキップします。
  5. ブートストラップを15行以内で報告し、提案する番号付き計画を提示し、プロジェクトコードを書き始める前に承認を待ちます。

フェーズ1 — 計画

  • 番号付きのスコープを定めた計画を作成します。1回のセッションで完了できる小さなタスクと、後回しにする明示的な項目。
  • 明示的な承認を得ます。ユーザーが計画を編集した場合は、編集内容が優先されます。
  • インターリーブに注意:計画がまだオープンな間に構築を開始しないでください。

フェーズ2 — 構築

  • プロジェクトに適している場合はテスト規律に従います:ロジックにはテスト、使い捨てのグルーコードには手動チェック。単純なビルドに重いテストフレームワークを発明しないでください。バグが害を及ぼすロジックのテストをスキップしないでください。
  • 依存関係は最小限に保ちます。すべての依存関係はユーザーが継承する負債です — 明確な見返りがない限り、stdlib/ゼロ依存を優先します。
  • 構造的な決定の前にAGENTS.mdを確認します。作業が二分探索可能になるように、小さな名前付きステップでコミットします。

フェーズ3 — 検証(「完了」と主張する前に)

プロジェクトを実行し、動作を証明します:

  • UIが存在する → 実際のブラウザでクリックスルーします(Playwrightまたはエージェントのブラウザツール)。コンソールエラーをチェックし、メインフローがエンドツーエンドで動作することを確認します。
  • Web UI → アクセシビリティとインタラクションの品質(フォーカス状態、フォーム、ダークモード、タッチ)を監査します:利用可能な場合はデザインガイドラインレビュースキルを使用し、そうでない場合は自己チェックします。
  • 認証、シークレット、支払い、またはユーザー入力に触れた → セキュリティパスを実行します:入力検証、シークレットの取り扱い(シークレットをコミットしないでください。環境変数置換を使用します)、最小権限のデフォルト。
  • アサーションの前に証拠:何が実行され、何が合格したかを報告するか、失敗したことを認めて最初に修正します。

フェーズ4 — 出荷

  • 「デプロイ / 公開 / プレビューリンク」 → プロジェクトのドキュメント化されたパスを介してデプロイします。Vercelでホスト可能なプロジェクトの場合、リンクされたプロジェクトにgit-pushし、ログインが存在しない場合はvercel deploy --temporaryにフォールバックし、URLを返します。
  • プルリクエスト:簡潔な本文 — 何が変わったか、なぜか、テスト方法 — 差分の説明ではありません。
  • 「完了」コミットは、今収集した証拠に基づいてビルド+テストがパスすることを意味します。

フェーズ5 — 一時スキルの後片付け

一時スキル(フェーズ0ステップ4)はプロジェクトスコープです。プロジェクトの終了時、または一時スキルが広く有用であることが証明された場合、ユーザーの共有スキルディレクトリに昇格させる(または削除する)ことを推奨します。一時スキルを静かに恒久的なグローバルインストールに変異させないでください。

トークン節約(全フェーズ)

最小限の十分なファイル範囲を読みます。既に見たファイル全体を再読み込みしないでください。完了したフェーズは、各ステップをナレーションするのではなく、一度だけ要約します。スクリプトとツールの内容をチャットに貼り付けるのではなく、それらを実行することを優先します。スキルはトリガーによって遅延ロードさせ、スキルの本文を会話にダンプしないでください。

参考文献

関連スキル