unslop

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

• Claude Code
• superpowers plugin

/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.