| name | dev |
| description | Ad-hoc development workflow for implementing features, fixing bugs, and making code changes outside a formal plan. Use when asked to implement, add, fix, build, or create something in the codebase. Routes to domain skills (postgres-expert, server-action-builder, react-form-builder, service-builder, playwright-e2e), enforces task tracking for context-compact recovery, and follows a reference-grounded build-test-verify loop. Do NOT use for large multi-phase features — use /create-plan + /implement instead. |
| argument-hint | [task description] |
| agent | general-purpose |
| model | sonnet |
| compatibility | Claude Code only. Requires Task, Skill, TaskCreate, TaskUpdate, TaskList, and TaskGet tools. |
| allowed-tools | Read Write Edit Grep Glob Bash Skill Task TaskCreate TaskUpdate TaskList TaskGet |
| metadata | {"version":"1.1.0"} |
Dev
YOUR TASK: $ARGUMENTS
Critical
- Check TaskList FIRST before doing anything else — tasks may already exist from a previous session or compact
- Find a reference implementation before writing code — never guess at patterns
- Invoke the right domain skill for each piece of work — skills embed project-specific conventions
- Run verification (tests, typecheck) before reporting done — unverified code breaks downstream work
- Do NOT create plan files, phase files, or documentation — this skill implements directly
Task Tracking
Tasks survive context compacts — skipping this check causes lost progress and repeated work.
Before starting work, run TaskList to check if tasks already exist from a previous session or before a compact. If tasks exist:
- Read existing tasks with
TaskGet for each task ID
- Find the first task with status
pending or in_progress
- Resume from that task — do NOT recreate the task list
If no tasks exist, create them in Step 2 after scoping the work.
Mark each task in_progress when starting and completed when done.
Workflow
Step 1: Understand the Task
Read any files the user referenced or that are clearly relevant. If the task mentions an existing file, read it. If it mentions a feature area, Glob for related files.
Extract:
- What needs to change — new files, modified files, or both
- What domain(s) are involved — database, server actions, services, UI, forms, tests
- What already exists — don't rebuild what's already there
Step 2: Create Task List
Break the task into concrete sub-tasks. Each task should be a single, completable unit of work.
TaskCreate({ subject: "...", description: "...", activeForm: "..." })
Task descriptions must be self-contained — include file paths, function signatures, and acceptance criteria. If your context gets compacted, the task description is all you'll have.
Order tasks by dependency:
- Schema/database changes first (if any)
- Service layer
- Server actions
