Repolens

The problem.

When I'm building, I want to know what an industry-standard repo looks like before modeling my own work on it. When I'm reading code, I want a single screen that tells me whether this repo is worth adopting. Both reduce to the same question: structured assessment of an entire codebase, surfaced in seconds, not hours.

Off-the-shelf tools fragment this work. Snyk for CVEs, SonarQube for quality, Depfu for dependencies, manual reading for architecture and documentation. Five tools, five accounts, five tabs. The signal is buried in tooling overhead.

Repolens collapses this into one workflow. Paste a GitHub URL. Five LLM agents inspect the repo in parallel across documentation, architecture, maintenance, testing, and security. Result: a structured report in 30 seconds with evidence-cited findings and recommendations.

Five agents, one verdict.

The audit dimensions weren't a marketing decision. Documentation, architecture, maintenance, testing, and security cover what a senior engineer would actually inspect during code review: can I read it, is it structured, is it maintained, is it tested, is it safe.

Each dimension is an independent LangGraph node returning a Pydantic schema: score, severity, summary, findings, recommendations. Nodes run in parallel via LangGraph fan-out, then aggregate into a weighted overall verdict. Each agent uses with_structured_output so the LLM output is typed end-to-end, not parsed from prose.

The security agent calls out to a custom MCP server. Two tools exposed via JSON-RPC over stdio: lookup_cves(dep) queries the CVE database, lookup_package(dep)queries PyPI/npm registry. The MCP pattern matters here because it demonstrates Anthropic's late-2024 protocol in production code, not as a demo.

Making agentic visible.

V1 shipped on Day 8. It worked. Users got their audit in 30 seconds, complete report at the end.

Something felt off in my own use. I opened the site, pasted a URL, clicked run. Blank screen for 30 seconds. Then everything appeared at once.

The whole product positioning was “agentic” — five agents working in parallel. None of that was visible. Users couldn't see the parallelism that was the differentiating insight. The UX was indistinguishable from a slow API call.

Day 10 I refactored the orchestration: LangGraph .invoke() became .astream(), FastAPI returned StreamingResponse with proper SSE format (text/event-stream, Cache-Control: no-cache, X-Accel-Buffering: no for proxy resistance), frontend replaced fetch with EventSource. As each agent completes, the corresponding dimension row populates with score and severity color.

One trap caught during design review: EventSourceauto-reconnects on disconnect by default. On a transient network blip, the frontend would silently re-trigger a full 30-second audit on the backend. I disabled auto-retry and exposed a “Connection lost” state instead.

Same product, completely different feel. The kind of UX gap that doesn't surface in MVP testing — and is easy to ignore post-launch — except it's the whole reason “agentic” sells.

Docker shaped two architectural decisions worth flagging. First, the MCP server runs as a subprocess inside the backend container, isolated but co-located — the command=sys.executable portability fix surfaced because Docker's python3symlink behaviour differs from macOS's. Second, the multi-stage Dockerfile keeps the production image lean (Python slim base, no build tools in final layer) and makes Railway deploys reproducible. The same image runs locally, in CI, and in production; the same image will be the basis for V3's self-hosted Docker Compose stack for enterprise customers who need on-prem deployment.

Three channels, one product.

Day 13 I sketched a “built-in terminal” feature. Users could fix flagged issues right inside Repolens. WebContainer as runtime, mockups looked impressive.

By Day 14 morning I'd cut it. The realization was uncomfortable but obvious: users already have Cursor, Claude Code, and Codex. Building a worse-version-of-their-IDE inside Repolens repeats the wheel. The right move was the opposite — make Repolens callable FROM their IDE.

I shipped Repolens as a Claude Skill instead. skills/repolens/SKILL.md is just markdown with YAML frontmatter — Anthropic's Skill spec. A user installs it once, then typing audit github.com/owner/repo inside Cursor triggers Claude to call Repolens API, parse the result, and present findings inline.

Three channels emerged: web UI for demo and discovery, REST API for programmatic users, Claude Skill for daily-driver inside IDEs. Same product, three points of contact. The Skill is the most novel: in the AI-tooling era, distribution-as-instruction is a real shipping artifact. Code isn't the only deliverable; instructions to other AIs are.

What it actually catches.

I audited Repolens with Repolens.

V1 score: 67/100. Documentation: missing CONTRIBUTING.md, no Quick Start guide. Testing: 7.4% test ratio (2 test files for 30 source files), no CI configured. Security: 10 of 11 dependencies unpinned. Architecture and maintenance scored well; the gaps were exactly what I'd skipped in the build sprint.

I fixed everything it flagged. Pinned all dependencies to exact versions in requirements.txt. Added GitHub Actions CI with parallel backend imports + frontend lint/typecheck/build jobs. Wrote LICENSE, CONTRIBUTING.md, expanded README with Quick Start. Re-audited: 80+.

The dogfooding loop closed. The tool worked on the tool's own repo. The findings were specific, actionable, and correct — not vague platitudes like “improve documentation” but cited gaps like “no CONTRIBUTING.md, no Quick Start guide, README lacks installation instructions for non-developers.”

What I optimized for, what I traded.

What this actually solves.

Three workflows, today, that Repolens compresses from hours to under a minute:

The common thread: structured assessment of an entire codebase, in seconds. Not a chatbot, not a code search, not a CI step. A compressed senior-engineer review surfaced in a single screen.

V3: what comes next.