goal-setting

name

goal-setting

description

Turn vague personal, research, learning, or project intent into honest, stable, detailed, falsifiable, incremental goals. Use when the user wants to define success, choose direction, prioritize open-ended work, avoid scope drift, recover motivation, or clarify what they are actually trying to accomplish. Keywords: goal-setting, goals, define success, north star, scope drift, priorities, tradeoffs, motivation, stuck, falsifiable, incremental, what am I trying to do.

Goal Setting

Help the user turn vague intent into a goal that can guide choices. The goal is not a slogan; it is a control surface for progress, prioritization, tradeoffs, drift detection, and disagreements.

A useful goal is:

• Honest — names what the user actually wants, not what they think they should want.
• Constant — stable long enough to create direction; changes only deliberately.
• Detailed — includes the concrete situation, users/audience, constraints, risks, inputs, and tradeoffs that would affect decisions.
• Falsifiable — everyone involved can tell whether it was met; failure is possible.
• Incremental — has independently valuable subgoals from easy to hard, so partial progress still matters.

Diagnostic Moves

First identify which failure mode is active:

Symptom	Likely goal flaw	Move
Circular work, repeated redesign	Too vague	Ask what specific question/result would make the work done.
Strained justification	Dishonest	Ask what they want even if nobody else valued it.
Weekly re-deciding	Not constant	Set a review horizon where doubts are collected, not acted on daily.
Endless debate	Not falsifiable	Separate disagreement about goals from disagreement about predictions.
All-or-nothing anxiety	Not incremental	Build a ladder of independently useful subgoals.
Exciting side quest	Drift/replacement goal	Compare it to the written goal before expanding scope.
Satisfying busywork	Weak prioritization	Ask how much this action moves the goal versus its cost.

Goal-Shaping Questions

Use only the questions that expose the live ambiguity:

• Honest: If you did not have to justify this to anyone, what would you be trying to learn, make, change, or feel?
• Constant: How long are you willing to pursue this direction before reopening the goal?
• Detailed: What exact scope, audience/users, environment, constraints, failure costs, performance/quality bars, and maintenance burden matter?
• Falsifiable: What would convince you that this succeeded? What would convince you to stop or change direction?
• Incremental: What is the smallest useful version? What ladder of harder subgoals preserves value if the final goal fails?

For exploratory work, define the goal as a question to answer. Then define what would count as an answer, including a useful negative answer.

Outputs

Prefer one concrete artifact per turn:

• a sharpened goal statement
• a falsifiability test
• an incremental ladder of subgoals
• a prioritization/tradeoff filter
• a drift warning
• one question that exposes a dishonest or missing goal

NEVER

• NEVER accept a socially approved goal if the user's energy points elsewhere. Instead: name the suspected should-goal and ask for the private real goal. Why: dishonest goals cause contortions: the user spends effort justifying what they wanted to do anyway.

• NEVER turn goals into permanent commitments. Instead: set a review horizon and define what evidence would justify changing the goal. Why: constancy creates direction, but new information should change goals deliberately rather than by unnoticed drift.

• NEVER accept “future-proof,” “better,” “simple,” or “successful” without concrete cases. Instead: ask for likely scenarios, users, constraints, inputs, and failure conditions. Why: vague goals cannot rank tradeoffs; almost any action can masquerade as progress.

• NEVER let scope expansion happen invisibly. Instead: compare the new work to the written goal and ask whether this is a deliberate goal change. Why: replacement goals are often more fun than the original goal and can consume the project before anyone notices.

• NEVER leave a hard goal as one all-or-nothing bet. Instead: create subgoals that are independently valuable and ordered from easy to hard. Why: if the final goal fails, the user should still have learning, artifacts, or partial value to show for the time.