interview-plan_skill

Overview

This skill conducts Socratic interviews to turn vague requirements into clear engineering specifications and then invokes the platform's native Plan mode to produce an executable implementation plan. It reads a target document, probes gaps through structured questions, and writes the final plan directly into Plan mode for review and approval. The flow enforces safety checks and respects repository write constraints.

How this skill works

The skill starts by locating a requirement file (defaults to "plan.md") and analyzing business goals, completeness, ambiguities, and risks. It loads interview principles and dimension frameworks from "resources/INTERVIEW_PRINCIPLES.md" and "resources/INTERVIEW_DIMENSIONS.md" and runs a Socratic Q&A using the AskUserQuestion tool. After summarizing conclusions and risk mitigations, it calls EnterPlanMode to create the plan (tasks, dependencies, acceptance criteria, priorities, risk mitigations) and waits for user approval before calling ExitPlanMode to proceed.

When to use it

• Refining a vague product requirement into an actionable engineering plan
• Designing technical solutions where constraints or tradeoffs are unclear
• Preparing detailed implementation plans for handoff to engineers
• Auditing existing proposals for missing assumptions, risks, or conflicts
• Scoping projects that require prioritized task breakdowns and acceptance criteria

Best practices

• Provide the target requirement file path or keep "plan.md" in repo root for fast start
• Allow the tool to run multiple concise AskUserQuestion rounds rather than long free-text sessions
• Keep interview answers committed in the UI; avoid embedding large attachments in questions
• Follow Read-before-Write: inspect files with "rg" and quoted paths (e.g. "resources/INTERVIEW_DIMENSIONS.md") before modifying Plan
• Do not expect automatic Git commit/push; all Git write actions are blocked by design

Example use cases

• You have a one-page product brief and need a prioritized engineering plan with acceptance criteria
• A design doc has ambiguous performance targets; run targeted interviews to resolve tradeoffs and create implementation tasks
• Risk-heavy operations (infra changes, migrations) where the skill must surface hazards and request explicit authorization
• Converting stakeholder interviews into a sequenced task queue with dependencies for Sprints