plan-verify.md

gistfile1.txt

---
name: plan-clearify
description: Reads a plan in the chat, checks UI/UX/data effects, offers two ways to read the request, asks simple questions about edge cases, and narrows work to the smallest safe change. Use when there is already a plan before coding, when the user wants the plan checked or improved, when the ask is unclear, or when the user says plan-clearify.
disable-model-invocation: true
---

# Plan clarify (simple English)

## Rules you must follow

Do the steps **in order**: 1, then 2, then 3, and so on. Finish each step (and wait for the user’s answers if needed) before the next. Do not skip steps or mix them. If the user gives new facts later, go back only to the steps that those facts change.

---

### Step 1 — Read the plan

- Find the **latest** plan in the chat (the block or list the user treats as the real plan).
- Say it back in **one short paragraph** in your own words: what they want, which screens or flows, and what data or APIs are involved.
- If there is no plan, ask the user to paste one or write one before you continue.

---

### Step 2 — Two possible meanings (do this before deep edge questions)

- From the plan **and** the first user message, think of **two different ways** (A and B) the user might mean the same words—different enough that the code would not be the same (who sees it, what is saved, what screen changes, etc.).
- Write **Scenario A** and **Scenario B**, one line each.
- Ask clearly: **Which scenario should we follow?** Or can we **combine** them? Say how. **Do not guess**—wait for an answer.

---

### Step 3 — Check effects: screens, experience, data

For each **separate** piece of work in the chosen scenario, ask **one short question** in this shape:

> **Change:** [what we would change]  
> **Effect:** [screen | experience | data] — [what the user would notice, e.g. new field, slower load, new filter]  
> **Is this OK?** (yes / no / change it like this: …)

Touch at least:

- **Screen:** pages, components, text, layout, accessibility, translation keys.
- **Experience:** who can do it, empty states, errors, loading, steps in a flow, confirmations, small screens.
- **Data:** database shape, APIs, Dynamo / stored-data, hooks (`filterOn` if it matters), workflows, migrations, old data.

Put several questions in one message if needed (about 3–6 is OK), but **do not skip** a whole area (screen / experience / data) if the plan touches it.

---

### Step 4 — Odd cases and “what if”

After the user picks a scenario and answers the effect questions:

- List **odd cases** in plain words (no data, half-failed save, slow network, two people editing, who is allowed, running twice, old clients still in use, feature flags).
- For each important risk, ask **at least one** question; group similar questions together.
- Keep going until **almost nothing is left vague**—you could start coding without inventing behavior or data rules.

---

### Step 5 — Keep it small

- Push back on the plan: can we **drop** something, **do it later**, or **fix it with less code** (fewer files, fewer new ideas)?
- Offer the **smallest** version that still matches what the user confirmed.
- Add to the plan (or a short **“How we build it”** part): steps in order, which files or areas, **one** main pattern that fits this repo—**no** big rewrites “just because.”

---

### Step 6 — Last check (can repeat)

- Ask: **Is anything still unclear or worrying?**
- If yes, or answers add new scope, go back to the **first** step that changed (often 2, 3, or 4) and only redo what needs redoing.
- **Stop** only when: scenario is chosen, effects are OK or adjusted, odd cases are decided, and the small build plan is agreed.

---

## How to write answers

- Use **numbered questions** more than long paragraphs.
- One short plan summary + questions per reply is fine; **do not write implementation code** until Step 6 is done unless the user says to code anyway.
- If project rules talk about stored-data, workflows, or docs, **mention** those in the effect questions when they apply (do not quietly grow the scope).

## Short examples

**Step 2 (two scenarios):**

- Scenario A: Only admins see the new field on the edit page; the list does not change.  
- Scenario B: The same field on add form, list columns, and filters.  
→ Ask which one (or a mix).

**Step 3 (effect question):**

> **Change:** New required field on stored-data X.  
> **Effect:** data — every save sends the new field; list may need `filterOn` and a column.  
> **Is this OK?**

**Step 5 (small build):**

- Reuse the existing form block + one API field + hook update; skip the dashboard until later.

---

## Extra note

- When you actually code, you can also use the workspace rule **scenario-impact-analysis** for breadth (happy path vs edge cases).