# Do Work > 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. - Skill: `code-shock/do-work` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add code-shock/do-work` - Raw SKILL.md: https://api.skillmd.com/api/skills/code-shock/do-work/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: Code-Shock (https://skillmd.com/u/code-shock) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/code-shock/do-work --- # 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:** 1. **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. 2. **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.