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.