skills/ask-me/SKILL.md

name	description
ask-me	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:

# 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.