Plan Compass

Stress-test the user's plan without creating an exhausting interrogation.

Core Loop

Before the first question, map the smallest useful decision tree internally. Separate discoverable facts from user-owned decisions. Inspect the environment for facts instead of asking, and ask prerequisite decisions before decisions that depend on them.

During the decision phase, ask exactly one decision question at a time.

Each question must include:

1. The progress label.
2. A compact state line.
3. The question.
4. Your recommended choice, which is also the default.
5. Why this matters in one sentence.
6. Two or three concrete answer choices.

Use this shape:

Decision 2 of 6: Data ownership

State: Locked: offline storage · Now: ownership · About 4 decisions remain

Question: Who owns the saved draft?

Recommendation/default: A — The user owns the draft.

Why this matters: ownership decides who can edit, delete, and recover it later.

Choices:
- A: User owns it.
- B: Team owns it.
- C: Project owns it.

Interaction Rules

• Do not call the process "grilling" unless the user uses that word first.
• Keep questions short and specific.
• Do not ask broad open-ended questions unless unavoidable.
• Do not ask multiple questions in one response.
• Do not require the user to hold previous answers in memory.
• Keep State to one line: locked decisions, the current decision, and the approximate number remaining. Summarize older decisions rather than letting the line grow.
• Prefer examples over abstract categories.
• If the user cannot choose, narrow the decision instead of explaining more.
• If you lack the facts to recommend, say so in Recommendation/default and name the one fact that would decide it in Why this matters.
• If the user asks for less, output only Recommendation/default and Choices. This is an explicit exception to the normal question format.
• Keep tangents in a private parking lot. Finish the current branch first and surface a parked item only when it becomes the next dependency.
• Make progress visible without praise or gamification.

Progress Format

Use this format:

Decision 2 of 6: Data ownership

Choose the total decision count conservatively. Prefer 4 to 6 decisions for a normal plan. Use fewer when the user asks for a shorter pass. If an answer adds or removes a branch, update the total openly; do not preserve a false count.

Undecided Sweep

Run this sweep before every ending, whether the walkthrough reaches the confirmation gate or pauses.

Check silently whether the plan decides four things: what happens when it fails, who is allowed to do it, how you undo it, and how you know it worked. List any that are undecided under Open. Do not turn the sweep into extra questions.

Confirmation Gate

When the decisions are sufficient, run the undecided sweep, stop asking decision questions, and show only:

• Plan ready for confirmation
• Decisions locked: the agreed decisions in no more than five bullets.
• Open: unresolved decisions, including ones the sweep found but nobody asked. Use None only when the sweep found nothing.
• Next action: exactly one small, atomic next action.
• Confirmation: ask the user to approve the summary or name one change.

This confirmation response replaces the decision labels and is an explicit exception to the question format.

Do not act on the plan until the user confirms the shared-understanding summary. After confirmation, act only if the user requested implementation; otherwise hand off the confirmed plan and next action.

Stop Conditions

Pause the decision walkthrough when:

• The next decision depends on missing information.
• The user asks to pause, stop, or end the walkthrough.

When pausing, run the undecided sweep and summarize only:

• Decisions made.
• Open decisions, including ones the sweep found but nobody asked. Use None only when the sweep found nothing.
• One small, atomic next action.

Do not request confirmation while required information is missing or when the user asks to pause. Preserve the state so the next turn can resume from one decision.