The flashcard primitive is checked into the repo. That is why your prototype is shape-stable.

The pages that rank for this query are not for you

Run the search yourself. The first page is FlashRecall, Brainscape, Active Recall (the brand), Anki, RemNote, Noji, Gizmo, Memo. All polished products selling a deck library or an AI flashcard generator. None of them write a word about how to prototype the surface of a flashcard app, because they sell the answer, not the workshop. If you typed the word prototype into your query, you are not in the market for any of those tools. You are trying to build one, probably to test a teaching idea, probably for a specific subject that no off-the-shelf deck nails, and probably before committing engineering time to it.

The honest stack for that move has three layers. The first is a clickable surface a real learner can try in five minutes. The second is the scheduling logic (Leitner, SM-2, FSRS) you wire in once the surface is settled. The third is real persistence and an account system, which you only need when somebody asks where their progress went. mk0r is built for the first layer, deliberately. You can prototype layer one in a single afternoon, hand the URL to a friend studying for the MCAT, watch them try to use it, and rip the layout apart twice before lunch.

The committed primitive, line by line

Most AI app makers will draw a flashcard differently every time you ask, because the layout is being invented per request. mk0r is anchored to a specific reference design that lives in the homepage source. The agent has read it. When the prompt mentions flashcards, study cards, or recall, this is the visual vocabulary it reaches for.

// src/components/landing-content.tsx:243 (excerpt)
function StudyCardsMockup() {
  return (
    <div className="w-full h-full bg-blue-50 p-4 flex flex-col items-center justify-center gap-3">
      <div className="text-[10px] font-bold text-blue-900 self-start">JavaScript Basics</div>
      <div className="bg-white rounded-xl p-4 shadow-md w-full text-center border border-blue-100">
        <div className="text-[8px] text-blue-400 mb-2">Question 3 of 20</div>
        <div className="text-[11px] font-medium text-zinc-800 leading-relaxed">
          What is the difference between
          <code className="text-blue-600 bg-blue-50 px-1 rounded">let</code> and
          <code className="text-blue-600 bg-blue-50 px-1 rounded">const</code>?
        </div>
      </div>
      <div className="flex gap-2 w-full">
        <div className="flex-1 bg-blue-500 text-white rounded-lg py-1.5 text-center">
          Show Answer
        </div>
        <div className="flex-1 bg-white text-blue-600 border border-blue-200 rounded-lg py-1.5 text-center">
          Skip
        </div>
      </div>
      <div className="flex gap-1 self-start">
        <div className="w-8 h-1 rounded-full bg-blue-400"/>
        <div className="w-8 h-1 rounded-full bg-blue-400"/>
        <div className="w-8 h-1 rounded-full bg-blue-200"/>
        <div className="w-8 h-1 rounded-full bg-blue-200"/>
      </div>
    </div>
  );
}

Five things to notice. The page background is bg-blue-50, the card is white over border-blue-100. The retrieval gate is the bg-blue-500 Show Answer button paired with a Skip outline. The pagination is exactly four w-8 h-1 rounded-full segments, two filled (bg-blue-400) and two empty (bg-blue-200) in the snapshot. The deck label is in the corner, not the center. None of those are accidents. They are the design budget the agent has agreed to spend before it touches your prompt.

A vague prompt versus the seeded one

The prompt you type matters less than which primitive it lands in. The seeded chip on the homepage routes you straight at the Study Cards primitive. A vague free-form prompt about quizzes can land you on a multiple-choice game pattern instead. Same word, different shape.

What active recall actually means in the UI

Active recall is not a layout. It is the discipline of forcing retrieval before revelation. In a UI that respects it, the answer is unreachable until the learner has had to think. Re-reading is the failure mode every well-designed flashcard app is built to prevent. The session loop has five beats; the first draft from mk0r covers four of them, and the fifth is one prompt away.

The first three beats are non-negotiable. Without them you do not have an active-recall app, you have a slideshow. The fourth beat (self-rating) is what separates a session from a study system: ratings let you reorder the deck and bring weak cards back sooner. The fifth beat (the pager) is what gives the session a shape, so the learner sees an end and feels rewarded for finishing.

Variants you can ask for, without leaving the primitive

Subject does not have to disturb the layout. The Show Answer gate, the centered card, and the pager all hold for any deck. What you change is the content slot on the front and the back. Six common shapes that work without leaving the committed primitive:

The honest gap: scheduling is not in the first draft

Anki, FlashRecall, and RemNote have decades of compound iteration on the scheduling algorithm. SM-2 (the original SuperMemo algorithm), the more recent FSRS, the simpler Leitner box system: these are the engines that decide which card you see next. mk0r will not draft a real spaced-repetition scheduler in your first prompt, and you should not pretend it did. What you have after that first draft is the surface a learner can use, with mock state and an in-order deck.

The clean way to upgrade is to ask in a second prompt. Start with a Leitner-style loop because it is the cheapest honest scheduling: "Replace Skip with four self-rating buttons (Again, Hard, Good, Easy). Cards I rate Again come back at the end of this session. Cards I rate Easy do not come back. Persist ratings to localStorage." You will get a working session-level scheduler that survives page reloads. When that stops being enough (probably when somebody studies for two weeks and asks where their schedule lives), wire in a real SM-2 or FSRS implementation. By that point your operator UI is settled, which is the entire reason you prototyped the surface first.

The mistake is the inverse: building a scheduler before you know what the card looks like, what the rating buttons say, or whether your learners will tolerate self-rating at all. Most people will not. Watch one MCAT student look annoyed at the Hard button, and the schedule you spent three days building is the wrong one.

One concrete prompt to start

If you want a starting point that consistently lands in the Study Cards primitive instead of the multiple-choice quiz pattern, paste this verbatim and iterate:

A flashcard app for active recall study.
Front: a question or term, centered on the card.
Back: the answer, revealed only after the user clicks Show Answer.
Header chip: deck name (top left), Question N of total (above the question).
Card: white, soft shadow, rounded, centered on a soft blue page.
Below the card: Show Answer (filled blue) and Skip (white outline) side by side.
Bottom: a four-segment progress bar that fills as the session advances.
Session: 20 cards, in order, no scheduling yet. End screen says "Done" with a Restart button.
Style: clean, generous whitespace, blue accent, no emoji, mobile-first.

The prompt is opinionated on purpose. It names the primitive, names the retrieval gate, and forbids the multiple-choice fallback. The agent will draft the deck with mock content (probably JavaScript basics, because that is what the reference uses) and you swap the deck in the next turn. If you want a kanji deck, say so on prompt two. If you want self-rating, say so on prompt three. The layout will hold while the content slots flex.

Frequently asked questions