teach
Structured multi-session teaching — missions, lessons, retrieval practice.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Structured multi-session teaching — missions, lessons, retrieval practice.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | teach |
| description | Structured multi-session teaching — missions, lessons, retrieval practice. |
| disable-model-invocation | true |
| argument-hint | What would you like to learn about? |
The user wants to learn something over multiple sessions. This is stateful — progress lives in files in a teaching workspace, not in chat memory alone.
Default location: teach/<topic-slug>/ at the repo root (never inside src/ package code). User may choose another directory — treat that directory as the workspace root.
Git: workspaces are personal by default — do not commit teach/** unless the user explicitly wants shared onboarding material in the repo (add it to .gitignore otherwise).
State files at workspace root:
| File / folder | Purpose |
|---|---|
MISSION.md | Why they're learning — grounds every lesson. MISSION-FORMAT.md |
GLOSSARY.md | Canonical terms once understood. GLOSSARY-FORMAT.md |
RESOURCES.md | High-trust knowledge + community sources. RESOURCES-FORMAT.md |
NOTES.md | User teaching preferences, scratchpad |
./learning-records/*.md | Decision-grade insights (ADR-shaped). LEARNING-RECORD-FORMAT.md |
./lessons/*.html | Primary teaching unit — one scoped win per file (0001-slug.html, increment) |
./reference/*.html | Compressed cheat sheets for revisit (syntax, flows, glossaries) |
./assets/* | Reusable lesson components (stylesheet first) |
Create directories lazily when first needed.
When the mission is this codebase (index, recipes, schema, parsers, adapters, agents init, rules/skills):
codemap (the structural SQLite index) for symbol-shaped questions before Grep/Read; read src/, docs/, .agents/ for narrative.docs/glossary.md and docs/architecture.md; align lesson terms (FileRow vs files table, recipe vs query, schema vs DDL, hub vs barrel)..agents/skills/<name>/SKILL.md or concrete src/ paths; use codemap query results for symbol references.AGENTS.md, relevant skills, docs/architecture.md, docs/glossary.md) alongside external sources.General topics (Rust, yoga, etc.): never trust parametric knowledge until RESOURCES.md is populated.
Three layers: Knowledge (trusted resources) · Skills (interactive lessons + feedback loops) · Wisdom (communities, real-world practice).
Split fluency (in-session recall) vs storage strength (long-term retention). Design for storage: retrieval practice, spacing, interleaving (skills only).
MISSION.md.open ./lessons/0001-….html on macOS).Before authoring: read ./assets/; reuse is default. Shared stylesheet is the first component every workspace earns — every lesson links it so the course looks consistent. When a lesson needs something reusable (quiz widget, diagram helper), add it to ./assets/ and link — never inline code a second lesson would duplicate.
If MISSION.md is empty or vague, interview the user (one question at a time; recommend an answer) before writing lessons. Revise mission only after user confirms — record shift in a learning record.
Read learning-records/, mission, and glossary → teach the next thing that challenges just enough. User may name a topic directly.
Lessons target a skill; include only knowledge required for it. Knowledge from RESOURCES.md with citations. Skills via quizzes / guided steps with tight feedback loops. Quiz options: equal word count when possible (no formatting clues).
For questions needing real-world judgment, answer then point to communities in RESOURCES.md. Respect if user opts out of communities — note in RESOURCES.md.
Compress lesson essence into ./reference/*.html for revisit. Glossaries live in GLOSSARY.md at workspace root — adhere to terms in all lessons.
grillinggrill-with-docsdomain-modelingVoice, tone, and format for the public Codemap docs (`apps/docs`, built with Blume). Use when authoring or editing apps/docs prose — landing, guides, concepts, recipes, reference, generated API — or deciding headline grammar, benefit framing, peer framing, or anti-pitch wording.
Repo-wide docs framework — what `docs/`, `docs/plans/`, `docs/research/`, `.agents/`, or any other doc-bearing surface in this repo looks like, what lifecycle each doc follows, and how to keep cross-references intact when slimming or moving content. Use when authoring or editing any `docs/**`, `docs/plans/**`, `docs/research/**`, `.agents/rules/**`, `.agents/skills/**`, or any new doc-bearing folder. Defines the lifecycle types (Reference / Roadmap / Plan / Audit / Research), the existence test every doc must pass, the closing-state lifecycles (delete + lift; never "Slim & keep in plans/"), the substrate variants (single `audit.md` vs `audits/<topic>.md`; conditional `glossary.md`), the surface tiers (repo-wide / per-tooling-area), and the cross-reference preservation discipline (grep before slim; preserve rule numbers cited from source). The Tier-2 priming layer at `.agents/rules/docs-governance.md` cites this skill and extends with codemap-specific bits only.
Bring a branch to pristine, maximum production readiness without changing PR intent — spawn parallel Task subagents (never inline review), fix in-bounds findings, loop autonomously until clean or pass cap, then report once. Use after a tracer-bullet commit (lite), before PR is done (full), on "harden", "harden-pr", "pristine", "review until clean", "production-ready pass", or "harden-pr reconcile". Invoking this skill authorizes one harden commit at cycle end. NEVER stop mid-loop to ask about commits, babysit, or the next pass. NEVER redesign the feature or change observable runtime behavior.
The product north-star — four Codemap tenets (structural over semantic, predicate-as-API, local-first / agent-native surfaces, honest scope). Use when making a design, API, or architecture decision, evaluating a trade-off, justifying a feature, or writing/reviewing a docs/plans entry.
Keep apps/docs in sync with merged product changes. On each run, audit recently merged PRs against docs content, update only drifted pages, regenerate API MDX when public exports/JSDoc drifted, verify with blume validate/check/build/audit, and open or update a docs/* PR — or report a clean no-op.
Delta-driven dependency upgrades — a script gathers the evidence, you read the artifact and judge. Use when the user asks to upgrade, bump, or CVE-audit dependencies.