---
name: dev-task
description: Structured dev workflow for any code/build task — pages, scripts, APIs, tools. Use when implementing anything technical: building a new page, writing a script, setting up an integration, refactoring code, or fixing a bug. Prevents context rot, ensures verified delivery. Triggered by: "build", "create", "implement", "fix", "write a script", "make a page", "set up", or any Thibault dev brief. Core pattern: spec → spawn fresh executor → verify actual output → commit. Never claim done without running the verify step.
---

# Dev Task

Spec-driven dev workflow. Keeps orchestrator context lean. Heavy work runs in fresh subagent contexts.

## When to Use

Any task involving writing, editing, or running code. One task or many — the workflow scales.

## Workflow

### 1. SPEC — Before touching any file

Convert the brief into a task spec. See `references/task-spec.md` for format and examples.

One spec per atomic unit of work. If the brief has multiple independent pieces, create one spec per piece. If pieces are dependent, order them sequentially.

Ask yourself:
- What files will this touch?
- What is the single verifiable done state?
- Are there dependencies between tasks?

### 2. PLAN — Map dependencies

Group tasks into waves:
- **Wave 1**: Tasks with no dependencies → run in parallel (spawn separate subagents)
- **Wave 2**: Tasks that depend on Wave 1 → run after Wave 1 completes
- Continue until all tasks are assigned

If a task is a single standalone unit, skip wave planning — just execute it.

### 3. EXECUTE — Fresh context per task

Spawn a subagent for each task in the current wave. Pass the task spec as the brief.

**Critical:** Do not execute heavy implementation work in your own context. Spawn a subagent with:
- The full task spec (XML format)
- The working directory
- Any relevant files to read first
- `DESIGN.md` path if this is a CE UI task: `work/internal-ce/system-export/DESIGN.md`

Wait for all Wave N subagents to complete before starting Wave N+1.

### 4. VERIFY — Check actual output

After execution, verify against the spec's `<done>` criteria. Do not skip this.

For code/scripts: run the thing. Check the output matches expected.
For pages/HTML: open in browser or use Playwright. Check rendering.
For APIs/integrations: make a real call. Check the response.
For file operations: check the files actually exist with correct content.

If verification fails: diagnose the delta, create a fix spec, re-execute.

**Never report done based on "the code looks right." Run it.**

### 5. COMMIT — Atomic commit per task

After each verified task:
```bash
git add <changed files>
git commit -m "<type>(<task-ref>): <what was done>"
```

Types: `feat`, `fix`, `refactor`, `style`, `docs`, `chore`

Example: `feat(page): build CE landing page with DESIGN.md tokens`

---

## Quick Task (single task, no planning needed)

For small, well-scoped tasks that don't need wave planning:

1. Write the spec (see references/task-spec.md)
2. Execute in a fresh subagent
3. Verify
4. Commit

## CE UI Tasks

Any task touching CE pages or components:
- Read `work/internal-ce/system-export/DESIGN.md` before writing any HTML/CSS
- Pass `DESIGN.md` path to the executor subagent's brief
- Add CE compliance check to the `<verify>` step: no dark backgrounds, no shadows, no gradients, no bold (700), only CE color tokens

## Context Budget

If your session is above 100k tokens: **stop, spawn a fresh subagent, and pass only the task spec**. Do not continue coding in a bloated context.

---

Read `references/task-spec.md` for XML spec format and examples.