Menu
Clarify requirements before implementing. Do not use automatically, only when invoked explicitly.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Run Cursor Agent headlessly and delegate work to another Cursor agent over the CLI. Use when the user asks to call, ask, invoke, run, or delegate to Cursor (e.g. "call cursor", "ask cursor", "invoke cursor agent"); when automating Cursor from scripts or agent-to-agent flows; or when the user mentions `agent -p`, headless Cursor CLI, or `cursor-agent.mjs`.
Hand off work in progress or finished to another agent for continuation or review. Produce a structured summary with enough background context, what was worked on, how, why, files touched, and what remains. Trigger when the user says "hand off this work", "prepare a handoff", "document what was done for the next agent", or ending a session another agent should pick up.
Review recently modified code for clarity, consistency, and maintainability while preserving exact functionality. Audit adherence to project conventions and industry best practices. Trigger when the user wants a code quality review, readability audit, maintainability review, or behavior-preserving refinement suggestions on a diff or implementation.
Execute an approved plan or spec document phase-by-phase, writing robust idiomatic code that follows codebase patterns. Trigger when the user says "implement this plan", "execute the spec", "work through the phases", or a plan in `dev/plans/` is approved and ready for implementation.
Review a given implementation critically and adversarially against its plan or spec. Look for antipatterns, red flags, bugs, unnecessary complexity, plan drift, and missing tests. Trigger when the user says "review this implementation", "review these changes", "review this branch", "adversarial review", "challenge these changes", or wants code scrutinized before merging.
Create a scoped, code-backed implementation plan from a todo, spec, issue, review notes, or raw user instructions. Use when the user asks to convert requirements into a proper plan, phased implementation plan, executor handoff plan, or reviewable planning artifact before coding.
| name | ask-questions |
| description | Clarify requirements before implementing. Do not use automatically, only when invoked explicitly. |
Ask the minimum set of clarifying questions needed to avoid wrong work; do not start implementing until the must-have questions are answered (or the user explicitly approves proceeding with stated assumptions).
Treat a request as underspecified if after exploring how to perform the work, some or all of the following are not clear:
If multiple plausible interpretations exist, assume it is underspecified.
Ask 1-5 questions in the first pass. Prefer questions that eliminate whole branches of work.
Make questions easy to answer:
defaults to accept all recommended/default choices)1b 2a 3c); restate the chosen options in plain language to confirmUntil must-have answers arrive:
If the user explicitly asks you to proceed without answers:
Once you have answers, restate the requirements in 1-3 sentences (including key constraints and what success looks like), then start work.
1) Scope?
a) Minimal change (default)
b) Refactor while touching the area
c) Not sure - use default
2) Compatibility target?
a) Current project defaults (default)
b) Also support older versions: <specify>
c) Not sure - use default
Reply with: defaults (or 1a 2a)