01
Name the outcome
Goal
A durable aim gives the work somewhere useful to go: make the owner dashboard easier to act on.
A private system for follow-through
Important work, kept moving.
NeedThisDone turns a long-range goal into one approved, reviewable next move.
It remembers what matters, asks before it acts, and shows what changed.
- 15–20 min
- owner check-in
- 1 goal
- next useful move
- 1 record
- proof of what changed
Four controls, one handoff
- 02
Decide the boundary
Owner approval
The owner sees the scope, route, cost, and expected result before a meaningful action can run.
- 03
Move one piece
Private execution
The outbound-only Mac sends the frozen task to the right lane: OpenClaw for tools or Codex for code.
- 04
Bring back evidence
Reviewable proof
The result, cost, diff, private asset, blocker, or next decision stays attached to the durable record.
The reason to build it
A conversation starts the work. The system carries it forward.
NeedThisDone is not trying to be a prettier prompt box. It is designed for work that spans days or weeks, continues while the owner is away, and still needs to remain understandable and controllable.
Starting point
A conversation
Useful for thinking through the next prompt. The important context and next action may still need to be reconstructed later.
- The work is centered on the current exchange
- The result may be an answer, draft, or recommendation
- Continuity depends on remembering where the conversation stopped
System outcome
NeedThisDone
Designed for work that continues after the conversation. The goal stays visible while the system moves one approved piece forward.
- The goal and constraints remain durable
- Every meaningful action crosses an approval boundary
- The output includes evidence and the next decision
How the loop works
Keep the mission visible as the next piece moves.
Every run has a beginning, a boundary, and a handoff. That makes long-range work easier to resume and easier to trust.
- 01
Start with the outcome
Name what better looks like
Start with the better state, not a pile of disconnected tasks.
- 02
Shape the work
Turn context into a plan
Hermes turns the goal into a bounded plan with a visible next step.
- 03
Cross the boundary
Approve the move
The owner sees the scope, route, cost, and expected result before anything runs.
- 04
Do one useful piece
Execute privately
The private machine sends the approved task to the right execution lane.
- 05
Make it legible
Review the proof
The result comes back with evidence, blockers, and a clear next decision.
One system, focused responsibilities
Clear boundaries make the system easier to trust.
The goal is not to make every agent do everything. Each layer owns one kind of responsibility, which makes authority easier to understand and the failure boundary easier to contain.
- 01
Mission control
NeedThisDone
Keeps the goal, context, approvals, status, costs, and results together in one durable record.
- 02
Planning layer
Hermes
Interprets the long-range objective and turns it into a focused, reviewable work packet.
- 03
Local gateway
OpenClaw
Runs approved non-code tools and provides the always-on gateway for the private machine.
- 04
Coding lane
Codex
Works inside an isolated repository worktree to inspect, edit, test, and prepare code changes.
- 05
Review boundary
GitHub
Holds the branch, diff, commit, and pull request so changes remain inspectable before merge.
The coding lane
Code can change without losing the boundary.
A coding task is not permission to modify the live product. It is permission to make one bounded change in a designated worktree, run the relevant checks, and return the evidence.
No merge or deployment by default
- 01
Start from the boundary
Base commit
Start from the exact approved repository state.
- 02
Keep the change isolated
Dedicated worktree
Keep the change isolated from other work.
- 03
Inspect, edit, verify
Codex execution
Inspect, edit, run the relevant checks, and explain the result.
- 04
Return the evidence
Reviewable handoff
Return the branch, diff, tests, and blockers before merge.
The intended rhythm
Short check-ins. Clear next moves.
01 · Check in
See the current mission.
Review what moved, what is blocked, and the one decision that would make the next step clear.
02 · Approve
Authorize one useful move.
The owner decides what the system may do, which route it may use, and what result should come back.
03 · Review
Pick up from evidence.
Return to a result, diff, or blocker—not a blank conversation where the entire project has to be explained again.
Where the project stands
Build proof before making promises.
The repository already contains the control-plane foundation. The coding lane is the next proof, so the public story stays honest about what exists and what still needs to be demonstrated.
In the repository
Control-plane foundation
- Authenticated browser control plane
- Supabase-backed plans, approvals, costs, and results
- Signed outbound bridge to the private worker
- Hermes plan, freeze, and approval lifecycle
- Local safety and lifecycle checks around the worker boundary
Next proof
A bounded coding handoff
- A first-class coding task contract
- Dedicated worktree and branch metadata
- Test, diff, commit, and pull-request evidence
- A durable goal → milestone → work-packet model
- A bounded end-to-end coding rehearsal
Take the next real-world step
More useful follow-through starts with one clear outcome.
Share the situation in your own words. We will help clarify the first piece of work and what you can review before deciding.
Share Your Vision