| name | dev |
| description | General-purpose development workflow for ad-hoc tasks outside of plans. Routes to the right domain skills (postgres-expert, server-action-builder, react-form-builder, service-builder, playwright-e2e), enforces task tracking, and follows a reference-grounded build-test-verify loop. Use when asked to 'build this', 'add this feature', 'fix this bug', 'create this component', 'wire up this form', or any implementation task not tied to a plan. Do NOT use for plan-based work (use /implement), creating plans (use /create-plan), or reviews (use /code-review, /review-plan). |
| argument-hint | [task description] |
| context | fork |
| agent | general-purpose |
| model | sonnet |
| allowed-tools | Read Write Edit Grep Glob Bash Skill Task TaskCreate TaskUpdate TaskList TaskGet |
| metadata | {"version":"1.0.0","category":"workflow-automation","tags":["implementation","development","skill-routing","ad-hoc"]} |
Dev
YOUR TASK: $ARGUMENTS
Do NOT ask the user to re-describe the task. Parse the arguments above and start working.
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:
