Building Interactive Rise Blocks with Claude Code
A real session, start to finish. A designer wants a knowledge check for a forklift safety module and has about an hour to get it done.
Read it for rhythm rather than detail. Halfway through, something goes wrong that is worth stopping on.
Designer. I need a knowledge check for my forklift safety module. One question, four options, instant feedback. It has to survive the Rise iframe.
Claude. Before I write anything, here is my plan: one self contained HTML file with no build step, your brand tokens inlined, height posted to the parent so the iframe can grow, a keyboard operable radiogroup with visible focus, and a Try again control. Shall I proceed with your question content?
Designer. Yes. Stem: what should you do before raising a loaded fork? Correct: check overhead clearance. Wrong: sound the horn, set the parking brake, lower the mast. Feedback for each option is in my notes file.
Nothing has been written yet, and the whole build is already decided. That exchange cost two minutes.
Read notes.md
Wrote blocks/kc-mcq/index.html, 178 linesClaude. Done. One file: tokens inlined, the resize snippet verbatim, a radiogroup with roving focus, and a feedback line per option pulled from your notes. Open it in the harness and walk it the way a learner would.
Designer. QA pass done. Arrows move the selection, Enter submits, no scrollbar at 320 wide. One issue: my screen reader says nothing when the feedback appears.
Stop there. The block works. It looks right, it grades correctly, it survives a narrow screen, and a stakeholder would have signed it off. Something is still wrong with it.
Edited blocks/kc-mcq/index.html, 1 lineClaude. Good catch. The feedback element now carries role status and aria-live polite, so the result is announced the moment it appears. That check is on the master checklist for exactly this reason.
Designer. Confirmed, it announces now. What is left before I can put it in Rise?
Packaged dist/kc-mcq.zipClaude. That zip has index.html at its root, which is all Mighty asks for. Add a Mighty block in Rise, upload it, and give it one last walk at a narrow width. Your block passes all ten checks; it is ready to ship.
One line of code separated a block that excluded people from one that did not, and nothing on screen would ever have told you which one you had.
Claude did not open a file first. It restated the job as a list of constraints and asked permission to proceed. That exchange is cheap; a wrong block built confidently is not.
If your assistant starts writing markup before you have agreed what it is building, stop it and ask for the plan.
The stem, the correct answer, the three wrong answers and the feedback for each were all supplied by the person who knew the subject. Claude supplied structure, not knowledge.
A block invented by the model is a block you will have to fact check line by line.
Everything visible worked. Arrows moved, Enter submitted, nothing clipped at 320 pixels. What failed was invisible, and only a person running an actual screen reader would ever know.
This is why the checklist exists, and why two of the six modules here are about quality.
One zip with index.html at its root. The packaging is trivial precisely because the constraints were agreed at the start rather than retrofitted at the end.
That is the whole loop: plan, prompt with constraints, build, QA, fix, package. Six moves. The rest of this course is you running each one yourself, starting with the words you need to run them precisely.