dev
Universal development assistant. Detects the project stack and routes work to specialist agents for architecture, implementation, debugging, review and research, enforcing design-system guardrails on every UI change.
| Version | 9.1.1 |
| Marketplace | magus |
| Commands | 17 |
| Subagents | 12 |
| Skills | 19 |
| MCP server | no |
| Hooks | yes |
What you actually get
The commands in dev are orchestrators. They don't write code themselves. They work out
your stack, hand each phase to a specialist subagent, and check the result before the next
phase starts.
That's why they take a while. Every phase is real work by a dedicated agent in its own context window. A forty-file trace or a full test run fills that agent's context, not yours.
The 13 subagents
Each one does a single job. The commands pick which to call — you rarely name them yourself.
| Subagent | What it does |
|---|---|
dev:stack-detector | Works out the languages, frameworks and test runners |
dev:architect | System design, and the trade-offs between options |
dev:developer | Writes code, then loops write → test → fix → lint until the checks pass |
dev:debugger | Finds the root cause |
dev:reviewer | Reviews in three passes: security, correctness, maintainability |
dev:qa-engineer | Writes black box tests from the requirements, never from the code |
dev:researcher | Multi-round web research, and rates the sources it used |
dev:aggregator | Merges findings from several sources into one answer |
dev:docs | Writes, checks and fixes documentation |
dev:frontend-developer | Builds components against your design system |
dev:devops | Infrastructure and deployment |
dev:spec-writer | Turn an interview into a spec |
MCP servers
dev ships no MCP server. It declares two plugin dependencies and uses theirs.
| Dependency | What dev gets from it |
|---|---|
claudish | The calls to other models behind every review gate |
mnemex | Semantic and AST-level code search |
Install dev with magus and both come with it.
multimodel is optional: /dev:architect and /dev:audit use it when it
is installed, and suggest installing it when it is not. Without
claudish the review gates can't run. The commands still work — they just lose the outside
opinion.
One more isn't declared. /dev:dev drives a real browser in its last phase through the
chrome-devtools MCP server, and you set that up yourself. If you don't have it, pick
unit-tests-only validation and that phase is skipped.
Skills
The registered ones are listed further down this page. You invoke almost none of them — commands load what they need — so this is just the handful worth recognising when you see one fire:
| Skill | Loaded by |
|---|---|
dev:context-detection | /dev:dev and /dev:investigate — works out what kind of task this is |
dev:systematic-debugging | /dev:fix — how it narrows down where a bug lives |
dev:worktree-lifecycle | /dev:worktree — the create and cleanup procedure |
dev:db-branching | /dev:worktree — Neon, Turso and Supabase branching |
dev:design-system-guardrails | any frontend work — tokens, component library, variants |
Knowledge is not on that list, and that is deliberate
Alongside skills/ the plugin ships a knowledge/ directory: the stack and framework
reference manuals — Python, Rust, React, Vue, Tailwind, shadcn/ui, TanStack Router
and the rest. Bun, Go and Dingo are not among them: their guidance is the
bunjs, go and dingo plugins, which dev uses
when they are installed. They are reference you consult at a decision point, not procedures you
follow, so they are not skills and nothing registers them. An agent is handed the path to
the one or two its task calls for; it never browses the set.
That is why they do not appear in the table below, and why no dev: address reaches one.
Read them by path, under knowledge/, or let a command pick for you.
One of those skills is much bigger than a skill
dev:architecture counts as a single entry in the table below.
Behind it are 40 documents and about 12,600 lines — every Gang of
Four pattern in TypeScript, seven architectural styles, and a set of refactoring techniques.
The skill itself is 140 lines and loads none of them. It is a router: it reads your question, decides whether you are choosing a system shape or one module's class graph, and names the one or two files to open.
That is the difference between a reference you can use and one you scroll. Loading 12,600 lines to answer "should this be a strategy or a switch" would cost more than the answer is worth, and the file that settles it is 142 lines.
Start with selection.md, which argues against patterns: the overuse smells, the threshold
where branching justifies indirection, and where TypeScript already gives you the pattern
for free.
Install
magus
Find dev on the Plugins tab and turn it on. magus registers the magus
marketplace if you do not have it, and installs what the plugin needs to actually run —
binaries, MCP servers, CLI tools.
For a team, press s to save your plugins as a profile and commit it. Everyone else runs
magus install — see Teams and profiles.
Prefer to do it by hand? Installing Magus has the manual path.
How to run these
Step-by-step, one guide per job:
- building a feature
- fixing a bug
- designing before you build
- understanding code
- documentation
- isolated worktrees
When to reach for it
- Use for README, API docs, tutorials, changelogs —
doc - Use when the user asks to roast code, find sins, or shame my code —
code-roast - Use when a worktree changes the schema, or on mention of Neon, Turso, Prisma —
db-branching - Use when applying design-review fixes, or when a UI looks AI-generated —
frontend-implement - Use when writing, reviewing or setting up tests —
testing-strategies - Use for new modules, subsystems, or any change needing 3+ files with test coverage —
developer
Commands
| Command | What it does |
|---|---|
/dev:architect | Architecture design and technical planning — complexity-aware with plan mode reasoning and multi-model escalation |
/dev:audit | Structured quality audit — routes to specialist reviewers for code, UI, docs, security, or plugin quality |
/dev:debug | Structured debugging — routes to quick patch (inline), standard debug (skill), or production-grade fix (/dev:fix) |
/dev:design-system | Validate a project against the design-system guardrails — token-only styling, one component library, variants over call-site restyling. |
/dev:dev | Builds a feature through an 8-phase workflow, delegating each phase to a specialist agent. Depth picks how many phases run, automation how often it stops to ask. |
/dev:doc | Documentation command - generate, analyze, fix, or validate docs. Use for README, API docs, tutorials, changelogs. |
/dev:fix | Fixes a bug test-first — reproduce, localize, plan, patch, validate. Two multimodel gates, one on the root-cause hypothesis before any code and one on the finished patch. |
/dev:help | Show dev plugin help, detected stack, and available commands |
/dev:interview | Comprehensive specification interview with intelligent requirements elicitation |
/dev:investigate | Read-only code investigation — architecture traces, implementation analysis, bug origin tracking with specialist agents |
/dev:learn | Analyze session for learnable patterns, apply pending learnings (--apply), or prune stale preferences (--prune) |
/dev:qa | Writes behaviour tests from a spec and a public contract with a writer that never sees the implementation — an external GPT top-tier model via claudish, or dev:qa-engineer in its own context… |
/dev:release | Releases the current project through a phased pipeline — preflight gates, version+changelog PR, merge, tag, publish, verify against the public registry. |
/dev:research | Multi-source research with convergence-based finalization and parallel exploration |
/dev:setup | Set up project CLAUDE.md with task routing table and agent delegation rules |
/dev:status | Reconstructs where this session stands — the original idea, decisions, plan changes, done-and-verified vs unverified vs not done, blockers, git and PR truth — and whether the worktree can be… |
/dev:worktree | Manage git worktrees - create isolated workspaces, list active worktrees, and clean up. Supports automatic Neon DB branching for schema isolation. |
Subagents
Dispatched with the Agent tool, each in its own context window.
| Agent | What it does |
|---|---|
dev:aggregator | Merges several reviews of one target into the one report a gate reads, tagging each finding with its consensus and computing the verdict from the thresholds it is handed; |
dev:architect | Plans system architecture in any language, weighing trade-offs and naming what each choice costs. |
dev:debugger | Traces an error to its root cause across files, in any language, and reports the evidence for the diagnosis. |
dev:developer | Implements features spanning multiple files, then iterates write-test-fix-lint until every check passes. Use for new modules, subsystems, or any change needing 3+ files with test coverage. |
dev:devops | Handles infrastructure work — CI pipelines, containers, deploys, observability — and reasons through the trade-offs before anything is applied — it produces the commands and IaC, it does not… |
dev:docs | Writes, analyses, and fixes documentation. Pass mode=write|analyze|fix, the exact doc paths to work on and the source paths that ground them, and SESSION_PATH so analyze and fix share one re… |
dev:frontend-developer | Builds and revises React components against the project's design system — library components with Storybook stories, tokens only, screens compose. Use when implementing or reworking UI. |
dev:qa-engineer | Writes behaviour tests from a spec and a public contract without reading the implementation — Go, Bun/TypeScript, UI via Playwright. Use when coverage must check the spec, not the code. |
dev:researcher | Multi-round web research with convergence detection — searches 10+ sources, assesses their quality, and returns a cited report. |
dev:reviewer | Reviews recent changes in three passes — security, correctness, maintainability — plus a design-system pass on UI files, returning severity-calibrated findings and a PASS/CONDITIONAL/FAIL ve… |
dev:spec-writer | Synthesizes a specification from an interview session, reading the log, assets and context to produce spec.md and tasks.md. |
dev:stack-detector | Classifies a repo's stacks and quality commands, resolves what the task is, inventories reachable MCP servers, and writes a per-agent reading list to context.json. |
Skills
| How you get it | |
|---|---|
| ● | Claude can reach for it on its own |
| ○ | You invoke it by name |
| ▸ | A command loads it for you — you never name it |
Why a skill lands in one row or another
| Skill | What it covers | |
|---|---|---|
| ● | dev:aggregate-reviews | Merges independent reviews of one target into one report with a consensus tag per finding and a verdict from supplied thresholds; also synthesises research findings. |
| ● | dev:context-detection | Detects the project stack from its config files, then names the one or two dev skill files to read for this task — it loads none of them. |
| ● | dev:design-system-guardrails — 4 more docs | Enforces single-source-of-truth UI — design tokens for every style value, one component library, variants instead of call-site restyling. |
| ● | dev:documentation-standards | 15 ranked documentation practices, 7 templates and anti-slop writing rules. Use when writing or reviewing a README, API reference, guide or changelog, even if the user only says "document th… |
| ● | dev:systematic-debugging — 5 more docs | Root-cause debugging — reproduce, localize, explain, verify — with depth routing and a technique catalogue for stack traces, wolf fence and data-flow tracing. |
| ● | dev:test-driven-development | RED-GREEN-REFACTOR: write a failing test, watch it fail, make it pass, refactor. Use before writing any production code or bug fix, or on mention of TDD or test-first, even if the user asked… |
| ● | dev:testing-strategies | Testing pyramid, AAA structure, test doubles, fixtures, assertions and coverage targets, in any language. Use when writing, reviewing or setting up tests. |
| ● | dev:ui-playwright | Writes Playwright UI tests — role locators, page objects, fixtures, network stubs, snapshot policy, one test per Storybook story state. |
| ● | dev:universal-patterns | Code organization, error handling, data flow, naming and anti-patterns in any language. Use while writing or reviewing everyday code. |
| ● | dev:verification-before-completion | Requires fresh evidence — command output, a test run, a screenshot — before any completion claim. |
| ● | dev:worktree-lifecycle | Creates, uses and cleans up git worktrees with safety checks. Use before isolated, risky or parallel feature work, or on mention of worktree, experiment or prototype. |
| ○ | dev:architecture — 42 more docs | Router for architecture knowledge — 7 architectural styles (layered, hexagonal, clean, modular monolith, microservices, event-driven, CQRS) and the 22 GoF design patterns. |
| ○ | dev:browser-debugging | Drives a real browser — claude-in-chrome or browser-use — to verify a UI change, read console and network activity, and reproduce browser-only bugs. |
| ○ | dev:code-roast | Roasts code with severity-graded sins, cites file and line, offers redemption. Use when the user asks to roast code, find sins, or shame my code. |
| ○ | dev:db-branching | Branches Neon, Turso, or Supabase per git worktree for isolated schema work. Use when a worktree changes the schema, or on mention of Neon, Turso, Prisma. |
| ○ | dev:frontend-implement | Rewrites generic-looking UI into a deliberate design via theme tokens and library variants, never call-site values. Use when applying design-review fixes, or when a UI looks AI-generated. |
| ○ | dev:plugin-sdk-patterns | Builds Claude Code plugins that load — manifest location, what registers, the frontmatter each component reads, hooks, MCP servers, verification. |
| ○ | dev:team-gate | Runs a multi-model review gate to a verdict: start the claudish team panel with input_file only, poll until settled, read every ballot, apply the minimum ballot count, log every skip. |
| ▸ | dev:brainstorming | Explores solution approaches in parallel across models through claudish, then has an external panel review the chosen plan. |
Hooks
This plugin installs hooks. They run automatically and are the usual first place to look if its behaviour stops firing.
Source
plugins/dev/ on GitHub, including its full README.