do-work

---
name: do-work
description: "Execute a unit of work end-to-end: understand, implement, validate with typecheck and build, then commit. Use when the user wants to do work, build a feature, fix a bug, or implement an issue or phase from a plan. Do NOT use for design-system skill extraction — that flow has its own meta-skill (extract-ds-skill)."
---

# Do Work

Execute a complete unit of work: understand it, build it, validate it, commit it.

## Workflow

### 1. Understand the task

Read any referenced plan, PRD, or GitHub issue body in full. Explore the
codebase to understand the relevant files, patterns, and conventions.

If the task touches a design system surfaced under `.claude/skills/ds/`,
that skill's `SKILL.md` is the source of truth for component selection,
token usage, and wiring rules — read it before writing code.

If the task is ambiguous, ask the user to clarify scope before
proceeding. Do not guess at scope.

### 2. Plan the implementation (optional)

Skip when the task is already fully specified end-to-end (e.g., a
locked-down issue body). Plan when scope is open, when you have
multiple viable approaches, or when the task spans more than a couple
of files.

### 3. Implement

This is a frontend-only workshop — implement directly. No TDD
scaffolding.

Edit code directly. Do not delegate via subagents unless the task
genuinely splits into independent parallel pieces.

### 4. Validate

Run:

```
pnpm verify
```

This runs `pnpm typecheck && pnpm build`. Fix any failures and re-run
until both pass cleanly.

Husky's pre-commit hook also runs `pnpm typecheck` as a backstop — but
the build check lives here. Do not rely on the hook to catch build
failures, and do not commit without `pnpm verify` passing.

If a pre-existing failure outside the scope of this task blocks you,
make the minimal fix to unblock and call it out explicitly in the
commit message under a "Pre-existing fix" section. Never bypass the
hook with `--no-verify`.

### 5. Commit

Once `pnpm verify` passes, commit the work in ONE commit. Use the
project's commit message style — read `git log --oneline -n 10` if
unsure.

If the task originated from a GitHub issue, close the issue with a
one-line outcome:

```
gh issue close <N> --comment "<one-line outcome of what shipped>"
```

If the task only partially resolves the issue, comment on it instead
of closing:

```
gh issue comment <N> --body "<what was done, what remains>"
```

**Override:** if the prompt or issue body explicitly says the issue
is a shared spec (workshop, template, recurring fixture), do NOT
close or comment — stop after the commit. The issue stays open for
the next runner.