Dojo

Learning Repo Generator

You are about to build a learning repo: a self-contained git repository that any coding agent can open and operate as a persistent mentor for one topic. The repo you generate is the product. After generation, you (or any other agent) will be running it — so everything you write must be executable by a cold agent with no memory of this session.

What you will produce

<topic-slug>/
├── AGENTS.md              # the mentor protocol — personalized, self-sufficient
├── CLAUDE.md              # shim: "@AGENTS.md"
├── GEMINI.md              # shim: "@AGENTS.md"
├── README.md              # what this repo is, the command table
├── .gitignore             # ignores progress/profile.md
├── curriculum/
│   ├── guide.md           # the synthesized curriculum: modules, exercises, roadmap
│   └── self-test.md       # closed-book recall question bank (module m0)
├── references/
│   └── library.md         # annotated, link-verified reference library by module
├── progress/
│   ├── progress.json      # source of truth for state (see assets/progress.schema.json)
│   ├── journal.md         # append-only daily log (starts with the generation entry)
│   └── profile.md         # interview record — gitignored, contains personal info
├── site/
│   └── index.html         # zero-dependency dashboard
└── scripts/
    └── sync.mjs           # injects progress.json into the dashboard

Non-negotiables

These principles are the point of the whole system. Never trade them away for speed, and never let a learner's preference remove them (adapt the content, not the mechanics):

1. Retrieval over re-reading. Quizzes are closed-book, recall-only, one question at a time. No multiple choice, ever.
2. Teach-back gates. A learn-item is done only when the learner explains it back causally — a mechanism, a tradeoff, or a failure mode. Restated definitions are rejected.
3. Spacing with expanding intervals. Mastered areas come back at 1 week → 3 weeks → 9 weeks. One fuzzy answer resets the clock. "Done" means scheduled, not finished.
4. Confidence calibration. The learner calls sure / likely / guess before every quiz answer. A "sure" that grades fuzzy outranks ignorance in the review queue.
5. Personal grounding. Every do-item and prove-item names the learner's real projects, contexts, or stakes from the interview. If an item would read the same for any learner, rewrite it.
6. One item at a time. The mentor never dumps a module.
7. The mentor's self-assessment is never verification. Grades are contestable with evidence, both ways.

Phase 1 — Interview

Read references/interview.md (relative to this SKILL.md) and conduct the interview: one question at a time, conversational, never a form. You are done when you can fill every field of the profile template at the bottom of that file with something concrete.

Do not skip this even if the user's request seems complete ("teach me Rust, I'm a senior Go dev" still leaves stakes, hours, horizon, and grounding unknown). If the user explicitly refuses the interview, extract what you can from the conversation, state your assumptions, and mark them in profile.md as assumptions.

Phase 2 — Research

Read references/research.md and run the deep-research pass for the topic. Output: the annotated reference library (references/library.md in the generated repo), with every link fetched and verified live — a hallucinated reference in a learning repo poisons months of study. This phase should use real web search/fetch tools; if none are available, tell the user up front that the library will be built from your training knowledge with links unverified, mark every such link (unverified), and continue.

Phase 3 — Synthesis

Read references/curriculum.md and synthesize:

1. curriculum/guide.md — modules ordered by leverage, each with why it matters, learn-items (pointing into the library), do-items (grounded in the learner's real context), and one prove-item (a verifiable or public artifact). Plus the roadmap: periods with themes and milestones, honest about total weeks vs. available hours.
2. curriculum/self-test.md — the m0 recall-audit bank: 8–15 areas over things the learner will use constantly, 3–6 mechanism-probing questions each, with a reading pointer per area.
3. progress/progress.json — every item status: "todo"; every module status: "todo" except m0, any ongoing module, and the first topic module, which start in_progress (all active from day one; current_module is still "m1", never m0); the first period in_progress, the rest upcoming. Match assets/progress.schema.json.
4. The daily drill: one 90-second daily micro-practice for this domain, gradable crisp/fuzzy/blank (the curriculum reference explains how to design it).

Phase 4 — Scaffold

1. Ask where to create the repo if not obvious (default: a sibling directory of the current project, named after the topic slug). If the target directory already exists and is non-empty, stop and ask: a new path, update the existing dojo in place (never regenerate progress/ — study history must survive), or explicit overwrite. Never clobber silently.
2. Copy the templates from this skill's assets/ directory and fill every placeholder:

Placeholder	Filled with
{{TOPIC}}	topic name, e.g. "Rust", "watercolor painting"
{{TOPIC_TITLE}}	display title for README/dashboard
{{TOPIC_SLUG}}	kebab-case slug — used as the repo directory name only; appears in no template file
{{LEARNER_SUMMARY}}	1–2 sentences: who this learner is, their goal, their horizon
{{HIGH_STAKES_CONTEXT}}	where a mistake costs this learner most (their real context)
{{DAILY_DRILL}}	the 90-second daily micro-practice you designed in Phase 3
{{MODULE_ORDER}}	the module sequence with any optional modules noted
{{TAGLINE}}	one line describing the curriculum's promise
{{GENERATED_DATE}}	today, YYYY-MM-DD

• assets/AGENTS.md.tmpl → AGENTS.md
• assets/README.md.tmpl → README.md
• assets/dashboard.html.tmpl → site/index.html
• assets/sync.mjs → scripts/sync.mjs (verbatim, no placeholders)

3. Write the shims — CLAUDE.md and GEMINI.md get identical content:

   # {{TOPIC_TITLE}} — Learning Repo
   
   The mentor protocol lives in **`AGENTS.md`**. Follow it exactly.
   
   @AGENTS.md
   

   and .gitignore containing the single line progress/profile.md.

4. Write progress/profile.md (the interview record), progress/journal.md (first entry: generation date + one line), and the Phase-3 outputs.

5. Validate: run node scripts/sync.mjs inside the new repo — it must print dashboard synced. If node is unavailable, say so and leave the dashboard unsynced rather than hand-editing the data island.

6. git init, git add -A, commit: init: generate <topic> learning repo.

7. Hand off with the command table (from the generated README): what should I learn today?, done <item>, quiz me, weekly review, audit me, podcast pack <item>, update my profile — and remind the learner the repo contains a gitignored personal profile, so a public fork should be scrubbed first.

Quality gates — check before you finish

• Zero unfilled {{placeholders}} anywhere in the generated repo (grep -rn "{{" <repo> is empty).
• Every do-item and prove-item names the learner's real context — no item that any learner could receive.
• Every reference link was fetched live during Phase 2 (or is marked unverified).
• node scripts/sync.mjs runs clean.
• The AGENTS.md protocol sections are intact: daily check-in, teach-back gate, spaced re-checks, confidence calibration, interleaving, weekly review, monthly audit. If you trimmed one to save tokens, restore it.
• Total module-weeks vs. the learner's hours/week is stated honestly in the roadmap, with designated slack.