Planning Interview Procedure

<Skill_Flow>

<Load_Skills>

  Load `planning-interview-knowledge` before starting the interview loop.
  Do not ask planning questions before the planning target and question strategy are clear.

</Load_Skills>

<Analyze_Context>

  Classify the request and identify the concrete planning target.
  Determine which facts are discoverable from the repository and which require a user decision.
  Build or update the current in-chat plan draft as soon as the goal is identifiable.
  Track whether the current state is `needs_input`, `planning`, or `plan_ready`.

</Analyze_Context>

<Select_Case>

  Use `<Initial_Plan_Draft>` when the planning target is identifiable but no usable plan draft exists yet.
  Use `<Question_Refinement_Loop>` when one or more material decisions still block an implementation-ready plan.
  Use `<Final_Review_Gate>` when the plan is implementation-ready and needs final user review.
  Use `<Blocker_Report>` when the planning target cannot be identified or the required next decision cannot be expressed safely.

</Select_Case>

<Execute_Skill>

  <Initial_Plan_Draft>

    Inspect the repository for concrete facts first.
    Create the first in-chat plan draft using the known goal, scope clues, risks, validation hints, and likely deliverables.
    Leave unresolved items in `Open Questions` instead of pretending they are decided.

  </Initial_Plan_Draft>

  <Question_Refinement_Loop>

    Identify the highest-impact unresolved question set.
    Compress it into the next minimal `question` batch.
    Ask only the questions needed to unblock the next material plan improvement.
    Ingest the answer and update `Goal`, `Scope`, `Assumptions`, `Risks`, `Open Questions`, `Execution Plan`, `Validation`, and `Deliverables`.
    Recompute whether the plan state is `needs_input`, `planning`, or `plan_ready`.
    Repeat until the plan is implementation-ready or a real blocker remains.

  </Question_Refinement_Loop>

  <Final_Review_Gate>

    Present the in-chat plan with a short summary.
    Use `question` immediately after the summary.
    Make the final review question a concrete choice, not a permission-seeking prompt.
    Prefer this review shape unless the plan requires small wording adaptation for the active conversation language:
    - header: `Plan Review`
    - question: `The draft plan is implementation-ready. What should I do next?`
    - options, in this order:
      1. `Confirm the plan (Recommended)`
      2. `Revisit scope`
      3. `Revisit steps`
      4. `Revisit risks`

    If the user selects the ready option, keep the plan marked as final in the conversation and stop the planning workflow.
    If the user requests changes, move back to `planning` or `needs_input` as appropriate and continue the loop on the same plan.

  </Final_Review_Gate>

  <Blocker_Report>

    Report the concrete missing target or missing decision.
    Do not invent a plan when the planning target is still undefined.

  </Blocker_Report>

</Execute_Skill>

<Verify_Result>

  Verify that repository-known facts were gathered before asking the user.
  Verify that each `question` batch is minimal and materially relevant.
  Verify that the plan sections are concrete enough for implementation.
  Verify that no blocking open question remains when declaring `plan_ready`.
  Verify that the workflow did not start implementation.

</Verify_Result>

</Skill_Flow>

Start only when the user request can be interpreted as a concrete planning target or can be narrowed into one.
Inspect relevant local evidence before asking user-facing planning questions.
Keep the working artifact in chat instead of persisting it to a plan file.

<Failure_Handling>

If the request is too vague to identify a planning target, ask the smallest target-identification `question` batch instead of inventing a plan.
If repository evidence already answers a candidate question, remove that question and continue planning.
If multiple unrelated unknowns exist, ask only the set that most affects the next meaningful execution step.
If a safe default exists and does not materially change the result, adopt it as an assumption instead of blocking.
If the user chooses to revise scope, steps, or risks after the final review gate, continue updating the same in-chat plan instead of discarding it.
If a real blocker remains that cannot be resolved through repository inspection or `question`, report it clearly and stop.

</Failure_Handling>

<Expected_Outcome>

Carry the interactive planning workflow to an implementation-ready in-chat plan, a final review decision point, or a concrete blocker.
Leave the user with a clear plan structure and explicit next planning action.

</Expected_Outcome>

Do not implement code, edit product files, or run a direct build workflow while this skill is active.
Do not require persisted plan files, executor-only schemas, or delegation-specific agent fields.
Do not ask plain-text permission questions when `question` can express the missing decision.
Do not ask every unresolved question in one batch when only one decision cluster matters next.
Do not stop at `plan_ready` without presenting the final review choice.

```text
Procedure example
├── request: `please add a notification settings screen`
├── repo fact pass: settings routes and existing form patterns
└── missing decision: notification channels and rollout scope

Draft the plan from repository evidence first.
Then ask one focused `question` batch about channels and rollout only.
```

```text
Procedure example
├── current state: `plan_ready`
├── blocking open questions: none
└── next action: final review

Present the compact plan.
Ask the fixed `Plan Review` question.
Continue only if the user selects a revision path.
```

</Planning_Interview_Procedure>