CommunityCoding & Developmentgithub.com

Sigma-Works/iCode-Claude-Skills

Turn one or more lesson-plan files (PDF, DOCX, text) into a 60–90 minute classroom slide deck that hits every learning objective, with a hands-on web game after each learning goal. Use when a teacher uploads lesson plans and asks for slides, a slideshow, a deck, or a presentation to teach from. Not for after-class parent updates (use report-generator).

What is iCode-Claude-Skills?

iCode-Claude-Skills is a Claude Code agent skill that turn one or more lesson-plan files (PDF, DOCX, text) into a 60–90 minute classroom slide deck that hits every learning objective, with a hands-on web game after each learning goal. Use when a teacher uploads lesson plans and asks for slides, a slideshow, a deck, or a presentation to teach from. Not for after-class parent updates (use report-generator).

Works with✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Sigma-Works/iCode-Claude-Skills/tree/HEAD/lesson-generator

Installed? Explore more Coding & Development skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Ask in your favorite AI

Open a new chat with this agent skill pre-loaded.

Documentation

Lesson Generator

Build a teach-ready slide deck from the user's lesson plans. The deck must:

  1. Cover every learning objective in the lesson plans (nothing dropped, nothing invented that contradicts them).
  2. Run 60–90 minutes, scaled to how much there is to teach.
  3. Put an interactive web game right after each learning goal, so students immediately apply what they just learned.
  4. Work for a small, energetic class of 4–10 students (often kids or teens).

When to Activate

  • The teacher attaches lesson plans and asks for slides, a slideshow, a deck or a presentation.
  • The teacher asks to rebuild, shorten or re-theme a deck this skill made.
  • Not for a parent report or class summary after teaching: use report-generator.
  • Not when there are no lesson plans and the teacher wants a lesson designed from scratch: ask for the plans, or say this skill needs them.

Step 1 — Gather inputs

Read every attached lesson plan in full. Extract into a working list:

  • Program / course name, unit or sprint, lesson numbers and titles
  • Every numbered objective, verbatim (these are the checklist you must hit)
  • Class-outline content, definitions, examples and code snippets
  • Activities, projects, labs, required materials, worksheets
  • Any links, preparation notes, or resource folders mentioned

Then check the user's message for:

InputIf givenIf not given
Game websites to useUse only those sites (verify each, Step 3)Choose games yourself (Step 3)
Class lengthUse itCompute it (Step 2)
Class size / ageUse itAssume 4–10 students, ages ~8–14
Class behavior notes ("chaotic", "quiet", "advanced")Adapt activities and management slidesAssume mixed energy

Do not stop to ask unless the lesson plans are missing or unreadable. State the assumptions you made in one line when you finish.

Step 2 — Group objectives into learning goals and set the length

Lesson plans often list many fine-grained objectives (e.g. 8–12). One game per objective would be too many. Group related objectives into learning goals (clusters that share a concept), usually 2–6 per class. Example: "define position", "explain top/left", "apply position", "describe z-index", "use z-index" → one goal: Position & stacking.

Length (unless the user set one):

Learning goalsClass lengthGames
2–360 min2–3
475 min4
5–690 min5–6

If two lesson plans are combined into one class, count goals across both.

Time budget per learning goal (adjust to fit the total):

  • Teach: 5–10 min (explain, show, quick check for understanding)
  • Try-it / activity: 2–5 min (hands-on in their own project, or an unplugged movement activity)
  • Game: 4–7 min
  • Fixed blocks: warm-up + rules 3–5 min at the start; project kickoff 5–8 min if the lesson plan has a project; exit ticket 2–3 min at the end

Use the upper end with fewer goals and the lower end with 5–6 goals (6 goals × 11 min + fixed blocks ≈ 76 min leaves room in 90). If it still doesn't fit, trim teach and try-it time before game time, and never cut a game below 4 min.

Write the schedule out (minute ranges per segment) before building. The minutes must add up exactly to the class length. Mark one segment as the buffer to cut if class runs long.

Step 3 — Pick and verify the games

Each game must practice the skill of the learning goal it follows. Prefer free, no-login, browser-based games; kids should not need accounts or payment.

If the user named websites: fetch each site, list its games, and pick ones that match each learning goal. Note which are free vs paid; never assign a paid/Pro game without flagging it.

If not: pick from your own knowledge. Good starting points (verify before use — availability and pricing change):

TopicGames
CSS flexbox / grid / positioningCodepip: Flexbox Froggy, Grid Garden, Anchoreum (codepip.com/games — check which are Free vs Pro); Flexbox Defense
CSS selectorsCSS Diner
HTML basicsCodepip HTML games (check if free)
JavaScript / general programmingCodeCombat (free levels), Elevator Saga (older students), Untrusted
Block coding / logic (younger kids)Blockly Games, Code.org activities, Lightbot
PythonCodeCombat (Python mode), CheckiO
GitLearn Git Branching
SQLSQL Murder Mystery, SQL Island
Typing / keyboard skillstyping.com, Nitro Type
Robotics / logic / algorithmsCode.org, Blockly Games (Maze, Bird), Lightbot
Design / UXCan't Unsee, The Boolean Game, Kerning game (type.method.ac), Color game (color.method.ac)

Always verify: fetch each chosen game URL to confirm it loads, is free, and matches the goal. Fetch all candidate URLs in parallel in one step rather than one at a time. If a game page can't be fetched, pick another or tell the user. If the environment has no web access, say the links are unverified in the hand-off rather than claiming they were checked. Give each game: exact URL, target levels for the time slot (e.g. "levels 1–8"), and a "speedy finisher" stretch option.

If no game fits a learning goal, use a short in-browser challenge instead (e.g. edit CodePen/their own project to hit a target) and say so.

Step 4 — Plan the deck

Slide sequence (typical 22–35 slides):

  1. Cover — course, unit, lesson numbers, a fun title
  2. Mission map — the schedule with minute ranges; game breaks visually distinct
  3. Class rules — a callback (e.g. "Hello!" → "World!" = hands off keyboards), "help with words, don't grab the mouse", and a points system that earns game time
  4. For each learning goal:
    • Section intro slide (eyebrow "Part N", one-sentence big idea)
    • 2–5 teaching slides, one idea each, using the lesson plan's definitions and examples
    • 1 activity slide (try-it in code, or an unplugged "act it out" for movement)
    • 1 quick-check slide (predict / point / shout-out question; answer revealed on click or in notes)
    • Game slide — game name, URL, mission (levels), time, speedy-finisher option
  5. Project kickoff (if the lesson plan has a project/lab) — requirements copied faithfully; optional labs marked optional
  6. Exit ticket — one question per learning goal; answers in speaker notes; worksheet / homework reminder

Before building, map every objective from Step 1 to at least one slide. If any objective has no slide, add one.

Step 5 — Write the content

For a class of 4–10 kids:

  • Big type, short sentences, one idea per slide. A kid should get each slide in 5 seconds.
  • Use analogies from their world (lunch lines, stickers, video games, houses).
  • Every 8–10 minutes of talking, change mode: stand-up activity, pair challenge, quiz, or game.
  • Name individuals' jobs (timer keeper, "captain") to channel energy.
  • Use pairs or two small teams, not large groups.
  • Show real code on dark code-block panels with syntax colors; keep code under ~12 lines per slide.
  • Where the slide format allows live embeds, add small live demos (e.g. a running CSS animation).

Speaker notes on every slide — the teacher reads these, not the kids. Include:

  • Which objective(s) the slide covers ("Objective 3: …")
  • What to say / ask, with expected answers
  • Common student mistakes to watch for
  • What to cut if running late
  • For game slides: how to start, set a timer, and how to stop ("Hello!" → "World!")

Footer on each slide: course name and the minute range for that segment, so the teacher always knows if they're on schedule.

Step 6 — Build the deck

Use the best slide output available in the current environment, in this order:

  1. A format the user named (PowerPoint, Google Slides) — use the matching skill.
  2. A Slides artifact type if the session offers one (list artifact types first). Follow that type's own instructions.
  3. Otherwise a .pptx via the pptx skill, or a self-contained HTML slide deck.

Design: one dark color, one light, 1–2 accents (pick from the course/belt/brand color if known); readable contrast; a rounded or friendly display font plus a clean sans for body text; a monospace font for code. Game-break slides should look different from teaching slides (e.g. dark background, big game title) so kids recognize them instantly.

Step 7 — Check before handing off

  • Every lesson-plan objective appears on at least one slide (and is labelled in notes)
  • A game follows each learning goal and practices that goal's skill
  • Every game URL was verified and is free (or flagged)
  • Segment minutes add up to the class length (60–90)
  • Project/lab requirements match the lesson plan exactly
  • Every slide has speaker notes

Anti-Patterns

  • One game per fine-grained objective (8+ games): group objectives into goals first (Step 2).
  • Listing a game URL from memory without fetching it, or assigning a Pro/paid level without flagging it.
  • A schedule whose minutes don't add up, or per-goal times that can't fit the class length.
  • Inventing objectives, or changing project requirements, that aren't in the lesson plan.
  • Text-heavy slides or code blocks over ~12 lines; answers printed on the slide instead of in notes or on click.
  • Stopping to ask about class size, length or games when sensible defaults exist (Step 1).

Step 8 — Hand off

Reply briefly: what the deck covers, the class length and why, which games were used (and any paid ones skipped), any assumptions, and which segment is the buffer to cut if the class runs long.

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

Related Skills