Help us improve
Share bugs, ideas, or general feedback.
Share bugs, ideas, or general feedback.
Share bugs, ideas, or general feedback.
By rlabarca
Enforce rule-proof spec-driven development by creating specs that define constraints, running tests to generate proofs, tracking coverage via sync_status, and detecting drift when code diverges from specs.
npx claudepluginhub rlabarca/purlin --plugin purlinCreate and manage anchor specs — cross-cutting constraints with optional external references
Evaluate proof quality — STRONG/WEAK/HOLLOW assessments
Inject spec rules into context, then implement
Detect spec drift and summarize changes since last verification, cross-referenced with specs
Search specs by name and show coverage
Admin access level
Server config contains admin-level keywords
Uses power tools
Uses Bash, Write, or Edit tools
Share bugs, ideas, or general feedback.
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge.
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge.
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
Skills-first specification-driven development framework with 7 agent skills for planning, implementation, review, and shipping. Natural language activation with intelligent agent orchestration. Includes /plan, /implement, /research commands plus managing-specifications, implementing-features, and reviewing-and-shipping skills.
SPEC-First development workflow with TDD, Ralph Loop, and autonomous agent coordination for Claude Code
Spec-driven development pipeline for Claude Code: interview-to-spec, spec-approach, tdd, verify, diagnose, and a feature orchestrator.
Specification-Driven Development with Process Discipline for Claude Code
Context-Driven Development: draft specs and plans before implementation. Structured workflows for features and fixes.
Spectacular skills/commands library for spec-anchored development and parallel task execution
Share bugs, ideas, or general feedback.
Rule-Proof Spec-Driven Development
Purlin is a Claude Code plugin that adds spec-driven development to your workflow. You use Claude exactly as you normally would — Purlin just gives it a structured way to track what your code should do, prove that it does it, and tell you what's missing.
Prerequisites: git, Python 3.8+, Claude Code
cd my-project
git init # required — Purlin needs git
claude plugin marketplace add git@github.com:rlabarca/purlin.git --scope project
The --scope project flag stores the marketplace in the project so teammates get it automatically when they clone. Omit it for user-level install.
Then start Claude Code and install:
claude
/plugin install purlin@purlin
Reload plugins so skill autocomplete takes effect:
/reload-plugins
Then initialize:
purlin:init
This creates .purlin/, specs/, detects your test framework, scaffolds the proof plugin, and installs git hooks.
You don't need to learn a new workflow. You just use Claude Code as usual. Here's what a typical session looks like:
If you have an existing codebase, generate specs from your code:
purlin:spec-from-code
Day-to-day work — use any combination of these as you go:
purlin:spec auth_login ← define what a feature must do
purlin:build auth_login ← Claude writes code + tests, iterates until rules pass
purlin:verify ← sign off — verification receipts committed
See what needs attention:
purlin:status ← coverage table with → directives telling you what to do next
purlin:drift ← what changed since last verification, who needs to act
You can tell Claude to handle the items that come back from status and drift — they're actionable directives, not just reports.
Check test quality (expensive — don't run every session):
purlin:audit ← evaluates whether your tests actually prove what they claim
Visual dashboard — purlin:status prints a dashboard link at the bottom. Open it in your browser for a visual view of coverage and test quality. You don't need to use it — the CLI output has everything — but it's there if you want it.
If you have a pre-0.9.0 Purlin installation, keep your features/ directory — spec-from-code migrates your old specs to the new format. Remove only the non-spec artifacts:
rm -rf .purlin/ pl-* *.sh
Then initialize and migrate:
purlin:init
purlin:spec-from-code
Your old scenarios and rules are preserved as input for the new-format specs. See the Installation Guide for details.
sync_status reads specs and proof files, diffs them, and tells you exactly what to do next.auth_login: 2/3 rules proved
RULE-1: PASS (PROOF-1 in tests/test_login.py)
RULE-2: PASS (PROOF-2 in tests/test_login.py)
RULE-3: NO PROOF
→ Fix: write a test with @pytest.mark.proof("auth_login", "PROOF-3", "RULE-3")
→ Run: purlin:unit-test
| Skill | Purpose |
|---|---|
purlin:spec | Create/edit specs |
purlin:build | Implement from spec rules |
purlin:verify | Run all tests, issue receipts |
purlin:unit-test | Run tests, emit proof files |
purlin:audit | Evaluate proof quality |
purlin:status | Show coverage + directives |
purlin:drift | Drift detection and change summary |
purlin:init | Initialize project |
purlin:anchor | Sync external constraints |
purlin:find | Search specs |
purlin:rename | Rename feature across artifacts |
purlin:spec-from-code | Generate specs from code |
Skills are optional — you can write specs, code, and tests without invoking any skill. Skills provide scaffolding and workflow automation.
The tools/ directory contains skills for non-engineer stakeholders who interact with Purlin projects through Claude Desktop. These don't require a development environment — just a repo URL.
| Tool | Audience | What it does |
|---|---|---|
tools/QA/purlin-qa-report | QA | Fetches project digest, produces triaged HTML report of failures, drift, test quality, manual tests due, and sign-off readiness |
tools/PM/purlin-anchor-userstories | Product | Creates and maintains user story anchor files that drive spec-driven development |