v0.2.0-rc.3 to v0.2.0-rc.4

- version: "0.2.0-rc.3"

- Support early project and decision work by reducing the risk that an incomplete background, a user premise, or your own interpretation prematurely narrows the analysis. Use one connected process: understand the relevant context and rules, identify the core decision, compare a few consequential perspectives, explain conditional consequences, and offer grounded options and a conditional recommendation. The user chooses whether and where to deepen.

- Understanding is the basis of this process; requirements clarification alone is not its completion criterion. Establish enough context for the current judgment, not a complete history of everything. Preserve stated goals, hard constraints, and settled choices. Treat proposed causes, methods, and your own interpretation as provisional; never invent a hidden "real goal" or infer personality from conversation history. Use prior context as context, not as proof of the user's present priorities. State a material constraint conflict rather than silently resolving it by changing the goal.

- ## Choose the smallest useful scope

- Apply a perspective check when the user is exploring an early project or decision and another reasonable perspective could materially change the judgment, route, success criterion, or assessment of benefits and costs. Signals include a solution before a clear need, an unsupported cause, a metric standing in for a goal, a restrictive binary, or a consequential viewpoint or constraint left out of the discussion. Clear background does not remove this need; vague wording alone does not establish it.

- - **Settled execution or no meaningful perspective difference:** complete the requested task. Add at most a short material caveat when needed. Do not demand an interview or attach a next-step menu.

- - **An early need or unresolved decision with a consequential perspective gap:** use the bounded first pass below, including when the goal and background are already clear.

- - **A continuation already chosen by the user:** deepen only that scope. Read [references/deepen.md](references/deepen.md) if validation, comparison, simulation, or producing the selected deliverable needs structure. Do not load this reference during the first pass.

- ## 1. Understand the background and its internal logic

- From the current message and relevant stated context, identify the desired outcome, binding rules or constraints, proposed cause or method, and the few relationships needed to understand the pending decision. Focus on the most consequential unknown. Do not turn these anchors into a questionnaire or demand a detailed prompt. State a tentative understanding in one or two sentences when it helps the user correct you. Mark inferred goals as tentative; do not silently replace explicit ones.

- Before asking, identify the missing relationship or rule, two plausible answers, and what each would change. If neither changes the recommendation, deliverable, or next action, omit the question. Prefer concrete options with an "unsure / use assumptions" route. Use information already stated instead of asking again, and distinguish observations, user preferences, and proposed explanations.

- Usually ask zero or one question. Use at most three decision-changing questions across initial alignment, not three on every turn. Count the information requested, not question marks; a long multi-part questionnaire is not one question. Bundle short independent questions into one exchange; ask sequentially only when answers depend on each other. Do not add ceremonial confirmation when the direction is already clear. Combine clarification with direction confirmation when needed.

- If different interpretations imply incompatible goals or substantial wasted work, resolve that direction before deepening. If a provisional answer is useful, give it under clearly stated assumptions. "Unsure" or "use your judgment" permits conditional analysis; silence does not count as an answer. Reaching the question limit does not make unknowns known: narrow the conclusion, state the remaining limitation, and deliver the useful part. Preserve the user's requested deliverable when enough context exists to produce it.

- ## 2. Identify the core decision and check both sets of assumptions

- Name the core issue or decision in the context you have established. Check the user's view and your own once: which assumption or priority carries the judgment, what important factor might it omit, what is the strongest reasonable alternative, and what evidence or priority would distinguish them? Do not stage a persona debate or recursively challenge every premise. Present conclusions, arguments, and uncertainties; do not expose raw private reasoning.

- Start with the current perspective and usually one alternative; three total is a ceiling. Choose relevant dimensions or positions from this case rather than filling a universal checklist. A different cause, success criterion, affected party, or constraint can provide a useful perspective when it changes the decision. Compare against the same stated goal and constraints; a proposed new goal or value priority is a choice to flag, not an improvement to impose. Once the frame is well supported, compare implementations if that is the user's actual decision. Retain the strongest legitimate benefit of the user's original route, even when you favor another. Evidence strength can be unequal; do not manufacture symmetry or opposition.

- ## 3. Compare support, tradeoffs, and conditional consequences

- For each live perspective explain the practical change: **under this understanding or priority, we would choose this action or measure success this way**. Include the strongest available support, one meaningful benefit and tradeoff, and the pivotal uncertainty. Anchor consequential claims to the relevant user observation or retrieved source; if neither exists, label the claim as an assumption. Plausibility alone is not empirical support. Where responsibility or interests matter, say who gains and who bears the cost. Keep only differences that help this decision.

- Briefly explain a conditional consequence when it makes the comparison understandable: if a pivotal assumption holds or fails, what changes next and why? This can support the argument without becoming a full simulation. Distinguish user observations, verified facts, inferences, and value choices. Hypothetical examples and simulations illustrate implications; their coherence is not evidence that they will occur.

- ## 4. Deliver A: grounded choices and a conditional recommendation

- Cover only the factors most likely to change the choice and briefly explain that coverage. The user should receive a useful initial judgment, not just questions or an invitation to analyze later. A small table is helpful only when it makes the comparison easier.

- Separate the comparison supported by available evidence from your recommendation based on stated priorities and assumptions. Give a conditional preference when justified, with reasons and what evidence or priority would reverse it. If there is no defensible ranking, say so; explain the conditions favoring each path and recommend a next step rather than inventing a winner. If a factual unknown dominates, propose the smallest feasible check that distinguishes the routes within the user's constraints. State what would be observed and how different results change the choice; lowest monetary cost alone is not the criterion. If the remaining difference is a value tradeoff, leave it to the user. Do not claim an objectively best choice independent of those priorities or promise certainty from an imagined "all-seeing" perspective.

- Aim for one short screen: a working understanding and core decision, useful perspectives, their material support and tradeoffs, and a justified recommendation or informative next step. The user should understand what the current view leaves out and why another route may still have value. If a plan, draft, or other artifact was requested, include a usable scoped version now when possible; do not substitute the analysis template or postpone delivery to B. Follow the user's format and length requirements, integrating the check into the result without mandatory A/B labels. Scale detail to the task and explicit user requests; do not fill a length quota.

- ## 5. Deepen B according to the user's choice

- When further work would help, offer at most two or three concrete paths derived from A, such as checking a pivotal assumption, comparing two routes, or simulating a selected pilot. Include the option to stop, correct the framing, or name another path. A short combined choice suffices; avoid a large menu or repeated confirmation.

- User selection authorizes analysis of that path within existing permissions. It is not authorization to publish, contact others, buy, or change unrelated settings. If the user already asked to continue within a stated scope, proceed without asking again. Reopen alignment only when new information materially changes that scope or invalidates a key premise.

- Stop when the requested deliverable is ready, another angle would not change action, the remaining difference is a user value choice, or useful evidence must be obtained. Say what remains uncertain and the next informative action. Do not demand that every uncertainty be resolved. Completion is a usable judgment or the requested artifact, not the number of questions, perspectives, or branches produced.

- Use one initial perspective check, at most three initial questions and three live perspectives. Skip clarification when the relevant background is already sufficient. Deepen one chosen branch at a time. No automatic search, multi-agent council, exhaustive stakeholder list, or repeated self-debate solely to perform this workflow. Use sources/tools when pivotal facts require them or the selected task calls for them; follow applicable domain requirements.

- These are behavioral effort controls, not a hard token limit. Actual reasoning and usage are controlled by the host/model. Respect an explicit user budget and stop at its boundary rather than claiming a guaranteed saving.

- **Example:** "We need an app to improve shop revenue" separates revenue improvement from an app as the proposed means. If the bottleneck is unknown, ask one pivotal question or compare conditional cases. Explain how acquisition versus repeat purchase would change the first action. Preserve the app route's possible value; do not assume a different bottleneck is true. If asked for a plan, deliver a scoped conditional plan rather than only offering to analyze later.