do-work

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