Why this exists

The goal of this tutorial is solo authorship: by the end, each of us should be able to take a topic and produce a finished, interactive HTML deck with an LLM doing the heavy lifting. You do not need to know HTML or CSS to do this. The real skill being taught is directing the model well — and that's what llm-dev:cycle structures.

Without structure, building with an LLM tends to drift into a long, meandering chat that loses the thread. The cycle replaces that with a repeatable set of phases, so results are consistent across people and projects rather than dependent on any one person's prompting instincts.

Why plain HTML instead of PowerPoint or a hosted slide tool? The decks we build will be handed to teachers whose classrooms may have no internet. A single self-contained HTML file opens in any browser with zero dependencies — that offline guarantee is the constraint that drives most of the technical choices in this suite.

The llm-dev plugin (linked on the slide) is optional. If you use Claude Code, installing it gives you the /llm-dev:cycle command directly; otherwise you can just load the two small skill files into any LLM chat.

The six phases

The core idea behind the cycle is making decisions before committing to code. Most of the value is front-loaded: thinking through what you're building, why, and how — before a single file is written — is what prevents wasted effort and rework.

Each phase ends at a gate: the LLM pauses and you approve before it moves on. Nothing here is rigid — you can revise a phase, skip one that doesn't apply, or jump back to an earlier phase if something changes. You stay in control the whole way.

The two files that drive this (SKILL.md and phase-details.md) are short and human-readable — worth opening and skimming once. Loading them into an LLM conversation is what lets the model walk you through the phases on its own. The next slide shows what each phase leaves behind on disk.

A single iteration, unrolled

The previous slide showed the cycle as a loop, because in practice you iterate. This slide shows what one pass through that loop actually accomplishes: it takes a rough idea on the left and walks it, phase by phase, into a verified solution on the right.

The word to land on is refinement. Each phase sharpens what came before — Review captures the requirements, Brainstorm settles the concept, Research commits to a stack, Plan makes it concrete, Execute builds it, and Verify checks it back against the requirements you started with. Nothing here is a leap of faith; each step narrows the gap between intent and a working result.

The Outcome banner along the bottom is the point of the whole exercise: a solution that meets the requirements, delivers value, and is ready to use. When you finish a pass and it's not there yet, that's your signal to start another, tighter loop — which is what the next slides build toward.

Pause and resume

The phase artifacts double as save points. Because each phase writes a markdown file (and each iteration gets its own folder), you can stop after any phase — when the context window fills up, when the day ends, or when you hand off to a teammate — and a fresh session can read those files and pick up exactly where you left off.

That's what the handoff / re-entry point in the diagram represents: the loop doesn't have to run start-to-finish in a single sitting. This matters most on longer builds, where one continuous LLM conversation would otherwise lose the thread as its context fills — the written artifacts are what let the work survive a clean break and a fresh start.

An artifact for each phase

Each phase writes a short markdown file, and each pass through the loop gets its own iteration-N/ folder. Together they're a durable record of the project: what was decided, what was tried, what was verified, and why.

This matters for two practical reasons. Re-entry: if you stop and come back days later (or hand off to a teammate), reading these files rebuilds the full context fast — no need to remember the chat. Reflection: when you start a new iteration, the Review/Reflect phase reads the previous iteration's files to decide what to do next, so the cycle builds on itself instead of starting cold.

This deck was built exactly this way — its own workspace/cycle/ folder looks just like the tree on the slide. (One note: the numbered filenames here, like 1-review.md, are a small convention we're adding to keep phase order obvious; the underlying files are the same.)

Phase 1: Review / Reflect

The mindset here is narrowing, not expanding — you're eliminating options and surfacing gaps, not generating ideas yet (that's the next phase). The quality of what you load in now sets a ceiling on everything downstream: garbage in, garbage out.

A few constraints are worth pinning down explicitly every time, because they cascade through the whole build: who the audience is, how the result will be delivered, and what it has to run on. For this suite, "offline classroom on a Chromebook" is the constraint that forced vanilla HTML and ruled out anything needing a server or network.

On later iterations, this phase changes character: instead of loading fresh context, the LLM reads the previous iteration's artifacts and reflects on what worked, what didn't, and what to change — then that reflection guides the new loop.

Phase 2: Brainstorm

This phase is a dialogue, not a request. A good brainstorm has the model asking you questions and pushing back on your assumptions — not just handing you a menu of options. If your LLM isn't asking questions, prompt it to ("ask me anything you need to know first").

The output is a scoped concept with explicit boundaries: what you will build, and just as importantly, what you won't. Deliberately deciding what's out of scope (or deferred to a later iteration) is half the value here — it's what keeps a first pass achievable.

A useful technique: ask for the simplest version first, then decide what to add. For a presentation specifically, settle the narrative arc — the story you want to tell — before worrying about any individual slide. The DP explainer in Deck 2 is a good example: its eight-act story was designed here, in Brainstorm, before any HTML existed.

Phase 3: Research

Research is where you commit to how you'll build, and verify that it'll actually work — before you've sunk time into building the wrong way. An honest caution: LLMs sometimes recommend libraries that don't exist, are deprecated, or won't run in your environment. Have the model confirm its suggestions, and prefer the simplest option that meets the need.

For most of our decks this phase is short — vanilla HTML/CSS/JS, reuse the starter template, confirm nothing reaches for the network so the offline guarantee holds. It gets more involved when a build has real substance behind it.

That's why the slide calls out interactive artifacts and understanding the math/algorithms/data. If you're building something that computes or animates (a chart, a simulation, a live demo), this is the moment to make sure both you and the LLM genuinely understand the underlying logic — not just that it "looks right." In Deck 2, the DP explainer's Laplace-noise math was worked out and verified here, in Research, which is exactly why the interactive demos behaved correctly later.

Phase 4: Plan

The plan turns everything decided so far into an ordered, concrete build sequence — what gets built first, second, third. A good rule of thumb: if a single step looks like it'd take more than an hour, break it into smaller steps.

Acceptance criteria are the most important part of a plan and the part people skip. They're specific, testable conditions that define "done" — and they're exactly what the Verify phase checks against later. Write them as pass/fail statements, not vibes: "opens offline with no console errors" is a criterion; "looks good" is not.

Testing is planned here, not bolted on afterward. Make sure the plan builds in checks along the way. If you're not sure it tests enough, just ask the LLM directly — "does this plan include enough testing to be confident the build works?" Your role at the end of this phase is to actually read the plan and approve or adjust it; the LLM proposes, but you own the decision.

Phase 5: Execute

"Test early and often" is the whole lesson of this phase. Don't wait until the end to see if it works — check each piece as it lands. When something breaks, describe the problem to the LLM precisely: "this returns X, I expected Y," or "the image doesn't load." Vague reports ("it's broken") get vague fixes.

Even though the LLM writes the code, read it and ask for explanations until you understand it well enough to describe what it does. You don't need to be able to write it yourself, but you should not be shipping a black box.

In-line vs. subagent execution (the slide's trade-off): "in-line" means the LLM builds directly in your main conversation; "subagent-driven" means it spins off separate helper sessions to do chunks of work and reports back. Subagents keep your main conversation from filling up (useful for big builds), but each subagent only sees a compressed summary of the context, so it can drift from your original intent. In-line keeps full fidelity to what you discussed but uses up the conversation's memory faster. For most single decks, either is fine — don't overthink it.

Phase 6: Verify

Verify exists because Execute reports on its own work — and anything self-assessed deserves an independent check. The rule is evidence before assertions. "It works" is not verification; "I opened it offline via file://, clicked through all 12 slides, the console was clean, and the Network tab showed zero requests" is. Walk each acceptance criterion from the plan and confirm pass or fail with real evidence.

Test it the way your users actually will — for us that means the same kind of device (a Chromebook) and the same offline conditions a classroom would have. A deck that works on your fast laptop with wifi but breaks on a Chromebook with no network has not been verified.

This is also where your judgement comes in, beyond the checklist: spend real time with what you built, tell the LLM everything you like and don't like, and decide whether you're genuinely happy with it. If it falls short, you don't mark it done — you either fix it now or carry the issue into the next iteration. That decision is what kicks off another loop back at Review/Reflect.

How it feels to use it

Three things shape what using the cycle actually feels like day to day:

Gates. The model proposes and you approve at each phase boundary. In practice you'll say "next" a lot, sometimes "revise this," occasionally "skip this phase" or "go back." Not every phase deserves equal weight — a simple deck might breeze through Research in a sentence, while a complex build lingers there. You decide where to spend effort.

Iteration. Plan to go through the loop at least once, but don't let the ceremony slow you down. Real work is messier than the diagram: this very deck was built with one full cycle, then a long stretch of moving back and forth across the slides polishing copy and layout until it felt coherent. That's normal and fine — the structure is a tool, not a rule.

Parallel work. When subtasks are genuinely independent — say, summarizing five reference documents — the LLM can fan them out and work on them at once instead of one at a time. The skill will suggest this when it applies; you decide whether to take it.