disco is a local daemon and CLI for style guide enforcement via RAG.
It dwells in the shadows of your machine as a long-running background service. Spin it up once and it devours your Markdown style guide, forging a persistent vector index of every rule. Then the CLI steps in as your hungover detective. Feed it a diff (from git, a file, or --base/--head), it whispers the changes to the daemon, and the daemon stirs, tasting the code against its indexed wisdom, retrieving exact citations, and spitting out skill-check verdicts, severity ratings, and biting suggestions.
go install ./cmd/discoor:
make installTypical workflow:
- Install and start the daemon to ingest
style.md
disco daemon install
disco daemon start- To evaluate a git diff against the guidelines
disco review --diff sample-review.diff
- Go toolchain matching
go.mod(go 1.26.0) - Mistral API key if you don't want to use Kronk all the way
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 if using mistral, ofc)
- 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)
If using Krong, the model is still hardcoded in internal/llm/kronkgen/generator.go (sorry). For more options, see Kronk Catalog.
The quality of the model will affect the quality of the evaluations, narration, and performance. Thus, there is a consideration between using everything with Kronk or an AI cloud provider.
Disco expects exactly one (for now) 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
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.
For RAG. Keep it running in the background.
disco daemon install
disco daemon start
disco daemon status
disco daemon stop
disco daemon uninstallReview from file:
disco review --diff sample-review.diffReview from git refs:
disco review --repo . --base main --head HEADTypical 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.
- 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:
- 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 idea here ]
Just open an issue and we'll chat about it.
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 allows 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 10 seconds on my machine to warm up and ingest all the rules. Running disco daemon status during this time might return running, but hey, you can make that better.
Common causes:
- wrong
STYLE_GUIDE_DIR - zero or multiple markdown guides
- malformed guide metadata
macOS/fish/ghostty. well, I haven't tested it anywhere else.
Apache License 2.0. See LICENSE.