Standard → Slides
“Type a standard, get a teachable deck.”
Illustrative team — open seats are real invitations.
- Build mode
- assemble on blocks
- Built on
- @k12vls/marp-slides + @k12vls/cce-handbook
- Output
- slide deck (present or print)
The brief
What it is, and why a teacher says yes
The pain point
Building a clean, aligned teaching deck per standard is hours of work — slide-by-slide, every unit, often the night before. The polish-vs-time tradeoff is one teachers feel constantly.
What it does
Teacher enters a Common Core code → out comes a classroom-ready Marp deck (worked examples + a check-for-understanding) to present on screen or print as a handout.
Why it's adoptable
It slots directly into how teachers already plan a lesson — “deck per standard” is the existing unit of work, so there's nothing new to learn. And because Marp decks export to both HTML and PDF, the printable fallback means no projector dependency: the same artifact works on screen or on paper.
What the teacher receives — a synthetic example
If 3 pens cost $6, what's the rate per pen?
Ratio table — scale 3:6 up and down
Unit rate: $2 per pen
5 pens cost…? Quick check for understanding
The same deck presents on a projector or prints as a handout — no screen required.
Illustrative mockup. All example data is synthetic — no real student data.
The graduation signal
“Built” doesn't count — real, repeated use does. Here's the ladder.
- 1
Pilot
A teacher generates a deck for the next standard they teach, edits it lightly, and actually uses it in class. (Teacher-side.)
- 2
Active use
The teacher comes back for the next unit's deck, and the one after — generated decks become part of how they plan, not a one-time novelty. (Teacher-side.)
- 3
Sustained MAU
A teacher reaching for generated decks across multiple units as a recurring part of their planning rhythm. Students never log in, so this is teacher-side MAU; the student participants who see the decks are counted separately, not as logins — estimated from classes served. (Teacher-side MAU.)
For the AI Builder
How you build it
The honest build path — what it builds on, the rough assembly, the data flow, and the gaps the blocks don't give you for free.
Blocks it builds on
- @k12vls/marp-slides — the deck layer. Exports the slide types (SlideData, SlideMetadata, RenderOptions, ParsedSlides), a K12 theme (K12_THEME_NAME, k12ThemeCSS, writeK12ThemeFile), and rendering/export functions (renderSlides / renderSlidesFromContent via @k12vls/marp-slides/render; exportSlides for PNG via Marp CLI). Decks are Marp markdown; the package themes and renders them. The themed deck is the artifact.
- @k12vls/cce-handbook — the Curriculum Content Engine handbook: schemas (briefSchema, taskSetSchema, taskItemSchema, the Brief type) and docs that define how to shape standard-aligned instructional content. Use it to structure what goes on the slides so the deck is genuinely aligned, not just themed.
Rough assembly
- 1Pick — the Common Core code, plus the deck's shaping parameters, mapped onto the cce-handbook Brief shape: optional grade/context (context, parameters.target_grade), deck length / time available via parameters.duration_minutes (a real Brief field — fit a ~30 vs ~50 min block), and lesson emphasis (worked-examples-heavy vs. practice-heavy) carried on content_properties / parameters.learning_objectives and reinforced in the generation prompt.
- 2Generate — an LLM call that, guided by the cce-handbook brief/task structure (including duration_minutes and the emphasis signal), drafts the deck content as Marp markdown: a hook slide, worked examples and/or practice per the emphasis, and a check-for-understanding — sized to the requested length.
- 3Theme — apply the K12 theme (writeK12ThemeFile() / k12ThemeCSS) so every deck looks consistent.
- 4Render — renderSlidesFromContent(...) to HTML for on-screen presentation; or export to PDF (see caveat) for the printable handout.
- 5Output — hand the teacher the deck to present, and the PDF to print.
The data flow
cce-handbook schema.writeK12ThemeFile).renderSlidesFromContent → HTML → present on projector.Caveats — the honest gaps
Scope boundaries
This generates a deck per standard — it is not an authoring suite or an LMS: it doesn't store decks, version a teacher's library, track which standards were taught, or ingest student work to “personalize” the slides. The moment it saves student-specific content or logins, it leaves the “no student data” profile that keeps it Lowest.
For the AI Champion
Taking it to a teacher
The adoption kit — the pitch, the pain it lands on, the objections you'll hear, and what a real pilot looks like.
The 30-second pitch
“You spend hours building a deck for each standard. Type the standard code and this drafts the whole thing — a hook, worked examples, and a quick check — already styled and ready to present. No projector? Print it as a handout; it's the same deck either way.”
The pain it lands on
The night-before deck build — opening a blank slide template for the standard you're teaching tomorrow and assembling it example by example.
Objections → responses
“Is it actually aligned, or just generic?”
It's shaped from the Common Core code you type, using the content-engine structure that defines what an aligned lesson covers — then you review before you teach.
“I don't always have a working projector.”
The deck exports to PDF too, so you print it as a handout. Same content, no screen required.
“Where does my students' data go?”
Nowhere. You type a standard code, not student data; the tool produces a deck. No student logs in, nothing about a student is stored.
What a pilot looks like
The teacher generates a deck for the next standard they teach, edits lightly, and uses it. Success = they come back for the next unit's deck, and the one after — generated decks become part of how they plan, not a one-time novelty.
The bar
Safeguarding & the pilot gate
The minimum conditions before any classroom use, and the data posture that keeps the solution honest.
Pilot gate
- Sponsoring adult
- The classroom teacher (or, in another venue, the school / after-school / community lead serving the learners) — required program-wide.
- Minimum version
- A teacher can type a real Common Core code and get back a themed deck — hook, worked examples, check-for-understanding — that both presents as HTML and exports as a PDF handout. Not a screenshot demo: the actual generate-theme-render path running end to end.
- Pilot setting
- A real class period (present on the projector) or the same content printed as a handout when no projector is available.
- Success evidence
- The teacher edits the deck lightly and actually uses it in class (mirrors the Pilot rung — first real use; coming back for the next standard's deck is the Active use rung, not the pilot bar).
- Stop condition
- Immediate — at review the teacher judges the deck pedagogically wrong, off-standard, or not classroom-ready and won't present it tomorrow. Over the pilot — the generated pedagogy is consistently wrong or off-standard enough that reviewing/fixing a deck costs more than building one from scratch, or the generation step begins ingesting anything beyond a standard code.
Safeguarding
Lowest loadData touched
No student data — the teacher-selected Common Core code (plus optional grade/context) shapes the deck and passes through the LLM generation call; output is a deck. No student login, no PII, no uploads, no completed work. No student data is persisted. The generated deck/PDF itself is of course an artifact — the teacher may download or save it as ordinary lesson material — but it contains no student data, so saving it carries no data risk.
Checklist
- Sponsoring teacher ✓ (required program-wide).
- Data-handling review n/a (no student data).
- Consent n/a.
- Content review applicable — because the slides are LLM-generated, the sponsoring teacher must read the deck before presenting it. This is not a data-handling item (the deck touches no student data either way) but it is still a required classroom safeguarding/quality gate, because students will see generated instructional content: it must be reviewed before classroom use.
One thing to verify
That the generation step is constrained to lesson content (a standard → a deck) and never ingests student work or names — so the “no student data” claim holds, and the teacher's content review is the only gate the deck must pass.
What would change the load
The current Lowest profile holds only as long as input is a standard code and output is a generic, student-agnostic deck. Saving generic decks (a teacher's deck library, versioning) is product-scope creep, not a data trigger — a generic deck holds no student data wherever it's stored. What does move the safeguarding load is tying anything to student identity: decks associated with a class roster, usage history of who was taught what, student logins, ingesting student work to tailor the examples, personalized feedback, or parent contact — each introduces a student-data class and pushes this above Lowest, at which point the data-handling and consent items, currently n/a, come back into play.
Want to build Standard → Slides?
Tell us this starter caught your eye — or browse the others first.