| 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.
