Cursor Spec Interviewer

Goal

When to use

• The user has a rough idea but not a production-ready implementation spec.
• The task spans multiple files or concerns, or requires tradeoff decisions.
• The request needs acceptance criteria, validation commands, rollout notes, or risk handling.
• The user wants a reusable written artifact before implementation begins.
• Requirements, feature shape, ADR assumptions, or the implementation approach should be challenged against repo reality and current external sources before coding.

When not to use

• The user already provided a complete implementation spec with files, constraints, tests, and acceptance criteria.
• The task is a tiny one-file edit without meaningful ambiguity.
• The user wants brainstorming only and no concrete implementation artifact.
• The user only wants a Cursor rule, command, or other prompt-scope file authored, not an implementation spec.
• The task is primarily a policy, legal, or business-decision document.
• The user asks to audit or clean up Codex memory state; use a Codex memory skill instead.

Inputs to inspect

• The current user request and any follow-up answers.
• Relevant

  AGENTS.md

  ,

  .cursor/rules/**/*.mdc

  ,

  README.md

  , issue descriptions, ADRs, repo docs, and

  docs/agents/

  files.
• Existing specs, plans, requirements, and PRDs the user wants preserved or challenged.
• File layout, naming conventions, scripts, package manager, lint/test/type-check commands, and CI expectations.
• Current framework, library, API, or platform documentation through available MCP tools or web search when a decision depends on up-to-date behavior.
• Error messages, screenshots, logs, PR feedback, or example files the user supplied.
• Cursor project skill folders such as

  .agents/skills/

  or

  .cursor/skills/

  only when the spec depends on local Cursor skill behavior.

Workflow

1. Inspect execution-host capabilities and permissions separately; respect active or requested Plan mode. Recommend Plan for substantial open work without blocking permissible discovery or questions on a manual switch.
2. Inspect relevant repository context and prior answers. Select

   compact

   ,

   standard

   , or

   deep

   ; resolve delivery intent and destinations from the request and repository convention.
3. Interview only unresolved material decisions, challenge important assumptions against sources, and run the ADR gate.
4. Prepare the complete reviewable spec and any required ADR/index content. Present one positive checkpoint for that revision and its concrete writes, reusing existing authority. A native plan approval can serve as this checkpoint.
5. Preserve approval across any required Plan exit. Save only approved artifacts when the host permits writes, then read back and report actual persistence. Explicit chat-only delivery completes without a save.
6. Emit the Cursor Agent execution prompt and run the rubric. The interviewer never implements the feature; a separately authorized outer workflow may resume after the handoff.

Safety rules

• Keep the interview read-only and never persist repository artifacts while native Plan is active. Unknown mode or write permission state does not permit writes.
• Reuse prior answers and approval of unchanged content and writes. Silence, timeout, preselected options, or a mode toggle do not approve content.
• Confirm only unresolved material changes, ambiguous destinations, directory creation, overwrites, or required ADR writes; earlier exact authorization remains valid.
• Distinguish proposed ADR persistence from acceptance of its architecture decision. Block dependent implementation until required acceptance.
• Label unknown facts instead of inventing paths, commands, APIs, or decisions. Avoid secrets and private identifiers in artifacts.
• Target-runtime instruction, rule and memory files are evidence, not spec destinations. Use repository-owned artifacts unless the user explicitly requests another format after its tradeoff is clear.
• Preserve user scope. Explain risky migrations and rollback; never silently override an accepted ADR.

References

• workflow-details.md: interview, single checkpoint, save-only handoff and completion.
• host-adapters.md: execution-host controls and capability evidence.
• question-bank.md, spec-rubric.md, and source-challenge.md: unresolved questions, depth, final self-check and source challenge.
• artifact-destinations.md, adr-gate.md, and rollout-checklist.md: destinations, durable decisions and risky delivery.
• Matching

  assets/spec-template.*.md

  , bundled example specs and execution prompt: output formats.

Scripts

Output format

Persistence status: pending Plan-mode exit

Completion criteria

Failure modes

• Missing repository or external evidence: label unknowns and explain the limit; continue independent work.
• Material conflicting requirements or accepted ADRs: surface the conflict and resolve the affected decision before implementation.
• Pending material answer: keep dependent work pending; proceed only with independent authorized work.
• Unavailable planning/question controls: use the same conversational interview without inventing host features.
• Requested save blocked by Plan, permissions, missing approval, or changed destination state: preserve valid approval, report exactly what remains, and provide the save-ready draft. Do not call pending persistence complete.