DRIFT
Context-heavy setup
See which repo layers are carrying too much memory, instruction weight, or setup noise before new projects inherit the same sprawl.
VibeSmith
Audit AI coding repo drift before it spreads.
VibeSmith gives multi-repo teams one place to review active components, dependency risk, and context-heavy reuse across Cursor and Claude Code workflows. It is open-source on GitHub, with prerelease installs available today.
If kickoff quality drops after repo three, start here.
Live dashboard and walkthrough
Open-source on GitHub
Built for multi-repo AI teams
WHAT SURFACES FIRST
See the problems teams usually discover too late
VibeSmith is most useful when your team needs one visible layer for setup drift, reuse risk, and context-heavy sprawl across repositories.
REUSE
Hidden reuse risk
Review what needs to move with a component so copy-paste bootstrap stops failing in partial, expensive ways.
RELEASE
Dependency and conflict surprises
Surface linked risk earlier so release-week review is not the first time your team sees the coupling.
FIRST-WEEK PAIN
What teams want from the first real audit
The common request is not another AI feature. It is a clearer operating view across repos.
Need 01
Know which standards are actually active
Teams lose time when rules, commands, and guidance look similar but differ just enough across repos to change behavior.
Need 02
Reuse without losing linked context
Users want to copy safe baselines, not half-working fragments that hide dependencies until later.
Need 03
Reduce context waste before it becomes review waste
Mixed memory layers and stale assets create token waste, noisy prompts, and longer review loops.
Visual Proof
Workflow proof from real multi-repo AI team pain
Start with the inline walkthrough, then inspect each decision screen below.
- Playable walkthrough on this page
- Decision-focused screens
- Repo-scale visibility
Use the inline walkthrough for the overall flow, then inspect the still screens below for specific decision points.
Core Workflows
How VibeSmith reduces drift
Find the active baseline
Unified inventory + search shows which Skills, Agents, Commands, Hooks, and Rules are still active across projects.
Reuse without dropping linked pieces
Copy components with dependency-aware flow so bootstrap stays coherent instead of breaking in partial ways.
Review rollout impact before writing changes
Preview and apply with conflict policy so teams can judge the blast radius before updating shared setup.
See risk before release week
Dependency graph, conflict review, and project scope views make hidden coupling easier to catch earlier.
Why This Matters
AI coding tools speed up one repo before they explain many
Cursor, Claude Code, and MCP are strong local tools. The systems gap appears when teams need the same operating clarity across multiple repos.
Cursor's session-scoped context pushes teams to externalize reusable standards instead of relying on chat memory.
Multi-scope memory/settings in Claude Code increase consistency overhead without a shared operating layer.
MCP expands capability, but server scope and permission boundaries need explicit review discipline.
FIRST-WEEK METRICS
What to measure in week one
You can judge early value from one repo. The question is whether the baseline becomes clearer, not whether a big rollout already happened.
Outcome 01
Faster first stable setup
Time from install to a baseline your team would actually keep.
Outcome 02
Fewer repo-to-repo surprises
Whether copied rules, commands, and components stay coherent after the first reuse.
Outcome 03
Clearer cleanup targets
Which stale, conflicting, or overgrown assets you can remove before context quality degrades.
ADOPTION PATH
Get to proof with one repo first
You do not need an org-wide migration. Start small, measure drift, then expand only if the baseline improves.
Step 1
Connect one live repo
Install the open-source build and scan the repo that keeps reopening the same setup questions.
- Output: first baseline of active components and drift points
- Output: install friction notes
Step 2
Review reuse and dependency risk
Use inventory, detail, and dependency views to see what breaks when setup is copied by memory.
- Output: cleanup candidates
- Output: linked dependency risks
Step 3
Expand only after one workflow feels cleaner
Decide whether another repo should adopt the same baseline after one team can explain the setup clearly.
- Output: keep / fix / expand decision
- Output: shortlist for deeper collaboration or Pro
Adoption Boundary
Adopt when drift is already hurting delivery speed.
Clear boundaries help multi-repo teams decide quickly without overcommitting.
Strong fit
- Three or more active repos share one delivery schedule.
- Kickoff quality drops because rules are handed off manually.
- Release reviews repeatedly discover dependency issues late.
Not ideal yet
- Single-repo setups with stable standards and low change frequency.
- Workflows not ready to define clear criteria for component review decisions.
- Workflows expecting one-click automation without rollout discipline.
Current scope (intentional)
Current scope stays narrow on purpose. The goal is visible proof before wider automation promises.
- No forced repository rewrite. Existing structure is mapped first.
- Cloud-wide policy automation is a later phase, not day one.
- Shared rollout layers expand only after repeated evidence from real repo audits.
Download
Install the open-source VibeSmith build
Choose the GitHub release page, direct DMG download, or Homebrew install path.
Option A. GitHub Release
Open the latest release notes, download the signed DMG, or inspect the open-source repository.
Latest GitHub release
https://github.com/aroido/vibesmith/releasesLatest install package
https://github.com/aroido/vibesmith/releasesGitHub repository
https://github.com/aroido/vibesmithLatest public build: GitHub release channel, including prereleases.
GitHub is the canonical public release channel. GitLab remains a legacy mirror only.
Option B. Homebrew Guide
The GitHub Homebrew tap tracks the same public release channel. Install with Homebrew, or retap first if you used the old GitLab path.
Install and upgrade
brew update
brew tap aroido/vibesmith https://github.com/aroido/homebrew-vibesmith.git
brew install --cask aroido/vibesmith/vibesmith
# If an older version is already installed:
brew update
brew upgrade --cask --greedy aroido/vibesmith/vibesmithPrefer this path for Homebrew installs and upgrades. If you used the legacy GitLab tap, run `brew untap aroido/vibesmith` before retapping.
Start with one repo. Make drift visible first.
The open-source build is the fastest way to see whether component sprawl, hidden dependencies, and context-heavy setup are already slowing your team. If you want outside eyes on one live repo, request an audit after the demo or install pass.