Knowledge Base for Mistral Vibe Code
Vibe Code can load project configuration, skills and instructions from trusted folders. These settings shape how it works and what tools it can run. Busabase gives the team a separate place to propose, review and preserve engineering decisions rather than treating local trust as approval of every result.
The missing layer
Trusting a folder is not approving its output
Trusted folders, agent modes and per-tool permissions shape what Vibe may execute. Accepting a migration or fix for team reuse is a different decision, supported by code and test evidence.
From proposal to accepted knowledge
Start the next task from accepted knowledge
Read applicable accepted records
Check source dates and applicability before supplying relevant accepted records to the agent.
Propose an evidenced update
Turn a finding into field-level changes with sources, execution version and open questions; submit a ChangeRequest.
Review the exact changes
A reviewer checks changes and evidence, requests revisions, approves or rejects. An authorized role merges approved changes.
Reuse accepted findings
People and agents read the merged state. Propose a revision when a claim changes and retain its history.
What to preserve
Link a migration decision to the checked commit and environment
Suppose one service has passed a dependency upgrade while others remain untested. Preserve that bounded decision, not a claim that every service can upgrade. The following is a suggested record contract.
Decision and scope
Dependency version, verified services and environments, exceptions and rollback conditions. Mark untested scope explicitly.
Configuration and execution
Source commit, interactive or programmatic run, explicit agent mode, trusted folder and relevant tool permissions.
Acceptance evidence
Final diff, test or build links, failures and repository review outcome. A successful command does not prove the migration is safe.
Accountability and follow-up
Decision owner, review status, next task and revalidation conditions. Propose revisions when later commits change those conditions.
Choose the right knowledge layer
Resolve execution permissions before preserving engineering facts
Trusted folders, agent modes and per-tool permissions shape what Vibe may execute. Accepting a migration or fix for team reuse is a different decision, supported by code and test evidence.
| Knowledge layer | Best place for | Basis for trust |
|---|---|---|
| Project guidance and configuration | Keep instructions, skills and agent configuration in project or user configuration files. Record the effective scope rather than embedding changing business status into instructions. | Project guidance and configuration |
| Code and tests | Keep commits and test artifacts in the repository and build system. Busabase references the evidence and necessary findings; it does not become another code repository. | Code and tests |
| Engineering decisions | Preserve the accepted migration, applicable versions, exceptions and owner. Execution mode is context for review, not the acceptance decision itself. | A reviewer checks changes and evidence, requests revisions, approves or rejects. An authorized role merges approved changes. |
| Busabase | Suppose one service has passed a dependency upgrade while others remain untested. Preserve that bounded decision, not a claim that every service can upgrade. The following is a suggested record contract. | People and agents read the merged state. Propose a revision when a claim changes and retain its history. |
Connection and review boundaries
Verify access, then limit write authority to proposals
Vibe’s active agent and per-tool permissions control execution. Programmatic runs fall back to auto-approve if no agent is specified. A project’s configuration and a proposed knowledge update therefore need distinct controls. For a migration decision, save the source commit, rationale, test evidence and owner. Vibe CLI currently documents no MCP OAuth support: use its supported static-credential configuration with a changeRequest-scoped Busabase key, verify the workspace, then test read-only access before proposing updates. This is a documented setup path, not a tested integration claim.
When to use
Share cross-project decisions, not every temporary code explanation
Use shared review
Use this when repositories reuse a migration finding, release exceptions need an accountable owner, or another agent needs to distinguish accepted scope from pending validation.
Use a simpler tool
Skip it for one-off explanations, configuration backups, patches and raw test logs. If Git and existing code review fully cover the need, do not add a redundant approval system.
Knowledge Base for Mistral Vibe Code · Questions
Is folder trust the same as approving a change?
No. Trust allows project configuration to load; tool execution and record acceptance are separate decisions.
Can the CLI use Busabase OAuth?
Current Vibe CLI documentation says OAuth-required MCP servers are not supported. Use the documented static-credential route and keep credentials out of committed files.
What should an unattended run specify?
Set the agent explicitly. Vibe warns that programmatic mode defaults to auto-approve when --agent is omitted; use plan when the task must remain read-only.
Does auto-approve approve a Busabase proposal too?
Vibe mode controls tool execution, not Busabase review authority. Restrict the static key to changeRequest permission; record acceptance still requires independent review and authorized merge.
Should .vibe configuration be copied into the knowledge base?
Usually not. Keep configuration at its source and reference its version and effective scope. Never copy credentials, complete user settings or environment secrets into the record.
Start with one reviewed record
Give the next task knowledge with sources and an owner
Choose one result the team will reuse, define a minimal record and reviewer, then validate access and proposal permissions using the connection guide.