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 | 4.3.0 |
| Marketplace | magus |
| Commands | 14 |
| Subagents | 13 |
| Skills | 43 |
| 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:test-architect | Writes black box tests from the requirements, never from the code |
dev:researcher | Multi-round web research, and rates the sources it used |
dev:synthesizer | Merges findings from several sources into one answer |
dev:docs | Writes, checks and fixes documentation |
dev:frontend | Builds components against your design system |
dev:devops | Infrastructure and deployment |
dev:spec-writer and dev:scribe | Turn an interview into a spec |
MCP servers
dev ships no MCP server. It declares three 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 |
multimodel | The voting and quality-gate skills those gates run |
Install dev with claudeup and all three come with it. 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
All 49 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:phase-enforcement | /dev:dev — stops a phase being skipped quietly |
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 |
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
claudeup
Find dev on the Plugins tab and turn it on. claudeup 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
claudeup 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 designing endpoints or an API contract —
api-design - Use when implementing authentication (JWT, sessions, OAuth), authorization (RBAC, ABAC), password hashing, MFA, or security best practices for backend services —
auth-patterns - Use when planning an approach or asked to brainstorm —
brainstorming - Use when verifying UI, chasing browser bugs, or console errors —
browser-debugging - Use when dev:frontend or dev:browser-debugging needs navigation, clicking, or web scraping —
browser-use-integration
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: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: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: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 changing anything. |
dev:docs | Writes, analyses, and fixes documentation. Pass mode=write|analyze|fix. Use for READMEs, API docs, tutorials, changelogs, or a documentation quality audit. |
dev:frontend | Builds and revises React components against the project's design system, with optional vision review of screenshots. |
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 — returning severity-calibrated findings and a PASS/CONDITIONAL/FAIL verdict. |
dev:scribe | Appends Q&A to an interview log, updates checkpoints and maintains session state — a small, fast file writer. Use when recording an interview turn, not for analysis or synthesis. |
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 | Identifies a project's languages, frameworks, package managers and test runners, and reports which installed skills apply to it. |
dev:synthesizer | Consolidates findings from several independent sources into one report, marking where they agree and where they conflict. |
dev:test-architect | Writes tests from the requirements alone, never reading the implementation, so the tests check behaviour rather than restate the code. |
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 |
| ! | Nothing can reach it — a packaging bug |
Why a skill lands in one row or another
| Skill | What it covers | |
|---|---|---|
| ● | 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: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:auth-patterns | Use when implementing authentication (JWT, sessions, OAuth), authorization (RBAC, ABAC), password hashing, MFA, or security best practices for backend services. |
| ○ | dev:browser-use-integration | Detects the browser-use@magus plugin and runs headless browser automation for frontend workflows. Use when dev:frontend or dev:browser-debugging needs navigation, clicking, or web scraping. |
| ○ | dev:bunjs | Provides Bun.js/Hono patterns — HTTP endpoints, Prisma/SQLite, Zod validation, Bun test. Use when building a Bun.js service or wiring Hono routes with Prisma. |
| ○ | dev:bunjs-apidog | Use when creating OpenAPI specs for Bun.js APIs, integrating with Apidog, documenting endpoints with schemas, or automating API specification imports via Apidog REST API. |
| ○ | dev:bunjs-architecture | Provides Bun.js clean architecture patterns — routes/controllers/services/repositories, camelCase conventions, Prisma schemas. |
| ○ | dev:css-modules | Provides CSS Modules patterns with Lightning CSS, PostCSS, *.module.css, TypeScript, and Vite. Use when scoping component styles, building complex animations, or migrating legacy CSS. |
| ○ | dev:database-patterns | Use when designing database schemas, implementing repository patterns, writing optimized queries, managing migrations, or working with indexes and transactions for SQL/NoSQL databases. |
| ○ | dev:designer-integration | Detects the designer@magus plugin and delegates pixel-level design validation. Use when dev:frontend or dev:browser-debugging needs design comparison or AI semantic UI analysis. |
| ○ | dev:dingo | Use when working with Dingo meta-language for Go, implementing optionals/results, using generics shortcuts, or transpiling .dingo files to .go while maintaining Go compatibility. |
| ○ | dev:error-handling | Use when implementing custom error classes, error middleware, structured logging, retry logic, or graceful shutdown patterns in backend applications. |
| ○ | dev:golang | Use when building Go backend services, implementing goroutines/channels, handling errors idiomatically, writing tests with testify, or following Go best practices for APIs/CLI tools. |
| ○ | dev:mcp-standards | MCP (Model Context Protocol) server patterns for Claude Code plugins. Use when implementing an MCP server, designing tool interfaces, configuring transports, or naming MCP tools. |
| ○ | dev:optimize | On-demand performance and optimization analysis. Use when identifying bottlenecks, improving build times, reducing bundle size, or optimizing code performance. |
| ○ | dev:plugin-sdk-patterns | Patterns and templates for building Claude Code plugins. Use for plugin development — creating a plugin, skill and agent templates, plugin architecture, or standardizing structure. |
| ○ | dev:python | Use when building FastAPI applications, implementing async endpoints, setting up Pydantic schemas, working with SQLAlchemy, or writing pytest tests for Python backend services. |
| ○ | dev:rust | Use when building Axum applications, implementing type-safe handlers, working with SQLx, setting up error handling with thiserror, or writing Rust backend services. |
| ○ | dev:security-audit | Security and code-quality audit — vulnerability scanning, OWASP categories, secret detection, dependency checks, compliance. Use to check for security issues or scan before a release. |
| ○ | dev:state-management | Use when choosing state management solutions, implementing global stores (Zustand, Pinia), managing server state (TanStack Query), or handling URL state in frontend applications across React… |
| ○ | dev:tanstack-router | Provides TanStack Router patterns — file-based routes, typed params/search, layouts, loaders. Use when setting up routes, implementing navigation, or configuring route loaders. |
| ○ | dev:testing-frontend | Use when writing component tests, testing user interactions, mocking APIs, or setting up Vitest/React Testing Library/Vue Test Utils for frontend applications. |
| ○ | dev:vue-typescript | Provides Vue 3 + TypeScript patterns — Composition API, script setup, Pinia, Vue Router, composables. Use when building Vue apps or wiring reactive state. |
| ▸ | dev:api-design | Covers REST and GraphQL design — pagination, filtering, versioning, auth, rate limiting, OpenAPI. Use when designing endpoints or an API contract. |
| ▸ | dev:brainstorming | Explores solution approaches in parallel across models, scores confidence, validates the chosen plan. Use when planning an approach or asked to brainstorm. |
| ▸ | dev:browser-debugging | Tests UI in a real browser via Chrome MCP — visual fidelity, console, network. Use when verifying UI, chasing browser bugs, or console errors. |
| ▸ | dev:bunjs-production | Provides Bun.js production patterns — Docker, AWS ECS/Fargate, Redis caching, security hardening, CI/CD. Use when deploying or operationalizing a Bun.js service. |
| ▸ | 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 by five anti-generic rules — asymmetry, texture, typography, motion, colour. Use when applying design-review fixes, or UI looks AI-generated. |
| ▸ | dev:react-typescript | React 19 + TypeScript patterns — components, hooks, TanStack Query, Zod forms, error boundaries. Use when building React apps or wiring state. |
| ▸ | dev:shadcn-ui | shadcn/ui patterns — CLI install, CSS-variable theming, dark mode, React Hook Form + Zod. Use when adding UI components or wiring shadcn forms. |
| ▸ | dev:tailwindcss | TailwindCSS v4 patterns — CSS-first @theme, design tokens, container queries, dark mode. Use when configuring Tailwind or defining tokens. |
| ▸ | dev:task-management | Manages Claude Code Tasks across multi-phase workflows — phase tracking, stale cleanup, optional GTD persistence. Use when orchestrating phased work. |
| ! | dev:phase-enforcement | Evidence-based phase completion for /dev:dev — artifacts, validation criteria, outer loops. Use when orchestrating phased feature work with gates. |
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.