◆ Convex Stack Bootcamp
Plan Cheatsheet Gotchas

convex-bootcamp — teach a fast-moving stack without teaching stale syntax

nameconvex-bootcamp
descriptionTeach the Convex stack (or any fast-moving framework) as a checkpointed multi-day bootcamp - verify the current API against live docs first, build one lesson artifact per day with story anchors, worked code, deliberate-bug drills and blind checkpoints, gate progress on the checkpoint, track state in memory. Trigger - /convex-bootcamp [day N | new <topic> | status | verify]

This skill documents the process behind the 7-day Convex bootcamp in curriculum/. It generalises to any framework that ships faster than its tutorials — which is most of them.

#Invocation

State lives in a project memory file (e.g. project_convex_bootcamp.md). ALWAYS read it first: it holds the plan, artifact URLs, the verified-API snapshot with its date, and which checkpoints passed. Update it whenever a day completes or a verified fact changes.

#The premise this skill exists for

A fast-moving framework's tutorials are a snapshot; its docs are the moving target. For Convex specifically, the document API moved from ctx.db.get(id) to ctx.db.get("tasks", id), which silently invalidates the syntax in essentially every video tutorial published before it. A bootcamp that teaches from model memory will teach that error confidently.

So Phase 0 is not optional and is not research flavour. It is the thing that makes the output trustworthy.

#Phase 0 — Verify the API against live docs (ALWAYS FIRST)

Before writing one line of teaching content, WebFetch the canonical docs and quote the current syntax. For Convex, minimum set:

Rules:

#Phase 1 — Curate sources

Search for videos and posts. Then:

  1. Resolve every URL. Only link URLs that came back from a real search. Never reconstruct a video ID from memory — a plausible-looking wrong ID is worse than no link.
  2. Date every source and check that date against Phase 0. A pre-change tutorial is not discarded — it is labelled: "watch for workflow, take syntax from the cheatsheet."
  3. One primary per concept. A second video on the same topic is procrastination with good posture. Add an alternative only when the teaching angle genuinely differs (vendor walkthrough vs. working developer).
  4. Prefer sources with a companion repo so the learner can diff.
  5. Note durations only if the title or snippet states them. Publish dates are more useful anyway, because they predict staleness.

#Phase 2 — The plan

Order by dependency, not by the docs' table of contents. Two rules that do the work:

Every day gets: one idea, one video maximum, a build task ending in running software, and a blind checkpoint. Publish the plan as an HTML artifact; save the URL to memory.

#Phase 3 — Per-day lesson (the core loop)

One self-contained lesson. Anatomy, in order:

  1. Header — the one idea as a single sentence the whole day hangs on; time; the video; what ships by the end.
  2. Numbered sections (4–7), each with this rhythm:
    • the concept in one sentence, then the layers
    • story box — a concrete anchor, one paragraph, vivid. The library with no catalogue (indexes). The photograph vs the window (fetchQuery vs preloadQuery). The runner sent into a building three times (sequential runQuery). This is what survives when the reader is tired and debugging at 1am.
    • verified code from Phase 0 — never from memory
    • where relevant, an explicit "the videos show X, current is Y" callout
    • quick check — one question, answer hidden in <details>. Number them across the page. Prefer questions phrased as symptoms ("renders right, never updates — where do you look?") over definitions; that is the form the knowledge is actually used in.
  3. Build task — ends with running software, and includes at least one deliberate-bug drill: instructions to write the wrong version, observe the failure, then fix it. Rationale: a bug you caused yourself is worth ten warnings you read. Best candidates are failures that are silent (.filter() at small scale, fetchQuery freezing) or scary (deleting another user's row from the console).
  4. Checkpoint — 5 blind questions, no answers on the page. Passing = day banked.
  5. Cheat strip — a monospace block of the day's whole API surface, copy-pasteable.
  6. Tomorrow — one sentence of narrative pull, naming the tension the next day resolves.

#Progression gating

Do not advance on request alone. Ask for checkpoint answers.

A learner who wants to skip ahead is asking you to make the later days useless. Be direct about the tradeoff rather than quietly complying or quietly refusing.

#Honesty rules

#Design rules (artifacts)

#Publishing & durability

#Adapting this to another stack

The Convex specifics are an instance; the process is the point. To retarget:

  1. Phase 0 doc list → that framework's canonical reference pages.
  2. Find its drift line — the API change that invalidates existing tutorials. Every fast-moving framework has one, and it is the highest-value thing you can tell a learner. (Convex: table-name-first document API. Next.js: App Router vs Pages.)
  3. Reorder days by what is expensive to reverse in that stack.
  4. Keep everything else: story anchors, deliberate-bug drills, blind checkpoints, gating, and the honesty rules.