You already know how to make things happen in Scratch: sequences, variables, loops, decisions, and fixing bugs. Today the question is different. How do you turn a fuzzy idea into a plan you can actually build?

You will meet four steps coders use to break a problem down, use them on a build you choose, and start that build in Scratch.

Coders use four steps of computational thinking to turn a big idea into something they can build. Meet each step on a worked example as you go.

Idea: a simple chase where your sprite catches another sprite and the score goes up.

• Decomposition (smaller pieces): your sprite moves; the target moves; detect a touch; score changes.
• Pattern recognition (what repeats or what you already know): arrow-key movement and a score variable are things you have used before.
• Abstraction (keep only what matters): one sprite you control, one target, one score. Ignore lives, levels and extra enemies for now.
• Algorithms (steps in order): when the green flag starts the program, forever: move your sprite on the arrow keys; if your sprite is touching the target, change score by 1 and move the target to a new place.

That plan is short enough to build. Yours will be too.

Choose one build idea, or invent a close cousin of one of these:

• an animated scene (two sprites that take turns doing something)
• a short quiz round (ask a question, check the answer, change a score)
• a simple chase (catch a target, score goes up)

Open Scratch. Reopen a project you saved earlier if it helps, or start a fresh one. If your saved project is missing, ask your teacher or begin a new project from your plan.

1. In your copybook, fill in a short plan for your idea using all four steps. Copy these four headings and complete each with one short line (like the chase example above):
   • Decomposition: Pieces I will build: …
   • Pattern recognition: I will reuse: …
   • Abstraction: Only what matters for now: …
   • Algorithms: In order, the program should: …
   Four short bullets, then Scratch: a rough algorithm is fine. Spend only a few minutes on the plan, then move to Scratch even if the algorithm is still rough.
2. Build only the first piece of that plan in Scratch. For a chase, that might be movement for the sprite you control. For a quiz, the question and answer check. For a scene, the first sprite's actions.
3. Run what you have. Does that first piece match the algorithm you wrote?

Keep building from your plan in Scratch. As you add each piece, say (quietly to yourself is fine) which of the four steps you are using.

Done for today looks like this:

• you have a complete written algorithm in your copybook (update it if the build taught you a better order)
• at least one clear behaviour from that algorithm runs end to end without you explaining missing bits out loud
• you can point to one place you used decomposition, one place you used pattern recognition, one place you used abstraction, and the algorithm that holds it together
• you have tested that working behaviour at least once

If time is short, a solid first piece plus a complete written algorithm counts as done today. Extra pieces of the plan are a stretch if you finish early.

If something breaks, use the debugging routine you already know: read the symptom, find the block, form a hypothesis, test it, and revert if you are wrong.

Save your project the way your teacher just said before you stop. If you are unsure: File → Save to your computer (or Scratch cloud Save now), then confirm the project name is visible.

Today the four steps did real work, not just labels on a slide.

• Decomposition split your idea so you were not trying to build everything at once.
• Pattern recognition let you reuse skills and blocks you already knew.
• Abstraction kept you focused on what mattered so the build did not get too big.
• Algorithms gave you an order to build and a way to check the program against the plan.

When the build drifted from the plan, updating the algorithm was part of the job, not a failure.