---
name: ask-me
description: Guided plan creation through structured questions. Use when starting a new feature, task, or significant change to produce a production-ready plan before writing code.
---

# Ask Me — Guided Plan Creation

**Type:** Rigid — follow the question sequence exactly. Do not skip categories.

## When to Use

- User wants to plan a new feature or significant change
- User invokes `/ask-me`
- A task is complex enough that jumping straight to code risks wrong work

## When NOT to Use

- Trivial changes (typo fixes, single-line edits)
- The user has already provided a detailed, unambiguous specification
- Pure research or exploration tasks

## Goal

Gather structured requirements through incremental questions, then produce a clean, production-ready plan in markdown. The plan covers all critical dimensions so implementation can proceed without guesswork.

## Workflow

### Phase 1: Objective

Ask first. Establish what the user wants before anything else.

**Questions to ask (1-2 via AskUserQuestion):**
- What exactly should change? What is the desired end state?
- What should explicitly stay the same / not be touched?

**Template:**
```
1) What is the goal?
   a) [Inferred option from context]
   b) [Alternative interpretation]
   c) Something else (describe)

2) What should NOT change?
   a) Everything outside the target area (Recommended)
   b) Specific exclusions: <list>
   c) No constraints
```

Wait for answers before proceeding.

### Phase 2: Scope

Narrow down the boundaries.

**Questions to ask (1-3 via AskUserQuestion):**
- Which files, components, or services are in scope?
- Which layers are affected (UI, business logic, data, infrastructure)?
- Is this a new addition or a modification to existing behavior?

If a quick codebase scan can answer scope questions, do the scan instead of asking. Only ask what you cannot determine from the code.

### Phase 3: Acceptance Criteria

Define "done" concretely.

**Questions to ask (1-2 via AskUserQuestion):**
- How will we know this is complete? What does success look like?
- Are there edge cases or error scenarios to handle?

Offer specific criteria as options when possible:
```
What defines "done"?
a) [Specific measurable outcome] (Recommended)
b) [Alternative success definition]
c) Custom criteria (describe)
```

### Phase 4: Constraints

Identify technical boundaries.

**Questions to ask (1-3 via AskUserQuestion):**
- Compatibility requirements (versions, browsers, platforms)?
- Performance requirements (latency, throughput, size limits)?
- Dependencies — can we add new ones, or must we use what exists?
- Style or architectural patterns to follow?

Skip questions where the codebase or project docs already provide the answer. State the assumed constraint and move on.

### Phase 5: Architecture

Determine where this fits in the system.

**Questions to ask (1-2 via AskUserQuestion):**
- Where does this logically belong in the existing architecture?
- Does this require new abstractions, or does it extend existing ones?

Before asking, explore the relevant codebase areas. Present findings with your questions:
```
Based on the codebase, [component X] handles similar logic.
Should the new behavior:
a) Extend [component X] (Recommended)
b) Live in a new module alongside it
c) Replace [component X] entirely
```

### Phase 6: Risks

Surface potential problems before they happen.

**Questions to ask (1-2 via AskUserQuestion):**
- Are there data safety concerns (migrations, destructive operations)?
- What is the rollback strategy if this goes wrong?
- Could this break existing functionality?

Skip if the change is low-risk and isolated. State why you are skipping.

### Phase 7: Testing

Define the verification strategy.

**Questions to ask (1-2 via AskUserQuestion):**
- What testing approach fits? (unit, integration, e2e, manual)
- Are there specific scenarios that must be tested?

## Question Delivery Rules

1. **Use AskUserQuestion tool** for all questions — never ask in plain text
2. **1-4 questions per round** — do not overwhelm
3. **Always offer multiple-choice options** with a recommended default
4. **Include a fast-path** — "Reply `defaults` to accept all recommended choices"
5. **Wait for answers** before moving to the next phase
6. **Skip questions you can answer** from the codebase — state your assumption instead

## Plan Output

After gathering answers from all relevant phases, write the plan to the plan file.

**Plan structure:**

```markdown
# Plan: [Feature/Task Name]

## Context
[1-3 sentences summarizing what was agreed upon]

## Objective
[What changes, what stays the same]

## Scope
[Files, components, services affected]

## Files to Create / Modify

| File | Action | Purpose |
|------|--------|---------|
| path/to/file | Create/Modify/Delete | What and why |

## Implementation Steps

### Step 1: [Description]
- Specific changes to make
- Code patterns to follow

### Step 2: [Description]
...

## Acceptance Criteria
- [ ] [Criterion 1]
- [ ] [Criterion 2]

## Constraints
- [Constraint 1]
- [Constraint 2]

## Risks & Mitigations
- **Risk:** [Description] → **Mitigation:** [Strategy]

## Verification
1. [How to verify step 1]
2. [How to verify step 2]
3. [End-to-end verification]
```

**Output rules:**
- Markdown only — no JSON, no XML wrappers, no raw tool output
- Self-contained — a reader should understand the full plan without external context
- Actionable — each step describes concrete changes, not vague goals

## Integration

This skill gathers requirements. If `superpowers:writing-plans` is available, hand off to it for final plan formatting. If not, use the plan structure above directly.