confirm

Files (1)

• SKILL.md

SKILL.md (first lines)

# Confirm

Before writing any code, align with the user on what the task actually is.

## Asking questions

Whenever you put a question to the user — one of the steps below, or an ad-hoc question when something is unclear — ask it and wait for their answer before carrying on.

Step 1's summary is the context step 2's questions need, so give it to the user alongside them.

## Workflow

1. **Summarize understanding** — In your own words, state:
   - The goal (what outcome the user wants)
   - The scope (what's in, what's out)
   - The approach you'd take (key files, structure, libraries)
   - Any assumptions you're making

2. **Ask clarifying questions** — Only ask about things that genuinely change the implementation. Skip questions whose answers won't affect the code. If you have no real questions, say so.

3. **Wait for confirmation** — Stop. Do not write or edit code. Do not run commands that modify state. Ask **"OK to proceed?"** and wait for the user to either confirm, correct, or redirect.

4. **Proceed only after explicit confirmation** — A "yes", "go ahead", "looks good", or similar. Silence or tangential replies are not confirmation.

## Rules

- **No code edits before confirmation.** Read-only exploration (Read, Grep, Glob) is fine and often necessary to write a useful summary.
- **Keep the summary tight.** A few bullets, not paragraphs. The user should be able to scan it and spot misunderstandings fast.
- **Surface disagreements early.** If the user's request seems wrong or risky, say so in the summary rather than silently complying.
- **One pass is usually enough.** Don't loop endlessly — once the user confirms, get to work.

## Format

```
**Understanding:**
- Goal: ...
- Scope: ...
- Approach: ...
- Assumptions: ...

**Questions:**
1. ...
2. ...

OK to proceed?
```

From tobico/tobico-skills, MIT.

More from tobico/tobico-skills