Busabase × Mistral Vibe Code

Mistral Vibe Codeのナレッジベース

Vibe Codeは信頼したdirectoryからproject設定、Skill、指示を読み込みます。これらは動作と使えるtoolを変えます。Busabaseでは開発上の判断を別に提案・reviewし、directoryのtrustと結果の採用を区別できます。

デモワークスペース · 変更案 確認の例
Busabaseの実際の英語デモ画面です。このAgentとの接続検証画面ではありません。
Busabaseの実際の英語デモ画面です。このAgentとの接続検証画面ではありません。

不足している層

Directoryのtrustと結果の承認は別です

信頼するディレクトリ、Agentモード、ツール別権限は実行を制御します。一方、移行や修正の結論をチームで採用するには、コードとテストの根拠が必要です。

01

プロジェクトの指示と設定

指示、Skill、Agent設定は元の設定ファイルに残します。実際に有効だった範囲を記録し、変化する業務状態を指示へ埋め込みません。

02

コードとテスト

コミットとテスト成果物はリポジトリやビルドシステムで管理します。Busabaseにはリンクと必要な結論を残し、第二のコード保管庫にはしません。

03

開発上の判断

採用した移行方法、対象バージョン、例外、担当者を残します。実行モードは確認の背景情報であり、採用判断そのものではありません。

提案から正式な知識へ

次の作業を採用済みの知識から始める

01

適用できる正式な記録を読む

資料の日付と適用範囲を確認し、作業に関係する正式な記録をAgentに渡します。

02

根拠を添えて更新を提案する

結論を項目ごとの変更に整理し、出典、実行の版、未解決事項を添えてChangeRequestで提案します。

03

具体的な変更を確認する

担当者が変更と根拠を確認し、修正、承認、却下を判断します。承認後、権限のある役割がマージします。

04

採用した結論を再利用する

人とAgentはマージ後の状態を読みます。結論が変わったら修正を提案し、履歴を残します。

残すべき情報

移行判断を確認済みのコミットと環境につなぐ

一つのサービスだけで更新が検証できた場合、全サービスの更新が安全だとは記録しません。以下は範囲を限定した判断を残すための設計例です。

残すべき情報

判断と範囲

依存関係の版、検証済みサービスと環境、例外、戻す条件。未検証の範囲を明示します。

設定と実行方法

元のコミット、対話またはプログラム実行、明示したAgent、信頼した場所、ツール権限。

採用の根拠

最終差分、テストやビルドへのリンク、失敗項目、コード確認の結果。コマンドの成功だけでは不十分です。

責任と再確認

担当者、確認状態、次の作業、再検証する条件。後のコミットで条件が変われば修正を提案します。

知識の置き場所

実行権限を確認してから、残すべき開発上の事実を選ぶ

信頼するディレクトリ、Agentモード、ツール別権限は実行を制御します。一方、移行や修正の結論をチームで採用するには、コードとテストの根拠が必要です。

知識の層 残す情報 信頼の根拠
プロジェクトの指示と設定 指示、Skill、Agent設定は元の設定ファイルに残します。実際に有効だった範囲を記録し、変化する業務状態を指示へ埋め込みません。 プロジェクトの指示と設定
コードとテスト コミットとテスト成果物はリポジトリやビルドシステムで管理します。Busabaseにはリンクと必要な結論を残し、第二のコード保管庫にはしません。 コードとテスト
開発上の判断 採用した移行方法、対象バージョン、例外、担当者を残します。実行モードは確認の背景情報であり、採用判断そのものではありません。 担当者が変更と根拠を確認し、修正、承認、却下を判断します。承認後、権限のある役割がマージします。
Busabase 一つのサービスだけで更新が検証できた場合、全サービスの更新が安全だとは記録しません。以下は範囲を限定した判断を残すための設計例です。 人とAgentはマージ後の状態を読みます。結論が変わったら修正を提案し、履歴を残します。

接続と確認の境界

アクセスを確認し、書き込みを提案に限定する

実行はactive agentとtool別権限で制御します。Programmatic modeでagentを指定しない場合はauto-approveになります。Project設定と知識の更新には別の管理が必要です。 Migrationの判断なら、commit、理由、test、ownerを残します。現在のVibe CLIはMCP OAuthをサポートしません。静的credential設定とBusabaseのchangeRequest権限を使い、workspaceとread-only接続を確認してから提案します。これは文書に基づく設定方法で、実機検証済みの連携ではありません。

文書変更の確認例
Busabaseの実際の英語デモ画面です。このAgentとの接続検証画面ではありません。

適する場面

共有するのは複数プロジェクトの判断で、仮の説明ではない

共有する確認が必要

複数リポジトリで移行結果を使う場合、リリースの例外に責任者が必要な場合、別のAgentが採用済み範囲と未検証範囲を区別する場合に適します。

より簡単なツールで十分

一度限りの説明、設定のバックアップ、コード差分、テストログ全体には不要です。Gitと既存の確認で十分なら、重複した承認を増やしません。

Mistral Vibe Codeのナレッジベース · よくある質問

Directoryをtrustすると変更も承認されますか?

いいえ。Trustはproject設定の読み込みを許可します。実行と記録の採用は別です。

CLIでBusabase OAuthを使えますか?

現行のCLI文書ではOAuthが必要なMCPは未対応です。静的credentialを使い、repositoryへ保存しないでください。

無人実行で何を指定しますか?

Agentを明示します。--agentを省略したprogrammatic modeはauto-approveになるため、read-onlyならplanを指定します。

auto-approveならBusabaseの提案も承認されますか?

いいえ。Vibeのモードは実行を制御し、Busabaseの承認権限は与えません。キーはchangeRequest権限に限定し、別途確認と権限のあるマージを行います。

.vibe設定を知識庫にコピーすべきですか?

通常は不要です。元の設定を管理し、版と有効範囲を参照します。認証情報やユーザー設定全体、環境の秘密は記録しません。

確認済みの記録から始める

次の作業に出典と担当者のある知識を渡す

チームで使う結果を一つ選び、最小限の記録と確認者を決めます。接続ガイドでアクセスと提案権限を検証します。