# Plan Interview

> Explicitly selected evidence-grounded interview that captures an approved Intent Pack before architecture planning. Use when the user chooses $plan-interview or a selected parent requires it. A brief or ambiguous request to build something does not select an interview lifecycle.

- Skill: `aelaguiz/plan-interview` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add aelaguiz/plan-interview`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aelaguiz/plan-interview/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: aelaguiz (https://skillmd.com/u/aelaguiz)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/aelaguiz/plan-interview

---


# Plan Interview

Use this workflow only after explicit selection as `$plan-interview` or a
binding task instruction requiring it.

The interview is a loop, not a line. The user's answers are investigation
triggers, not entries to transcribe: the skill goes and figures out what the
words mean in this codebase, writes what it learned into the pack, and comes
back with questions it could not have known to ask before looking.

## When to use

- The user describes an outcome and wants it properly captured before
  planning: "interview me about this", "build the intent pack", "let's spec
  this out", or just "build this" plus a pointer.
- Plan quality has been spotty and the user wants intent, requirements,
  user experience, testing, and execution logistics extracted up front.
- A conductor-sized effort needs an approved scope boundary, journey maps, an
  approved test grid, and a definition of done before any plan is written.

## When not to use

- The diff could be described in one sentence — just do the work.
- The user wants the implementation plan written: `arch-mini-plan` or
  `arch-step` (the pack is their input, not their replacement).
- The user wants an existing plan audited (`plan-audit`), a plan executed
  (`conductor`), or a read-only second opinion (`fresh-consult`).
- The artifact would duplicate a plan that already exists — this skill
  captures intent before planning, it does not re-plan.

## Non-negotiables

- **The interview runs in the foreground conversation.** The user answers
  in this thread, so the interviewer must be this thread: never delegate
  the interview itself to a background agent, subagent, or external
  worker. If this skill finds itself running in a background or child
  context where the user cannot reply directly, stop and return control so
  the main conversation runs it. Children are for education research and
  the explicitly requested proxy interviewee only; they report to the
  parent, and the parent asks the questions.
- **Educate, don't draft.** After the opening ask and at most 1–3 orienting
  questions, education produces facts, reference material, and a blank
  template — zero decisions. Never pre-fill the pack from the opening
  sentence: a drafted pack is a pile of decisions the user never made,
  formatted to be rubber-stamped.
- **Elicit, don't confirm.** Open questions first, framed with evidence and
  the user's own past asks ("typically your requirements here are X — what
  are you thinking?"). Options with a recommendation are the fallback —
  when the user asks, is unsure, or an answer needs sharpening — never the
  lead for intent, requirements, UX, or architecture. Standing doctrine and
  execution policy are one-line confirms.
- **Plain English only.** Never ask about code symbols, file names, or
  internal identifiers, and never invent shorthand of your own: requirements
  are stated in words and referred to by name afterward, never as
  R1/Q3-style codes. Recognition test: could someone who never read this
  code answer the question? If an always-on communication-style skill is
  installed (for example `i-have-adhd`), its rules govern every
  user-facing message.
- **The loop is structural.** "Give me a few minutes to figure out what
  that means" is a first-class move at any point, multiple times per
  interview. Each trip writes findings into the pack and returns with the
  questions those findings raise. Cycles deepen one area, then the walk
  advances.
- **Breadth before depth, always advancing.** Walk the must-always-know
  list breadth-first; roughly two follow-ups per topic in the broad pass;
  checkpoints offer depth ("sign off now, or take a few more minutes on
  these areas?") instead of imposing it. "Good enough" is always accepted
  and produces the pack with assumptions listed and owned. Restate
  progress each turn.
- **Everything approved up front.** Journey maps wherever a journey is
  touched, visual references asked for on any UX work, and the full test
  grid built and approved inside the interview. Nothing in the close says
  "coming later" except items the user explicitly parked.
- **Discovery raises questions, never scope.** An adjacent surface with the
  same problem is a scope question for the user, not included work.
- **The pack is not a plan.** It records intent, requirements, boundaries,
  and proof obligations. Target architecture belongs to the planning skill
  downstream; architecture *requirements* (constraints) belong here.
- Apply `../_shared/agent-orchestration-policy.md` whenever education
  researchers or a proxy interviewee are dispatched, and apply
  `$prompt-authoring` to each populated child brief.
- Read `references/standing-doctrine.md` and bake its core requirements and
  execution defaults into every pack; ask only about deviations.

## First move

1. Read `references/must-know-list.md` — the interview's backbone.
2. Read `references/intent-pack-contract.md` and
   `references/education-contract.md`.
3. Read `references/interview-doctrine.md` before the first question.
4. Read `references/standing-doctrine.md` for what is never re-asked.
5. Judge the size: one-sentence diff → say so and skip the skill;
   small-but-real → quick lane (brief education, one batched round of
   evidence-backed questions, quarter-page pack; the close may merge the
   two gates into one table-plus-dispatch question when the plan-step
   choice was already settled in the batched round); otherwise full lane.
6. Ask the 1–3 orienting questions needed to aim education. No decisions.

## Workflow

1. **Orient.** Restate the ask in plain English; classify nothing yet.
2. **Educate.** Dispatch clean read-only researchers per the shared policy
   and `references/education-contract.md`. Output: research files, a facts
   briefing, and the blank Intent Pack template.
3. **Interview.** Walk the must-always-know list breadth-first under
   `references/interview-doctrine.md`: open questions with informed
   framing, investigate-and-return cycles as answers demand, journey maps
   and the test grid produced and approved in-flow, standing items as
   one-line confirms, answers written into the pack immediately. Open
   every questioning round after the first with the compact running
   decisions table — what's settled so far — so the user follows along by
   table while answering; the gate-1 table is the final version of the
   same table, never a reveal.
4. **Proxy on request.** "Have <model> answer as me" swaps in a clean
   proxy child under the same open-question rules; answers are marked,
   user-visible decisions stay provisional unless delegated, and the user
   gets a skimmable decision summary afterward.
5. **Harden.** Self-review against this skill's own failure modes: any
   pack decision with no answer, approval, or confirmed default behind it;
   any invented shorthand; any un-parked "later"; any answer recorded but
   not understood — plus placeholders, contradictions, vague adjectives,
   requirements with no proof line, must-know items with no line.
6. **Close with two gates.** Gate 1: the decision table — everything
   decided, one clean table, assumptions marked and owned — "is this
   good?" Gate 2: "ready for me to run the plan step?" A bare yes runs
   `$arch-mini-plan` against the pack; a sentence of steering (full
   `$arch-step`, an adversarial plan review with a named model and round
   cap, straight to `$conductor`) runs exactly that. Hand off with the
   reminder that downstream skills must not re-ask what the pack answers.

## Output expectations

- The Intent Pack per `references/intent-pack-contract.md`, signed off after
  gate 1 feedback is folded in.
- A decision log in the pack: every question and answer, proxy answers
  marked, rejected alternatives, flagged derivations.
- The gate-2 handoff executed as steered, with the chosen next command
  named plainly.
- Chat output stays compact: progress lines during the interview, the
  decision table at the close, detail in the pack.

## Reference map

- `references/must-know-list.md` — the 13 items every pack must have a
  line for, with tags and strong/weak bars
- `references/intent-pack-contract.md` — artifact layout, blank template,
  decision log, sign-off rules, acceptance bar
- `references/interview-doctrine.md` — elicitation, framing, the
  investigate-and-return loop, budgets, jargon ban, grid-up-front, journey
  maps, visuals, two-gate close, proxy mode
- `references/education-contract.md` — researcher lenses,
  facts-not-decisions rule, recurring mid-interview education
- `references/standing-doctrine.md` — core requirements and execution
  defaults baked into every pack
- `references/examples.md` — six worked interviews plus counter-examples;
  illustrations of the moves, not a lookup table
- `../_shared/agent-orchestration-policy.md` — dispatch semantics for
  researchers and the proxy interviewee