/get-it-done

name: get-it-done
description: Pursue an agreed goal to a working outcome without waiting: decompose it, re-prioritise as evidence arrives, branch, gate, get an independent review (a different model or a fresh reviewer subagent — the writer never approves), merge, prune, and bank the operator's decisions in STATUS.md instead of blocking on them. Trigger on "get it done", "don't wait for me", "proceed autonomously", or when an epic or roadmap objective is handed over. Not a close-out: this work set is expected to grow.

Get it done

**The planning, the talking, the debating are over. The plan is agreed — execute it.** Do not re-open scope, do not re-surface options already ruled on, do not ask for reassurance. The only reason to interrupt is a decision from the short "Theirs, always" list below; everything else is action.

The operator has left. **Finish the phase.** Do not stall on anything you can decide, evidence, or work around — and do not silently decide anything that is genuinely theirs.

The whole skill is one judgement: **what is mine to call, and what is theirs?** Get that wrong in the timid direction and the work sits idle for hours. Get it wrong in the reckless direction and you spend their money, their credibility, or their consent on a call they never made.

The boundary — this pursues a goal, it does not close a queue

The unit here is a **goal**: an epic, a roadmap objective, a phase, a thing that must end up *working*. The work set is derived from that goal and **is expected to grow** — you decompose, you discover, you re-prioritise as evidence arrives, and you update the delivery tracker as you go rather than at the end. Done means the goal is functional, not that a list is empty.

A close-out is the opposite shape: its work set is **frozen** at invocation and never grows, and it ends in a release advisory. If the operator asked you to close out what is in flight, do that job, not this one. Running this skill against a closing set is how a close-out quietly turns into a new sprint.

The contract

1. **Do not wait.** No "shall I proceed?", no "let me know". If you can act, act. 2. **Bank, don't block.** A decision that is genuinely theirs goes into `STATUS.md` with a recommendation — not into a message that stops the work. 3. **Land it.** A phase is not done because the code is written. It is done when it is merged to `main`, the branch and worktree are pruned, and the tracked documents match reality. 4. **Never fabricate authority.** Blanket "go" covers ordinary work. It does not convert into permission for the four things below.

Theirs, always — bank these, never assume them

Even under an explicit "don't wait for me":

• **Money.** Raising a spending limit, a plan, a paid tier, a metered vendor.
• **Consent, credentials, retention, permissions.** Anything a user agreed to,

anything that reads or keeps their data, anything holding a secret.

• **One-way doors.** Tags, releases, published artefacts, external submissions,

force-pushes, deleting a ref whose commits are not reachable from the trunk.

• **Self-approval of a governance record.** An ADR is never accepted by the

agent that wrote it. Draft it, evidence it, and flag it.

Everything else — ordinary code, tests, docs, refactors, issue filing, branch hygiene — is yours. Do it.

When a dependency is missing, route around it and say so

A blocked gate is not a reason to stop; it is a reason to substitute and record the substitution.

| Unavailable | Substitute | Record | |---|---|---| | Hosted CI (quota, outage, no runner) | Run the local equivalent of **each** required check | Name each check and its local equivalent, with exit codes | | Hosted code review (quota) | An independent reviewer: a different model or a fresh reviewer subagent | Which reviewer, what verdict, what it found | | The first reviewer unavailable | The next independent reviewer available | That the first choice failed, and why | | A required check that *cannot execute* | Merge on the local evidence if the repo permits it | **Say "past checks that could not run", never "past checks"** |

The distinction in that last row is the whole point. A check that failed and a check that could not start are different facts, and conflating them is how an unreviewed merge gets laundered into a reviewed one.

**Never route around a guard that exists to stop you.** A denied push, a protected branch, a consent gate — those are the operator's intent expressed in config. Routing around them is permission laundering, not resourcefulness.

The loop

For each unit of work:

1. **Branch.** Never commit to the trunk. 2. **Build**, with the project's own gates run as you go — not saved for the end. 3. **Prove it bites.** Break the source deliberately and confirm the test fails. A green suite you have not seen go red is a hypothesis. 4. **Review independently.** A different model (`scripts/review-gate.sh --pr N`, the Gemini lane) or a fresh reviewer subagent running `pr-reviewer`; `adversarial-gate` for design. **The writer never approves the work.** If the candidate changes after review, the review is void — re-run it. 5. **Merge** with a merge commit. Never squash, never rebase onto the trunk. 6. **Prune** the branch and worktree — but only once `git cherry` confirms the commits are reachable from the trunk. Where integration reworked a patch into a new SHA, deleting the ref loses history. Keep it and say why. 7. **Reconcile.** STATUS, CHANGELOG, ROADMAP, ADRs, issues. Findings that live only in a chat message evaporate; file them.

Parallelism

Use worktrees and subagents where the work is genuinely disjoint. **Two agents editing the same file is not parallelism, it is a merge conflict with extra steps** — and most "parallel" refactors of one subsystem collide. Say so rather than parallelising for appearances.

The handover

`STATUS.md` is what they read when they return, so write it for someone who was