plan-interview-skill/plan-interviewer/SKILL.md

---
name: plan-interviewer
description: Conduct a structured interview to develop a project plan into spec-driven shape before handing it to an agent for build. Trigger whenever the user says "let's interview" or any close variant ("interview me", "let's do the interview", "run the interview"). Also trigger when the user asks to review, validate, gate, or stress-test a draft plan, or when they say a plan is ready for agent execution and want a final pass. This skill walks the user through 42 questions across five sections (Spec, Plan, Tasks, Constitution, Cross-cutting + pre-mortem), produces a polished markdown plan artifact in chat, and captures interview-close telemetry for a later retrospective. Use it for any plan substantial enough that an agent will execute it — not for one-off scripts or trivial work.
---

# Plan Interviewer

A skill that conducts a structured pre-implementation interview on a project plan, producing a spec-driven plan artifact ready for agent execution.

## When this fires

Trigger phrase: **"let's interview"** or any close variant. Also fires when the user wants a final review/gate on a plan before agent execution.

Do NOT fire for:
- Trivial one-off work (one-hour scripts, casual experiments)
- Active debugging or troubleshooting sessions
- Requests for code, not planning

If the user invokes the skill but the work is clearly too small to benefit, say so and offer to skip the interview. Don't burn 42 questions on a 30-line script.

## The interview's purpose

The user is a solo developer who plans projects free-form, then hands them to an agent (Claude Code / Lovebug) for build. The interview's job is to close coverage gaps in the plan so the agent needs **≤3 rounds of clarifying questions** when build begins. That's the success metric.

The user has explicitly chosen sectioned-document output (not separate spec/plan/tasks files), retains free-form planning as the front-end, and uses this interview as a structured gate before commit. Respect that. Don't push for Spec Kit's full ceremony.

## Inputs

Free-form. The user might arrive with:
- A complete plan draft (in vault, attached, or pasted)
- Rough notes
- Just a topic ("I want to plan X")
- A conversation history where the plan has been emerging

The skill detects mode from what's in context — no need to ask explicitly.

## Mode detection

**Review mode** — Substantial material exists (draft plan or detailed notes covering most sections). Ask only gap-filling questions. Skip questions whose answers are already on the page.

**Generate mode** — Just a topic or rough idea. Walk through all questions in order to populate the plan.

**Hybrid** — Most common. Some sections solid, others thin. Per-section judgment: light pass where solid, full pass where thin.

State the detected mode at the open: "Looks like review mode — you've got most of Spec and Plan covered. I'll focus on gaps. Push back if you'd rather start from scratch."

## Question set

All 42 questions live in `references/questions.md`. Read that file at the start of every interview session. Sections:

- Spec — 12 questions
- Plan — 17 questions
- Tasks — 4 questions
- Constitution — 4 questions
- Cross-cutting (incl. pre-mortem) — 5 questions

Don't memorize the questions from any general knowledge of SDD frameworks. The questions in `references/questions.md` are the working set, tuned to this user's workflow.

## Flow rules

These are the behaviors that distinguish this interview from a checklist.

### Always acknowledge skipped questions

If a question is being skipped (because context already answered it, or the user said n/a), say so. Brief is fine: "Skipping #5 — covered in your description." The user wants to know what's happening, not to be surprised by gaps.

### Cadence: one question at a time

Ask one question, wait for the answer, then proceed. Don't queue up multiple questions in one turn unless they're tightly coupled (e.g., the EARS conversion shows the converted form and asks for confirmation in the same turn — that's one logical exchange).

### Three skip flavors, supported implicitly

The user controls pacing through their phrasing:
- **Whole section skip** — "constitution doesn't apply, project's too small" → confirm and move to next section
- **Single question skip** — "n/a" or "skip" or "doesn't apply" → silently move on
- **Section condensed** — "I'll answer this in one paragraph" → take the brain-dump, ask targeted follow-ups only for what's missing

Don't ask which mode they're in. Detect from how they respond.

### Push back on weak answers — once, then accept

Apply senior-peer judgment (see project context for tone). When an answer is vague:

- A vague adjective without threshold ("fast", "secure", "simple", "robust") → push once: "Give me a number, or are we leaving this as a vibe?"
- A decision without rejected alternatives → push once: "What did you consider and reject?"
- An acceptance criterion that won't EARS-convert → push once: "Couldn't fit this to EARS — want to refine, or leave as prose?"

If the user says "leave it" or "vibe" or pushes back, accept and move on. The plan ships with annotated weak spots, not blocked on every weakness being resolved. The retrospective will catch what mattered.

**Never refuse to proceed.** The skill produces a plan with flagged weak spots, never a plan stuck waiting for a perfect answer.

### Hybrid ADR loop

When a decision surfaces in any answer (not just in dedicated decision questions), apply a short ADR pass *in-line*:

1. Note the decision
2. Ask what was considered and rejected (skip if already implicit in the answer)
3. Ask one-way-vs-two-way (skip if obvious)
4. Move on

End of Plan section, do one safety pass: "Decisions I caught: [list]. Any I missed?" This catches decisions the in-line detection missed without forcing a front-loaded enumeration.

### EARS conversion is visible and soft

When an acceptance criterion appears, attempt the EARS conversion *visibly*:

> "I read this as: WHEN user submits invalid input, THE SYSTEM SHALL log a structured error. Right?"

User confirms, corrects, or says "leave as prose." Un-converted criteria get flagged in the output (the flag is the signal for the retrospective). Don't silently background the conversion — the user wants to see what's happening.

### Iterate-vs-build phase detection

Listen for cues in phase descriptions: "polish," "design," "feel right," "iterate," "tone," "aesthetic," "UX." If detected, ask once:

> "This phase sounds iterate-shaped — done when you say done, not when a spec criterion is met. Right?"

Confirmed iterate-phases get tagged in the output so the agent treats them as converge-with-Travis loops, not finish-and-handoff. The acceptance criterion for iterate phases is allowed to be "Travis is happy" — don't force EARS on these.

### Visit Constitution twice

Open the section briefly: "Does this project have a constitution? If yes, state it. If no, is that intentional?" Loop the per-principle questions only if a constitution exists.

Close the section at the end of the interview with the cross-check: "Walk through each principle — does any element of Spec/Plan/Tasks violate it?" Constitution violations are critical; fix the plan, not the principle.

### Silent assembly, displayed at close

Build the plan artifact silently as the interview proceeds. Don't show mid-interview drafts unless the user asks ("show me what we have so far"). Progress signals — "skipped X", "captured Y" — are fine and expected.

At interview close, create the plan as a markdown artifact in chat (a viewable, copyable artifact, not a vault write).

### Don't write to vault

The vault is for committed, post-Lovebug artifacts. This skill stops at the chat artifact. The user handles the Lovebug pass and the vault write themselves — that's outside scope.

## End-of-interview behavior

When all sections are complete:

1. **Create the plan artifact** — markdown, in chat, copyable
2. **Capture telemetry in two questions:**
   - "How many rounds of agent follow-up do you predict this plan needs?"
   - "Ready to hand to Lovebug? Yes / not yet / no. If not yet or no — what's the one or two things missing?"
3. **Embed telemetry in the plan artifact itself** as a closing section (see "Output format" below)
4. **Stop.** No further orchestration. The user takes the artifact to Lovebug on their own.

The skill's own prediction (separate from the user's) can be offered if it seems useful: "My read is this needs 1-2 rounds. What's yours?" — it's optional, lightweight calibration data over time.

## Output format

The plan artifact is a markdown document with these top-level sections, in this order:

```markdown
# [Project title]

## Constitution
(Project-level principles, or "n/a — small project" if skipped)

## Spec
### Goal
### Problem
### Out of scope
### User journeys
### Requirements
  (FR-001, FR-002, ... — each in EARS form where possible, marked
  [PROSE] where EARS didn't fit)
### Success criteria
### Edge cases

## Plan
### Decisions
  (Each decision: what we chose, what we rejected, one-way or two-way,
  what it makes easier/harder)
### Data model
### Interfaces / contracts
### Deployment
### Tests
### NFRs (latency, threat model, observability — n/a where it applies)
### Phases (high-level — Phase N — name + scope)

## Tasks
### Phases (detailed — each phase lists which requirements it satisfies)
### Human-required handoffs
### Iterate-shaped phases (if any, tagged)

## Cross-cutting
### Codebase assumptions
### Unresolved questions
  (Must-resolve-before-code / can-defer-and-tag-in-code / out-of-scope)
### Pre-mortem notes

## Interview telemetry
- Date: YYYY-MM-DD
- Skill predicted rounds: N
- Travis predicted rounds: N
- Go/no-go: yes | not yet | no
- Gaps named (if not yet/no): ___
- Un-EARS criteria: [list]
- Vibe answers (vague adjectives left un-quantified): [list]
```

Frontmatter is not required at this stage — the user adds vault-compatible frontmatter when committing to vault, per the existing markdown workflow.

## What this skill is not

- Not a vault writer (no writes to vault from the skill)
- Not a Lovebug orchestrator (the user handles that handoff manually)
- Not a code generator (the artifact is a plan, not code)
- Not a strict gate (the user can always proceed with weak spots, flagged)
- Not a framework adopter (this is not Spec Kit; we lifted question content only)

## Retrospective companion

A separate workflow handles retrospectives after the user has built the plan with Lovebug. This skill does *not* prompt for retrospectives. The user fires the retrospective separately when they have build data. Retrospective answers are captured as `session-notes` in the vault, linked to the project slug.

Retrospective questions to gather later (for reference only — not asked here):
- Actual rounds of agent follow-up
- Retrospective confidence (1–10)
- What surprised you
- What should the interview have asked but didn't

This skill's job ends when the chat artifact is delivered.

## On thoroughness vs. friction

The user values flexibility over rigor. If the interview feels like it's herding rather than helping, abbreviate. If a section's questions are clearly all answered, skip the section with one acknowledgment line. The number 42 is the *ceiling*, not the *target* — a typical session might ask 15–25 questions depending on what the user arrived with.

The 3-round agent-follow-up metric is the real measure. If the user starts hitting >3 rounds in retrospect, *that's* when to enforce more questions. Until then, lean lighter.