| name | do-work |
| description | Execute one complete unit of work end-to-end through tight feedback loops — understand it, plan it, build it, validate it, commit it — never advancing a phase until its feedback signal is green. Manual and global: runs only when the user invokes /do-work or another skill explicitly hands it a scoped unit of work. Use to "do the work", "execute this task/plan/issue", "build and validate and commit", or as the execution engine other planning skills delegate to.
|
| disable-model-invocation | true |
| allowed-tools | Bash Read Write Edit Grep Glob Task TodoWrite AskUserQuestion |
Do Work
Execute a complete unit of work: plan it, build it, validate it, commit it —
driven by feedback loops. Each phase produces output that you check against a
real signal (the user, the type checker, the tests, the build, your own review),
and you loop until that signal is green before moving on. Work never advances
on a red signal.
Manual and global. It runs only when:
- the user invokes
/do-work [task, issue #, or plan reference], or
- another skill explicitly hands off a scoped unit of work to it (e.g.
/prd-to-plan or /grind says "now run /do-work on slice 1").
It is the execution engine — the counterpart to the planning skills. Planning
skills decide what to build; do-work builds it, proves it works, and commits.
The core idea — feedback loops
A unit of work is the smallest slice that can be planned, built, validated,
and committed as one coherent change. You drive it through a chain of loops. Each
loop acts, reads a feedback signal, and repeats until that signal is green
before the next loop begins:
| Loop | Action | Feedback signal | Advance when |
|---|
| Understand | read the task, explore the code | your restatement matches the user's intent | scope is unambiguous |
| Plan (optional) | break the unit into steps | the plan covers the whole unit, no gaps | steps are concrete |
| Implement | write the smallest increment | it compiles / runs locally | increment is in place |
| Validate | run typecheck → lint → tests → build | all green | zero red signals |
| Self-review | read your own diff | it does what the task asked, nothing extra | you'd approve this PR |
| Commit | stage + commit (+ PR if asked) | commit succeeds, hooks pass | change is captured |
Two rules make the loops work:
- Cheapest signal first. Inside the Validate loop, run the fastest check that
can fail first (typecheck/lint, ~seconds) before the slow ones (full test
suite, build, runtime). A fast red signal saves a slow one.
- Never advance on red. A failing signal feeds straight back into the next
Implement iteration — fix the cause, re-run the same check, and only move
outward once it's green. Don't accumulate red signals to fix "later."
If a loop won't converge after a few honest iterations (test keeps failing for a
new reason each time, scope keeps growing), stop and surface it rather than
thrashing — report what's green, what's red, and what you think is wrong.
Workflow
1. Understand the task
Read any referenced plan, PRD, or issue. Explore the codebase to understand the
relevant files, patterns, and conventions — match what's there, don't invent a
new style. Feedback loop: restate the unit of work in one or two sentences. If
the task is ambiguous or larger than one coherent slice, ask the user to clarify
or split scope before proceeding. Don't start building on a guess.
2. Plan the implementation (optional)
If the task has not already been planned, create a short plan for it — the ordered
steps to take it from here to committed. Use TodoWrite to track them so progress
is visible. If a plan already exists (a PRD, a /prd-to-plan output, an issue
with a checklist), use it; don't re-plan.
3. Implement
Work through the plan one small increment at a time. After each increment,
keep it in a runnable state — this is what makes the Validate loop fast and the
failures legible. Don't write the whole feature, then discover at the end that
none of it compiles.
4. Validate — the central loop
Run the project's real signals, cheapest first, and loop until all green:
typecheck / lint → unit tests → build → run the actual behavior
- Use the project's own commands (read
package.json scripts / Makefile /
CI config — don't assume). Examples: npm run lint, npm run typecheck,
npm test, npm run build.
- On any red: stop, read the error, fix the cause, re-run that check.
Repeat until green, then move to the next signal.
- For behavior changes, prove it actually works — run the thing, hit the
endpoint, exercise the path. Tests passing is necessary, not always sufficient.
- If there's a
/verify, /run, or /tdd skill in scope, use it here.
Do not proceed to commit while any signal is red.
5. Self-review
Read your own diff end to end as if reviewing someone else's PR:
- Does it do exactly what the task asked — no more (no scope creep), no less?
- Any debug logging, commented-out code, or stray files left behind?
- Does it match the surrounding conventions?
If review surfaces a problem, loop back to Implement → Validate. Only continue
when you'd approve this change.
6. Commit
Branch first if on the default branch (main/master). Stage and commit using
the project's convention (use /commit if available). Open a PR only if the
user or the delegating skill asked for one. Let the pre-commit hooks run — if
they fail, that's another feedback signal: fix and re-commit.
Operating rules
- One unit at a time. If the task is really several units, do the first one
fully (through commit) before the next, or ask the user how to split it.
- Use the project's signals, not generic ones. Discover the real lint / test /
build / typecheck commands from the repo before running anything.
- Don't fake green. Never delete a failing test, loosen an assertion, or
--no-verify past a hook to make a signal pass. A green you engineered is a red
you hid.
- Don't commit or push unless asked (beyond the working commit that captures
the unit). PRs, force-pushes, deploys → only on explicit request.
- Surface blockers fast. A loop that won't converge is information — report it
instead of silently thrashing.
Done when
The unit of work is understood, built, every validation signal is green, the
diff has been self-reviewed, and the change is committed — with nothing faked to
get there and nothing pushed/deployed that the user didn't ask for.
