Score breakdown
Popularity is tracked separately. Support, ads, sponsorships, and tips never affect these signals.
Why it matters
Useful for any developer, agent builder, or organization that wants a persistent, review-controlled long-term knowledge base for LLM agents where every claim is auditable and every write is gated — without black-box auto-injection into the prompt context. The git-native + PR-shaped review gate is the durable differentiator: the KB lives as a folder in your repo, git is your audit log + backup + sy
Who should use it
Who should skip it
Move on from vouchdev/vouch if the licensing terms, language support, or platform requirements do not fit your project.
About this signal
vouchdev/vouch is tracked by RepoRadar as a git-native review-gated knowledg in the Memory & Knowledge section. It was first seen on 2026-07-04 and last updated on 2026-07-04. The current verdict is 'try now' with a Gold tier and easy setup difficulty. Across RepoRadar's eight signals, vouchdev/vouch is strongest on workflow potential (9.5) and practical usefulness (9.0) and weakest on maturity (6.6) — a profile worth weighing against your own priorities. This page summarizes the evidence RepoRadar has captured from captured source metadata. The score, tier, risk label, and verdict on this page are never influenced by sponsorship, ads, or tips — they reflect only the usefulness, popularity, novelty, momentum, maturity, and evidence signals described in the RepoRadar methodology.
How this item is evaluated
RepoRadar assigned vouchdev/vouch a composite score of 8.4 out of 10, placing it in the Gold tier. This score combines weighted sub-signals: usefulness (35%), novelty (18%), momentum (14%), maturity (10%), open-source/build quality (7%), evidence quality (6%), workflow potential (6%), and setup ease (4%). Popularity is tracked separately at 1.0 and never affects the composite score or tier. The risk label of 'low' reflects inherent user-impacting hazards, not generic novelty. Items with no risk flag may still require normal code review before production use.
Putting this into practice? Read How to evaluate an AI tool before you adopt it for the checklist behind this score.
Risk explanation
Still alpha — the README explicitly says 'expect breaking changes pre-1.0'; the proposal/approve API and KB schema may evolve between releases, so users should pin a version for production-shaped workloads; Proposal-only writes are a deliberate gate, but the user owns keeping the rejected drafts out of git history — `proposed/` is gitignored but if the user explicitly reverses that ignore, drafts may leak into committed history; the README documents the gate but does not enforce `proposed/` gitignore in a programmatic way; Multi-agent-shared-repo mode requires per-agent attribution in the audit log to remain useful — if the user runs agents without distinguishing them (e.g. multiple Cursor instances with the same MCP config), the audit log records the agent-claimed provenance but not which physical instance.