Skip to content
Zero to Kiro Hero

Plan the change

Goal: an explicit plan for making spent honest, before touching code. This is the spine of the whole workshop: the plan is the difference between a change that holds and one that silently breaks.

You’ll build the plan two different ways and compare what each surfaces.

Path A: Spec mode

Section titled “Path A: Spec mode”

Path B: grill-me-with-docs

Section titled “Path B: grill-me-with-docs”

Run it against the same goal, but specific enough that Kiro can find what to fix — name the symptom, not the fix:

/grill-me-with-docs the spending total in /summary over-counts — make it report the honest number

It reads the code and the project docs you generated with /code summary, then interrogates you, often 10 to 20 questions, until it’s sure it understands, and writes the answers into a decision doc. Naming the symptom only points it at the right code — it still forces the decisions the prompt left open:

  • Does a transfer between your own accounts count as spending? (no)
  • Does a refund reduce spending, or get ignored? (reduce)
  • Do pending charges count before they clear? (no)

That’s the whole point: the bug was born from unanswered questions. This drags them into the light before a single line changes.

Write the plan down

Section titled “Write the plan down”

However you got here, capture the decisions and the touch points:

  1. Decisions: transfers excluded, refunds netted, pending excluded, for an honest total of $850.
  2. Touch points (this is what vibing misses): the transactions schema + seed (add a kind so a transfer is distinguishable), the /summary query, the /transactions output, and the tests.