| 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.
