| name | do-work |
| description | Execute a unit of work end-to-end: plan, implement, validate with typecheck and tests, then commit. Use when user wants to do work, build a feature, fix a bug, or implement a phase from a plan. |
| disable-model-invocation | true |
Do Work
Execute a complete unit of work: plan it, build it, validate it, commit it.
Workflow
1. Understand the task
Read any referenced plan or PRD. Explore the codebase to understand the relevant files, patterns, and conventions. If the task is ambiguous, ask the user to clarify scope before proceeding.
Reading a GitHub issue
Use gh api --jq, not gh issue view — long bodies get truncated.
gh api repos/OWNER/REPO/issues/N --jq '.body' > /tmp/issue-N.md
If the text ends in ... (truncated), page it in slices:
gh api repos/OWNER/REPO/issues/N --jq '.body[1200:2400]'
Read linked ## Parent / ## Blocked by issues the same way.
2. Plan the implementation (optional)
If the task has not already been planned, create a plan for it.
3. Implement
Work through the plan step by step. Make sure to follow coding standards
4. Validate
Run the feedback loops and fix any issues. Repeat until both pass cleanly.
pnpm run typecheck
pnpm run test
5. Commit
Once typecheck and tests pass, pause to let the user review, then commit the work.
Never add a Co-Authored-By: Claude line (or any co-authorship line) to commit messages
6. The Issue
If the task is complete, and was coming from a github issue, hand it off for QA:
-
Remove the ready-for-agent label (if present) and add the ready-for-qa label
-
Leave a QA checklist comment so a human (or a later QA pass) can verify the
work before closing. The checklist must be:
- Specific to what this issue changed, not generic boilerplate.
- Written as GitHub task-list items (
- [ ] ...) so they can be ticked off.
- Framed as observable outcomes ("Creating a séance shows the new duration
field"), not implementation notes.
- Include how to exercise each item (route, action, expected result) and any
edge cases or regressions worth spot-checking.
Use this shape:
## QA checklist
How to verify before closing:
- [ ] <observable behavior> — <how to trigger> → <expected result>
- [ ] <edge case to spot-check>
- [ ] No regression in <adjacent area touched>
If the task is NOT complete, keep the ready-for-agent label and leave a
comment on the GitHub issue describing what was done and what remains.