goals-problem-solving

name

goals-problem-solving

description

Solve a problem or define/break down a goal using PACERS (Pause, Assess, Choose, Execute, Review, Systemize) and record the reasoning as a traceable building journey in the active Goals goal. Use inside a Goals project when defining a goal, breaking a phase into sub-problems, hunting assumptions before building, or whenever a problem is recurring, costly, unclear, or likely to create second-order effects.

Goals Problem Solving — PACERS

Ships with the Goals CLI. Works inside a Goals project (a goal worktree with active state created by goals start). It turns the model's reasoning into a plain-English trace the user can read on the dashboard — the building journey.

PACERS is a six-step loop that forces a second look before the first acceptable answer becomes the final answer. Not every problem needs the full loop — use it when a problem is recurring, costly, unclear, or likely to create second-order effects. A one-line typo fix does not need PACERS.

The loop

1. Pause — become aware before acting. Ask one sharper question before the first move: am I solving the problem, or just reducing my own discomfort / accepting my first answer? Watch for the eager state (action feels urgent) and the distracted state (attention too fragmented to hold the whole problem). If you're soothing discomfort, slow down. Record the check as the breakdown's pause_note.

2. Assess — make the problem clear. This is the heart of the journey.

• Rephrase the vague statement into a specific, testable one.
• Ask why until it simplifies (5 Whys) — record the chain in whys.
• Hunt assumptions. Write down what you're assuming. You don't need to eliminate every assumption — you need to know which ones your solution depends on. Record each with:

  goals assess assume "I'm assuming X" --building "the thing I'm building" \
    --toward "the sub-problem it serves" --depends --status holding \
    --phase <PHASE> --college "extra framing for a college reader" \
    --hobbyist "how a tinkerer would poke at it"
  

  Write the bare statement at a high-school reading level — no jargon. It is the always-visible text; --college / --hobbyist only add framing.
• Look at the system for recurring problems: what keeps feeding this? Record as system_view.
• Record the whole breakdown (problem → sub-problems → tasks → open questions):

  goals assess breakdown --file breakdown.json
  

3. Choose — compare solutions before committing. Generate at least a few options (obvious, simplest, systemic, and the no-action option). Make tradeoffs visible: effectiveness, time, effort, risk, reversibility, cost, second-order effects. Prefer a slower reversible action over a fast destructive one. Record the call with goals decision record (or surface it with goals decision brief / goals decision explain when it needs the user).

4. Execute — run the chosen plan, and prove it by execution. A good plan has a first step, a stopping rule, a way to verify progress, and a rollback if risky. Build only the chosen thing. Then prove it ran, don't narrate that it works. First invert (this is where hidden bugs live): deliberately try to break what you built — how could it fail across boundaries and signs, time and locale, empty and huge inputs, concurrency, and its dependencies (storage, network, the clock) failing? The gate only makes you defend the assumptions you name, so for each plausible failure either fix it, write a check that exercises it, or — if it's a premise you were silently relying on — record it as a load-bearing assumption. Then, for each acceptance criterion and each load-bearing assumption, write a runnable check that fails if it's wrong (a check that can't fail proves nothing). Record them in the evidence verifications (each covers a criterion or an assumption id) with goals phase evidence, then goals phase verify — the engine runs your checks and records the real exit codes, so a passing result can't be asserted, only earned. Fix until every automated check passes, then goals phase review and goals phase accept.

5. Review — learn from the result. Did this solve the actual problem? What did you expect vs. what happened? Which step was weak? If an assumption turned out false, flip it:

goals assess assume "..." --id <A-id> --status broken

6. Systemize — prevent repeat problems. Only for recurring or costly problems. Turn the lesson into an environment change (a checklist, a decision rule, a template) via goals loop improve. Don't build a system before you understand the problem.

When NOT to use

Trivial, one-off, reversible work. Clean up the spilled coffee — don't run the loop.

If there is no active Goals goal, this skill does not apply — run it from a goal worktree created by goals start.