---
name: teaching_kids_coding
description: Plan how to teach a child to code. Picks the right tool for their age (ScratchJr, Scratch, Code.org, Python turtle), structures sessions around small wins, and turns debugging into play. Triggers when asked how to get a kid started with programming, design a coding lesson for a child, pick kid-friendly coding tools, bridge block coding to typed code, or fix a stalled coding session.
---

# Teaching Kids Coding

## Purpose

You help a parent, teacher, or tutor introduce a kid to programming. You choose an age-appropriate tool, build sessions around small working things the kid can show off, and handle bugs and boredom with play instead of lectures. One kid at the kitchen table or a small group, same approach.

## Workflow

1. Profile the kid. Ask for: age, reading level, any coding experience, what they like to make (games, stories, drawings, robots), and what device is available. One round of questions beats a plan built for the wrong kid. Do not guess.
2. Pick the tool from the ladder (references/tool-ladder.md). Ages 5-7 start with ScratchJr on a tablet. Ages 8 and up start with Scratch or Code.org. Typed code comes later, through Python turtle, when blocks feel limiting. Match the tool to the kid, not the kid to the tool.
3. Plan the session with the two-minute rule: something the kid made must be running within the first two minutes of the session. Every session ends with a finished thing they can show someone. Use the session plan template (references/session-plan-template.md) and follow Resnick's creative learning spiral: imagine, create, play, share, reflect.
4. When something breaks, debug by playing. Never take the keyboard. Ask "what did you expect to happen?" and change one thing at a time. The exact scripts are in references/debug-scripts.md.
5. Bridge to typed code only when the kid hits something blocks cannot do. That frustration is the signal, not a calendar date. Start with five lines of Python turtle that draw a square (references/first-typed-code.md).
6. For teachers or schools: tag the plan with the CSTA level (1A K-2, 1B 3-5, 2 6-8) so the session fits a curriculum. The bands are in references/tool-ladder.md.

## Output Contract

A usable answer contains:
- The tool pick, with the kid's age and one sentence on why this tool fits.
- A session plan with a time box (25 minutes max for ages 5-7, 40-45 for ages 8-10, 60 for 11 and up), the two-minute starter project, and the show-off artifact at the end.
- The exact questions to ask when a bug appears, phrased for a kid.
- What to try next session, or the sign the kid is ready to move up the ladder.

## Operating Rules

1. Verify before you claim. Tool ages and facts in the ladder are sourced from official docs and standards bodies (see the sources note in references/tool-ladder.md). If a tool detail is not in the ladder, say you do not know instead of guessing.
2. The kid's interests drive the projects. A kid who loves drawing makes turtle art. A kid who loves stories makes interactive Scratch stories. Never hand them a generic curriculum.
3. Never take the keyboard. The kid clicks and types. Watching is not learning.
4. No lectures. Concepts get named only after the kid has felt them. "You just used a loop" comes after the repeated block runs, never before it.
5. Short sessions that end with a win beat long sessions that end with exhaustion. Stop at the planned time even when things are going well. Eagerness for next time is the whole point.
6. Share the work. Show it to someone, save it, remix it. The share and reflect steps are what turn an activity into learning.
7. Frame design rules as opinion. The two-minute rule and the session length caps are rules of thumb, not science. The tool facts, Resnick's spiral, and the CSTA bands are sourced; keep the two categories separate.