disco is a daemon-first Go CLI.
A long-running background daemon handles rule ingestion, builds a persistent vector store, and performs RAG-powered code reviews. The lightweight CLI client simply sends git diffs to the daemon and displays the results — making every subsequent review extremely fast.
It currently supports running everything locally using Kronk (for both embeddings and generation), as well as hybrid setups with Mistral (and more providers planned in the future).
go install ./cmd/discoor:
make install- Go toolchain matching
go.mod(go 1.26.0) - Mistral API key if you don't want to use Kronk all the way
- This Playlist
STYLE_GUIDE_DIR(default:./styleguides)EMBEDDING_PROVIDER(kronkormistral, default:kronk)GENERATION_PROVIDER(kronkormistral, default:kronk)MISTRAL_API_KEY(required when either provider ismistral)MISTRAL_MODEL(default:mistral-small-latest, generation)MISTRAL_EMBED_MODEL(default:mistral-embed, embeddings)MISTRAL_BASE_URL(default:https://api.mistral.ai)
- EMBEDDING_PROVIDER=kronk
- GENERATION_PROVIDER=mistral
- MISTRAL_API_KEY=... (required)
- MISTRAL_MODEL=mistral-small-latest (set as default in the code, but you can override here)
- MISTRAL_BASE_URL=https://api.mistral.ai (default exists)
- Start the daemon to ingest
style.md
disco daemon start
- To evaluate a git diff against the guidelines
disco review --diff sample-review.diff
Disco expects exactly one markdown style guide in STYLE_GUIDE_DIR at daemon startup.
Current behavior:
- startup ingests style guide automatically
- retrieval is evidence-driven and attached to findings as citations
Recommended layout:
styleguides/
disco/
style.md
I have it set with my personal style guide, but you can add your own. Just be attentive to include the necessary fields for the "roleplaying" ;]
### Error and Logging
## RG-ERR-001 - Wrap propagated errors with context
Type: rule
Enforcement: block
Taxonomy: error_handling
Skill_Primary: Logic
Difficulty_Base: Challenging
Scope: production code and library code
### Statement
When returning an upstream error to a higher layer, wrap it with context using `%w`.
### Rationale
Context makes logs and traces actionable without losing root-cause identity.
### Bad
```go
if err != nil {
return err
}
```
### Good
```go
if err != nil {
return fmt.Errorf("could not load config: %w", err)
}
```
### Notes
At process boundaries where context is already attached one layer above, returning as-is can be acceptable.
If the guide is missing, duplicated, or malformed, startup should fail fast.
disco daemon install
disco daemon start
disco daemon status
disco daemon stop
disco daemon uninstallFor RAG. Keep it running in the background.
Review from file:
disco review --diff sample-review.diffReview from git refs:
disco review --repo . --base main --head HEADCommon flags:
--diffpath to unified diff file--reporepository path for git diff mode--basebase ref for git diff mode--headhead ref (default:HEAD)
Typical review flow:
- hunk progress stream (
evaluating hunk X/Y ...) - queued checks
- interactive check-by-check output with:
- narrative line(s)
- technical message
- citation
- good example snippet
Severity mapping:
high-> likely blockermedium-> should be fixed before mergelow-> advisory but still worth fixing
Difficulty labels (Challenging, Formidable, Legendary, etc.). You set them directly in the style guide.
But don't take it too seriously. You can use it as policy, but I've added them more to match the game style.
- Keep diffs focused. Smaller hunks improve retrieval and judgment quality. Also time.
- Treat model output as guidance, not scripture. Verify against citation and code.
- Run tests after fixes. Style checks do not replace correctness checks.
Known limits:
- review v1 focuses on Go hunks (
*.go) - model output can still produce false positives or awkward phrasing. it depends a lot on the model you're using.
- retrieval quality depends on guide structure and metadata consistency
Contributions are welcome. Really! There are a lot of improvements that I would like to make but don't have time.
For example:
- sounds? would be cool, huh?
- more AI cloud providers?
- integration with opencode and stuff like that?
- Improved UI? if you have ideas
- tests!
- zsh completion
- gh workflow "revachol CI" =D
- [ insert your cool idea here ]
Just open an issue and we'll chat about it.
make fmt
make test
make vet
make vulncheckYou know the drill.
Then what I usually run during development:
disco main• ❱ make install
disco main• ❱ disco daemon stop && disco daemon uninstall && disco daemon install && disco daemon start
disco main• 1.3s ❱ disco review --diff sample-review.diff
- if you changed only
internal/pkg/cli/*(client output/UX), go install/run is enough - if you changed daemon-side code
(internal/runtime/*, internal/review/*, internal/llm/*, internal/policy/rag/*, server transport)or daemonenv vars, restart daemon
disco was an inspiration for this project. So cool. And I wanted to have a reason to play with kronk, which allowed me to spin up the LLM directly from Go code.
Generation failed or returned invalid payloads for some/all hunks.
- verify daemon env (
GENERATION_PROVIDER, model, key) - restart daemon after env changes
- inspect daemon logs
Launch service env may be stale.
- run
stop/uninstall/install/startagain
The daemon takes around 10s to warm up and ingest all the rules. Running disco daemon status during this time might return running, but hey, you can make it better.
Common causes:
- wrong
STYLE_GUIDE_DIR - zero or multiple markdown guides
- malformed guide metadata
Install completion:
disco completion fish > ~/.config/fish/completions/disco.fishmacOS/fish/ghostty. well, I haven't tested it anywhere else.
Apache License 2.0. See LICENSE.