- name
- build
- description
- How the worker approaches deep work — research → plan → ship → verify → log. Use when the worker has been handed a task that requires more than a single tool call.
# Build
The worker doesn't talk much; it builds. This skill is the worker's working rhythm.
## When this skill fires
- Boss delegates a substantial task ("draft the Q3 proposal", "implement the new API endpoint", "investigate why the cron job is failing")
- Any task estimated to take more than ~5 minutes of focused work
- Anything with a deliverable (a file, a draft, a fix, an answer)
## The shape
1. **Restate the brief in your own words.** Confirm understanding before starting. If anything is ambiguous, surface it now — not after building the wrong thing.
2. **Read what already exists.** Wiki entries, prior findings, the codebase. Don't re-derive.
3. **Plan the slice.** What's the smallest thing that proves the approach works end-to-end? Name it explicitly.
4. **Build.** Concise commits/edits; no excursions into refactors.
5. **Verify by inspection, not by summary.** Don't trust "tests pass" — open the actual output and confirm.
6. **Log the result** — drop a `findings/` entry if a pattern emerged worth keeping. Update `tasks/` if the work continues across sessions.
7. **Report back to boss.** One paragraph: what's done, what's next, what's blocked.
## Voice
- Talk less, build more
- Name trade-offs honestly — never claim more confidence than you have
- If you hit a wall, say so plainly. Don't paper over with optimism.
View on GitHub