Stats
Actions
Available In
Tags
Clarity Loop
A Claude Code plugin that takes you from a vague idea to working code — through research, reviewed docs, visual design, and tracked implementation. AI does the work. Humans make the calls. Files hold the truth.
/plugin marketplace add dev-eloper1/clarity-loop
/plugin install clarity-loop@clarity-loop
The problem with AI coding
You ask Claude to build something. It writes code. The code looks right. Three days later:
- The PRD says one thing, the Architecture doc says another, the code matches neither
- The auth strategy you decided on day 1 got re-decided on day 4 — differently
- You're debugging stale API calls because the LLM's training data is six months behind your
package.json - Nobody verified the specs against the docs before implementation started
This isn't a code generation problem. It's an input problem. Vague docs, drifting specs, lost decisions, stale library knowledge — the inputs are broken, so the outputs can't be correct.
Clarity Loop fixes the inputs.
How it works
Five stages, chained together with human gates:
Research → Document — Describe what you want to build. The plugin researches the problem, drafts system docs (PRD, Architecture, TDD), and iterates with you until they're solid. Every doc is cross-referenced against every other doc before you move forward.
Build library knowledge — Before any code touches your project, the plugin researches the actual current state of every library in your stack. Correct imports. Breaking changes. Known gotchas. Distilled into context files that load during implementation. No more stale API calls.
Design the UI — Design discovery conversation → token system and component library → screen mockups with visual feedback loops. Works with Pencil MCP for live visual artifacts, or produces structured specs if you don't have it.
Generate specs — Once docs are verified, the plugin generates concrete implementation specs: precise types, enumerated edge cases, explicit acceptance criteria. The bridge between "what to build" and "how to build it."
Implement with tracking — Because the docs are precise and the library knowledge is current, implementation runs near-autonomously. It generates a task queue, processes tasks front-to-back, verifies each against acceptance criteria, handles runtime bugs, and picks up exactly where it left off across sessions.
Stages 1–4 are the investment. Stage 5 is where it pays off.
Under the hood, parallel subagents handle the heavy lifting — reading documents simultaneously, checking consistency across doc pairs, running implementation tasks concurrently. The main context orchestrates; the agents execute.
What it looks like
# Start a new project
/cl-researcher bootstrap
# → Scaffolds docs structure
# → Discovery conversation: what are you building?
# → Initial system docs generated (PRD, Architecture, TDD)
# → "Architecture references 4 libraries. Create context files? [Y/n]"
# Research a feature
/cl-researcher research "user authentication"
# → Multi-turn conversation grounded in your existing docs
# → Research doc with findings and recommendations
# Review and ship
/cl-researcher proposal # Concrete change manifest: what changes, where, why
/cl-reviewer review # Six-dimension review across all docs
/cl-reviewer merge # Protected write to system docs
# Implement
/cl-implementer spec # Waterfall-gated spec generation
/cl-implementer run # Task queue → parallel execution → per-task verification
When implementation reveals something upstream was wrong — a spec gap, a stale library pattern, an incomplete design — the pipeline loops back to fix the source. Not paper over the symptom.
When should you use this?
Clarity Loop is overhead for small projects. It's built for when "describe and ship" starts breaking:
- 5+ interconnected documents that drift from each other without structured review
- Complex tech stacks where the LLM's training data doesn't match your library versions
- Multi-day projects where context compression loses decisions you made yesterday
- Systems where correctness matters — your auth flow can't just look right, it has to be right
If you're prototyping something over a weekend, this is probably too much process. If you're building something you'll maintain, it pays for itself.
