unslop
The spec is the source of truth. Generated code is a disposable artifact.
unslop is a Claude Code plugin for intent-first development -- a workflow where you maintain spec files describing what code should do, and the system maintains the code. Edit the spec, regenerate, run tests. The generated code is updated by an agent on every cycle; the only way to change a managed file's behaviour is to change its spec.
The name started as a joke about rescuing vibe-coded prototypes. It stuck because the workflow works just as well for greenfield projects -- and because "unslop your codebase" is a satisfying thing to say.
Prerequisites
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
Installation
/plugin marketplace add Lewdwig-V/unslop
/plugin install unslop@unslop
Quick Start
Greenfield: write a spec from scratch
/unslop:init
/unslop:elicit src/retry.py # Socratic dialogue to build the spec
/unslop:generate # tests-then-implementation from spec
Takeover: bring existing code under management
/unslop:takeover src/retry.py # single file
/unslop:takeover src/auth/ # entire module
/unslop:takeover src/**/*.py # glob pattern
Reads the code, infers a spec via distill, refines it via elicit, archives the originals, and regenerates fresh code from specs alone. For directories and globs, unslop discovers files, resolves their dependency order, and offers per-file or per-unit spec granularity.
Change: modify a managed file's behaviour
/unslop:change src/retry.py "add circuit breaker with 5-failure threshold"
Records the intent, opens a Socratic dialogue to amend the spec, then regenerates. For quick fixes:
/unslop:change src/retry.py "fix null check on empty response" --tactical
Architecture
unslop is a Claude Code plugin that ships two coordinated pieces:
- unslop/ -- the plugin: markdown commands and skills, agent prompts, hooks
- prunejuice/ -- the TypeScript orchestrator (MCP server): freshness classification, dependency graph, ripple check, sync planning, agent dispatch, convergence loop
The plugin is the user-facing command layer. Prunejuice is the coordination mechanism -- commands invoke prunejuice via MCP tools to avoid reimplementing orchestration logic in markdown prompts.
The Five-Phase Model
unslop decomposes development into five independent phases. Each can be run standalone or composed by orchestrators.
| Phase | Command | What it does |
|---|
| Distill | /unslop:distill | Infer spec from existing code |
| Elicit | /unslop:elicit | Create/amend spec via Socratic dialogue |
| Generate | /unslop:generate | Tests-then-implementation from spec |
| Cover | /unslop:cover | Find and fill gaps in test coverage |
| Weed | /unslop:weed | Detect intent drift between spec and code |
Three orchestrators compose these phases into workflows:
- takeover -- distill, then elicit, then generate. Brings existing code under management.
- change -- elicit, then generate. Records a change and regenerates.
- sync -- generate with dependency resolution. Regenerates one file, a blast radius, or everything stale.
The Core Inversion
In most projects, code is the ground truth and documentation is the afterthought. unslop inverts this: the spec is the durable artifact, and the code is derived from it.
This is enforced structurally, not by convention. The code generator is physically blocked from seeing your conversation history, your change requests, or the original code (except during takeover). It receives only the spec. If the spec is insufficient, the tests fail -- and the failing test tells you exactly what the spec is missing.
The practical consequence: code review happens at the spec level. Diffs are spec diffs. The generated code is an output of the review process, not an input to it.
The Artifacts
src/
retry.py # managed file -- do not edit directly
retry.py.spec.md # per-file spec -- edit this
retry_test.py # human-owned tests -- the acceptance gate
auth/
__init__.py # managed
tokens.py # managed
middleware.py # managed
auth.unit.spec.md # unit spec -- one spec for the whole module
Per-file specs (*.spec.md) manage a single file. Unit specs (*.unit.spec.md) manage a group of tightly coupled files as a single logical unit -- one spec, multiple outputs. Dependencies between specs are declared in frontmatter and resolved transitively.
Specs describe intent, not implementation. If your spec reads like commented-out code, it's over-specified.
