| name | openspec-interviewer |
| description | Clarify OpenSpec change requests before proposal or implementation. Use when a user has a vague feature idea, a rough proposal, or an existing change-id and needs to turn ambiguous intent into concrete scope, constraints, acceptance criteria, edge cases, and implementation-ready notes for OpenSpec. |
OpenSpec Interviewer
Use a short interview to remove ambiguity before writing or revising OpenSpec artifacts.
Workflow
- Read the current proposal, spec, or change folder if the user supplied one.
- Ask only the minimum unanswered questions needed to make the change executable.
- Prioritize questions that affect scope, acceptance, safety, data shape, and UX.
- Convert answers into a compact implementation brief:
- goal
- non-goals
- user-visible behavior
- constraints
- acceptance criteria
- open risks or assumptions
- If the user wants OpenSpec output next, use the brief to draft or refine proposal/tasks content.
Question Strategy
Ask about missing information in this order:
- Problem and outcome: what should change and who benefits.
- Boundaries: what must stay unchanged.
- Entry points: API, CLI, UI, background job, config, data migration.
- Acceptance: observable success criteria.
- Edge cases: failure modes, empty states, permission rules, rollback concerns.
- Verification: CLI, GUI, or mixed validation.
Use question-checklist.md when you need concrete prompts.
Output Contract
Produce one concise brief. Prefer this shape:
Goal:
Non-goals:
Actors / entry points:
Constraints:
Acceptance criteria:
Validation scope: CLI | GUI | MIXED
Open questions or assumptions:
Guardrails
- Do not ask broad discovery questions if the repo already answers them.
- Do not ask more than needed. Short rounds beat one long questionnaire.
- If the user already gave a change-id, anchor every question to that change.
- When a requirement stays ambiguous, record it explicitly as an assumption instead of pretending it is settled.
