Sebastian Schkudlara
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
████████████████████████████████████████████████
██ ██████ ██████ ███████
██ ██◉ ◉██ ██ ██ ██
██ ██ ▽▽ ██ ██████ █████
██ ██ ◡◡ ██ ██ ██
██████ ██████ ██ ███████
████████████████████████████████████████████████
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
any cli implements · any cli validates
Today we’re open-sourcing Lope: an autonomous sprint runner with a multi-CLI validator ensemble. One AI CLI writes the code. A different AI CLI reviews it. Majority vote decides if the phase ships. No single-model blindspot.
GitHub: github.com/traylinx/lope · MIT licensed · v0.3.0 (first public release) · Zero Python dependencies.
The blindspot problem nobody wants to admit
Here’s a thing that happens every day in every codebase that uses AI assistants. Claude writes a function. You ask Claude if the function is correct. Claude says yes. You ship it. It breaks in production because the edge case Claude didn’t think of writing is also the edge case Claude didn’t think of reviewing.
This is correlated failure. The same reasoning that produced the bug approves the bug. It’s not a Claude problem specifically. GPT-4 has it. Gemini has it. Every model has it when it reviews its own output, because the blindspots in its training distribution show up on both sides of the loop.
Humans solved this a long time ago. We call it code review, and the entire point is that a different pair of eyes with a different frame catches things the first pair missed. Two senior engineers who trained at different companies will find different bugs in the same diff. That’s not a flaw. That’s the mechanism.
Lope applies that same principle to AI-written code. Different models have different blindspots. Run them against each other and the gaps show up.
What Lope actually does
Lope is a sprint runner. You tell it a goal. It drafts a structured sprint document (phases, deliverables, success criteria), sends the draft to your chosen AI CLIs for review, revises until everyone passes, and then executes the sprint phase by phase with another validation pass after each phase.
Here’s what running it looks like from inside Claude Code:
You: /lope-negotiate "Add JWT auth with refresh tokens"
Round 1 drafter proposes sprint doc (4 phases)
Round 1 opencode + vibe + gemini review... NEEDS_FIX (0.78)
- Missing rate limiting on refresh endpoint
- No test for token expiry edge case
Round 2 drafter revises
Round 2 opencode + vibe + gemini review... PASS (0.93)
Saved: SPRINT-JWT-AUTH.md
You: /lope-execute SPRINT-JWT-AUTH.md
Phase 1 scaffold ................ PASS 0.95 12s
Phase 2 core-middleware ......... PASS 0.91 34s
Phase 3 refresh-rotation ........ PASS 0.88 28s
Phase 4 integration-tests ....... PASS 0.94 19s
4/4 PASS | avg confidence 0.92 | 93s
That’s the entire loop. Negotiate, execute, audit. Each phase produces a verdict block with status, confidence, and specific fix instructions on failure. Three attempts per phase before it escalates. The whole thing is logged to a journal file so you can grep “why did phase 2 fail last Tuesday” six months later.
12 built-in validators, infinite custom ones
Lope ships with adapters for 12 AI CLIs out of the box. All of them are unmodified, off-the-shelf binaries — no plugins, no API key juggling inside lope. If claude --print "hello" works in your terminal, Claude is a Lope validator.
| CLI | What it is |
|---|---|
| Claude Code | Anthropic’s coding CLI |
| OpenCode | The SST team’s terminal agent |
| Gemini CLI | Google’s CLI |
| OpenAI Codex | OpenAI’s coding CLI |
| Mistral Vibe | Mistral’s fresh coding CLI (first-class adapter) |
| Aider | The classic git-native coder |
| Ollama | Local models, zero auth |
| Goose | Block’s open-source agent |
| Open Interpreter | The OG code interpreter |
| llama.cpp | Fastest local inference |
| GitHub Copilot CLI | GitHub’s gh copilot command |
| Amazon Q | AWS’s developer assistant |
And if you want something that isn’t in that list, you add it with five lines of JSON in ~/.lope/config.json. Two provider types cover every AI backend: subprocess for CLI tools and http for API endpoints. That’s the whole extension mechanism.
Not just code: engineering, business, research
The same validator loop that catches bugs also catches gaps in a marketing brief, a financial close process, a systematic literature review, a consulting deliverable, or a GDPR compliance audit.
# Engineering
lope negotiate "Add rate limiting to the API gateway"
# Business
lope negotiate "Q2 marketing campaign for enterprise segment" --domain business
# Research
lope negotiate "Systematic review of transformer efficiency papers" --domain research
Same core loop. Different role prompt, different labels, different checks.
Intelligent caveman mode
The phrase is a wink. The mode sounds primitive (drop articles, grunt in fragments) but the compression is linguistically precise. Code, paths, line numbers, error messages, and commands stay exact. Only the wrapper prose gets grunted away.
Before: “I’ve reviewed the proposal carefully and I think there are a few issues that should probably be addressed before moving forward. Specifically, I noticed that the authentication middleware doesn’t appear to handle the case where the token has just expired…”
After, caveman mode on: “Auth middleware misses expired-token edge case. Add rate limit on /refresh endpoint. Fix at middleware/auth.go:142.”
50–65% fewer tokens per response, same information. Across a sprint with 3 validators, 4 phases, and 1 retry average, the savings compound fast on paid APIs. Credit where it’s due: core terseness rules come from JuliusBrussee/caveman (MIT).
What’s new in v0.3.0
Two-stage validator review per phase. Validators run a spec-compliance pass first (“does this output match the phase goal?”), then a separate code-quality pass. A spec NEEDS_FIX short-circuits the quality pass so you never waste a quality review on code that doesn’t match the requirement.
Verification-before-completion evidence gate. Any validator that returns PASS with a rationale that lacks evidence — no file:line reference, no test output, no explicit verification phrase — gets auto-downgraded to NEEDS_FIX. This kills rubber-stamping at the framework level.
No-placeholder lint on drafts. If the negotiator produces a sprint doc that contains TBD, TODO, XXX, or phases with empty artifact lists, the lint fires and the drafter loops back before any validator round. Much cheaper than paying validators to say “you forgot to fill in phase 3.”
Also new: a SessionStart hook that briefs your AI agent that lope is available, and a using-lope auto-trigger skill that recognizes natural-language descriptions of multi-phase work and invokes lope on your behalf.
Install: paste one line into any AI agent
No pip. No virtualenv. No dependency hell. Pure Python stdlib.
Copy this line and paste it into any AI agent you already use — Claude Code, Codex, Gemini CLI, OpenCode, Cursor:
Read https://raw.githubusercontent.com/traylinx/lope/main/INSTALL.md and follow the instructions to install lope on this machine natively.
Your agent fetches INSTALL.md, follows the six short steps, auto-detects which CLIs you already have, and writes slash commands into each host’s native directory. About 30 seconds end to end.
After install, these slash commands work inside your CLI of choice:
/lope-negotiate— draft a sprint doc with multi-round validator review/lope-execute— run sprint phases with validator-in-the-loop retry/lope-audit— generate a scorecard with per-phase verdicts
Try it, break it, open issues
This is v0.3.0 — the first public release. It works well for the use case it solves but we are actively learning from users. If you hit a rough edge, open an issue. If you find a pattern we should codify, open a PR. If you build a custom validator config for a CLI we don’t support yet, share it in the repo’s discussions.
github.com/traylinx/lope — Star it, break it, tell us what’s missing.
— Sebastian