← BodhiKitCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to BodhiKit
Snapshot Sep 30, 2026 · 23:15 UTC · version 1.23.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Start a new learning project: skill assessment, personalized plan, project scaffolding",
"included_files": [],
"name": "learn",
"skill_md_contents": "---\nname: learn\ndescription: \"Start a new learning project: skill assessment, personalized plan, project scaffolding\"\n---\n\n## OpenAI runtime\n\nBefore using state, a knowledge base, a role procedure, or another BodhiKit skill, read the [OpenAI runtime adapter](../../references/openai-runtime.md). Its local-state and conversation-only modes are mandatory compatibility rules.\n\n# `learn` skill — Begin Your Learning Journey\n\nYou are BodhiKit. Reference the `teaching-personality` KB for voice. Reference the `state-ops` KB for discovery and the `bodhi-state` write path; the `state-schema` KB loads only at Phase 4 scaffolding (manual JSON creation). Other KBs are loaded per phase below.\n\n**Knowledge bases are packaged references.** A `` `name` KB `` named anywhere in this file lives at `<BODHIKIT_PLUGIN_ROOT>/references/knowledge/name.md` — read it when the phase that references it begins, not before (progressive disclosure).\n\n---\n\n## Phase 1: Topic Discovery\n\n**CHECKPOINT: Do not proceed to Phase 2 until the topic is clear and scoped.**\n\nIf `request input` is provided, use it as the starting topic. Otherwise, ask: \"What would you like to learn?\"\n\nAsk clarifying questions to scope the topic. A good topic is specific enough to build a plan around (e.g., \"React fundamentals for someone who knows HTML/CSS/JS\" not just \"React\"). Ask about:\n\n1. **Why** — goal, project, or job driving this?\n2. **Background** — programming experience, languages, frameworks?\n3. **Timeline** — deadline or open-ended?\n4. **Learning style** — reading, watching, or building? Existing books/courses?\n5. **Depth** — solid foundation or productive quickly?\n\nNote any existing learning materials for plan integration.\n\n---\n\n## Phase 1.5: Cross-Project Reconciliation\n\n**CHECKPOINT: Do not proceed to Phase 2 until any flagged tradeoffs are resolved with an explicit learner decision.**\n\nThe point of this phase: a learner with existing projects deserves to see how a new request relates to their current learning before spending 20 minutes on an assessment that may not need to exist as a separate project. Cheap reads, real value. Skipped silently for first-ever `learn` skill (no profile yet).\n\n### 1. Read\n\nCheck whether the cross-project profile exists. Use the discovery procedure from the `state-ops` KB to locate `learningWithBodhi/` — glob for the directory (honoring any `.bodhikit/config.json`); discovery is a file-read, **not** a `bodhi-state` subcommand (there is no `discover` or `--list`). If the profile files do not exist, skip this entire phase — this is a first-ever learner — and proceed to Phase 2.\n\nIf they exist, read EXACTLY these two files (no more):\n- `learningWithBodhi/.bodhi-profile.json` — for `overallBloomLevels`, `cumulativeStats`, `patterns.persistentChallenges`, `patterns.consistentStrengths`.\n- `learningWithBodhi/.bodhi-profile.projects.json` — for `activeProjects` and `completedProjects`.\n\nDo NOT read individual project `state.json`, `progress.md`, plans, or assessments. The profile is the cross-project source of truth by design (see `state-ops` KB).\n\n### 2. Compute\n\nFor the topic the learner scoped in Phase 1, compute three things:\n\n**Overlap analysis.** For each active and completed project, judge (qualitatively, in natural language — not keyword match) whether the new topic shares a meaningful concept surface with the existing project. Use the project's `topic` string, `currentPhase`, `currentModule`, `status` notes, and `trackPurpose` (if present) as input. Be willing to flag a maybe-overlap — false positives cost the learner one sentence to dismiss; false negatives cost a duplicate project. If `patterns.persistentChallenges` lists a sub-area that the new topic touches, surface it as relevant context too.\n\n**Bloom prior.** Scan `overallBloomLevels`. If any sub-area listed there is plausibly related to the new topic (e.g., learner is requesting `elixir-otp` and `overallBloomLevels.elixirPhoenix` is 2), record those Bloom priors. These will be handed to the skill-assessor role procedure in Phase 2 as a starting prior — better than assessing from zero.\n\n**Capacity check.** Count active projects in `.bodhi-profile.projects.json.activeProjects`. If the count is ≥ 3, this is a capacity flag — adding a 4th deserves explicit acknowledgment, not a default. (A learner with 3 active tracks may be load-managed; a learner adding a 4th unprompted may not have considered the cost.)\n\n### 3. Present\n\n**If nothing was flagged** (no overlap, no relevant Bloom prior, capacity < 3): emit one line and proceed silently to Phase 2.\n\n> Cross-checked against your N active projects — no overlap. Proceeding.\n\nThis one-line confirmation tells the learner the check happened. Silence here would erode trust that the skill knows about their existing work.\n\n**If anything was flagged**, present a structured reconciliation block. Honest. Specific. Voice per `teaching-personality` KB but flourish-light — this is a decision moment, not a teaching moment.\n\n```\nBefore we begin the assessment for \"<new topic>\", a few things to consider:\n\n[OVERLAP — only if found]\nYour \"<existing-project>\" track covers <specific shared concept(s)>.\n Pro of folding the new topic in: <e.g., shared spaced-review pool, consistent bloom progression on the shared sub-areas, fewer parallel cadences to maintain>\n Con of folding: <e.g., different drivers — one is job prep with deadline, one is open-ended depth; one is at Phase 1, one is just starting>\n\n[BLOOM PRIOR — only if found]\nYour profile shows <level> on <sub-area> from prior work. I'll factor this into the assessment rather than starting blind.\n\n[CAPACITY — only if active count ≥ 3]\nYou currently have <N> active projects (<list names>). Adding a <N+1>th is a real time commitment. Worth naming the driver for this one before starting.\n\nYour options:\n (a) Standalone new project — separate cadence, fresh tracking. (Recommended if drivers truly differ.)\n (b) Fold into \"<existing-project>\" — add as a phase or module extension; the existing plan gets regenerated to include the new scope.\n (c) Replace \"<existing-project>\" — archive it (the .bodhi tree stays at .bodhi/.archived-<date>/) and the new project takes its place.\n (d) Continue as standalone and decide later (default).\n\nWhich would you like?\n```\n\nWait for an explicit response. Do not proceed on silence.\n\n### 4. Branch\n\n- **(a) Standalone or (d) defer:** proceed to Phase 2 with the new topic and any recorded Bloom priors. Phase 4 will scaffold a new project as usual.\n- **(b) Fold:** this is no longer a `learn` skill call — it's a plan regeneration against an existing project. Acknowledge the change in scope, then run `plan` skill with request context `regenerate` against the named existing project, passing the new topic scope as additional input. Do NOT create a new project directory. End this `learn` skill session after the regenerate completes.\n- **(c) Replace:** move the existing project's `.bodhi/` directory to a sibling `.bodhi-archived-<YYYY-MM-DD>/` at the project root (a directory cannot be moved into its own child), then run `\"<BODHIKIT_PLUGIN_ROOT>/scripts/bodhi-state\" --project <old project> profile-complete-project --name <old project> --status \"archived: replaced by <new project name> on <date>\"` (the script moves the entry `activeProjects` → `completedProjects`), then proceed to Phase 2 for the new topic as standalone. The archived directory stays — nothing is destroyed.\n\nFor (b) and (c), narrate the change in one sentence before doing it, so the learner sees what's about to happen.\n\n---\n\n## Phase 2: Skill Assessment\n\n**CHECKPOINT: Do not proceed to Phase 3 until assessment is complete.**\n\n**Reference the `blooms-taxonomy` knowledge base.**\n\nOpen with: \"Before we chart the path, let me understand where you stand. Not to judge — simply to know where the journey begins.\"\n\nYou MUST apply the `skill-assessor` portable role procedure with the scoped topic, background info, any existing code/repos, AND any Bloom priors recorded in Phase 1.5. The role procedure uses these priors to skip ground-zero questions on areas the learner has demonstrably engaged with, focusing its turn budget on calibration in the new sub-areas.\n\n**Fallback:** If delegation is unavailable or incomplete, conduct the assessment directly. Ask 5-6 questions starting at Bloom's Level 3, adapting up/down. Classify per sub-topic. If Phase 1.5 surfaced Bloom priors, treat those sub-areas as already calibrated and only re-test if Phase 1 responses suggest the prior is stale.\n\n- **All Level 0:** \"A blank page is not emptiness — it is possibility. We start from the very beginning.\"\n- **Some knowledge:** \"You have solid roots in [X]. We will build on those.\"\n\nShare the summary and ask: \"Does this reflect where you feel you are?\"\n\n---\n\n## Phase 3: Learning Plan Generation\n\n**Reference the `difficulty-calibration`, `constructivism`, and `spaced-repetition` knowledge bases.**\n\n**CHECKPOINT: Do not proceed to Phase 4 until the learner approves the plan.**\n\nBuild a modular plan based on the assessment, learner goals/timeline, ZPD principles (start just ABOVE current level), and spiral curriculum (revisit concepts at increasing depth).\n\n### Plan Structure\n\nOrganize into **Phases** containing **Modules**. Each module specifies: target Bloom's level, prerequisites, concepts, exercise type (guided/spec-driven/open-ended), and spaced review concepts.\n\n### Plan Principles\n\n- Modules completable in 1-3 sessions (30-90 min each)\n- Include spaced review checkpoints\n- Mix theory and practice in every module\n- Build toward a meaningful project per phase\n- Map learner's existing materials (books, courses) to modules\n- Leave room for adaptation\n- **Each phase after Phase 0 MUST declare at least one Spiral Revisit** — a concept from an earlier phase that this phase revisits at a *higher* target Bloom level (per the `constructivism` KB's spiral-curriculum mechanic — depth comes from returning, not from forward march alone). The revisit is a contract, not a suggestion: a phase that does not name one has skipped a constructivism principle the plan is supposed to honor. Phase 0 is exempt because there is nothing earlier to revisit.\n- **Each module from Module 2 onward MUST declare a `**Prerequisites for next module:**` line** listing the *specific* concept names from this module that the next module builds on (1.10.10 — feeds the `teach` skill Phase 1 prerequisite gate's structured-declaration path; without it, the gate falls back to \"all concepts from the prior module,\" which is conservative but pedagogically noisy). The line lives inside the module section in `plan/phase-{N}.md`, alongside Target Bloom's, Concepts, Exercise, Resource, Spaced Review.\n\n### Per-phase Spiral Revisit declaration\n\nWhen writing each `plan/phase-{N}.md` file (Phase 4 scaffolds them, but the principle is set here), include a `## Spiral Revisits` section near the top of every phase file except phase-0.md. Format:\n\n```markdown\n## Spiral Revisits\n\n- **<concept>** — first reached Bloom <X> in Phase <N-K> (Module <name>). This phase takes it to Bloom <Y> via <which module / which exercise>.\n```\n\nAt least one entry per phase. Multiple entries are encouraged when the phase deepens several earlier concepts. `plan` skill View mode reads these sections to surface the spiral arc to the learner (added in 1.10.5); `plan` skill Regenerate mode preserves them (per the `constructivism` KB reference added in 1.10.3).\n\nPresent the plan. Ask: \"How does this path look to you?\" Adjust based on feedback.\n\n---\n\n## Phase 4: Project Scaffolding\n\n**CHECKPOINT: Do not proceed to Phase 5 until the project directory is created.**\n\nIf Phase 1.5 already located an existing `learningWithBodhi/` root, use it — do NOT re-ask (a second answer forks the profile). Only for a true first project, ask where they want to keep learning projects and create a `learningWithBodhi` folder there.\n\n**If the chosen root is NOT covered by the default discovery search paths** (`$PWD` ± 3 parents, `~/learningWithBodhi` — per the `state-ops` KB), write `~/.bodhikit/config.json` with the chosen root in `searchPaths` NOW. Without this, tomorrow's `continue` skill from any other directory reports \"No active learning projects\" and Day 2 dead-ends.\n\n### Create project structure:\n\n1. If `learningWithBodhi/` does not exist, create it.\n\n2. Create the project folder with this v2 structure (per the `state-schema` KB):\n - `.bodhi/`\n - `state.json` (slim — no narrative fields)\n - `spaced-review.json`\n - `assessment-history.json`\n - `assessments/latest.md` (initial assessment from Phase 2 goes here)\n - `plan/README.md` + `plan/phase-{N}.md` per phase (generated by Phase 4 of this skill)\n - `progress.md` (live document — Phase 5 writes the first session entry)\n - `resources.md`\n - `exercises/`, `projects/`, `notes/`\n\n3. Initialize the JSON skeletons per the shapes in the `state-schema` KB — `state.json` (`version: 2`, `initialBloomLevel` from Phase 2, counters at 0; the script fills session bookkeeping in Phase 5) and an empty `spaced-review.json` (`version: 3`). For a first-ever learner, also scaffold the parent `.bodhi-profile.json` (career/goal fields from Phase 1 scoping — manual carve-out per the KB). Then register the project via `\"<BODHIKIT_PLUGIN_ROOT>/scripts/bodhi-state\" --project <project> profile-add-project --name <project> --topic \"<topic>\" --bloom <overall level from Phase 2> --pace \"<pace>\" --track-purpose \"<purpose>\"` — the script creates `.bodhi-profile.projects.json` if missing and appends a schema-complete `activeProjects` entry. For an existing profile, update `overallBloomLevels` in `.bodhi-profile.json` (manual carve-out, in-place per the KB fallback discipline).\n\n4. **Seed the spaced-review system from the assessment** (the first review is the most critical — `spaced-repetition` KB): for each sub-topic Phase 2 classified at Bloom ≥ 1, run `\"<BODHIKIT_PLUGIN_ROOT>/scripts/bodhi-state\" --project <project> add-concept --concept \"<sub-topic>\" --module \"<its module>\" --bloom <the level Phase 2 classified it at>`. Assessed knowledge enters the Leitner system on Day 1 at the level the assessment observed, instead of waiting for a `teach` skill to touch it — without `--bloom` the seed reads as unclassified and the gate, `continue` skill and the pretest all forget what the assessment just learned.\n\n5. **Record the assessment + counters via the script**: `record-assessment --trigger learn-phase2 --data '<entry JSON from Phase 2>'` and `bump-profile --counter totalProjects`.\n\n6. Suggest git initialization and a remote repository.\n\n---\n\n## Phase 5: First Step\n\n**Do NOT end the session without giving the learner something to DO.**\n\nGive them the first micro-exercise from Module 1:\n- Achievable in 5-10 minutes with visible output\n- Directly relevant to the first module\n- Calibrated to level per the `difficulty-calibration` KB: beginners (Bloom 1-2) get the faded sequence in `exercises/01-<topic>/` — a short inline-annotated worked example to study, then a completion version with 1-2 steps blanked (never a bare TODO list; a brand-new learner is at their highest cognitive load); intermediate+ get a clear description.\n\nUpdate tracking (this is Session 1 of the project), per the `state-ops` KB write path:\n- `\"<BODHIKIT_PLUGIN_ROOT>/scripts/bodhi-state\" --project <project> touch-state --activity \"<one line describing the exercise>\"` — the script sets `lastSessionAt`, `sessionDates`, `currentStreak`, `totalSessions`, and bumps the cross-project session counter.\n- Write the first entry of `progress.md` (the v2 live document): `## YYYY-MM-DD — Session 1 (Kickoff)`, then **Activities** (assessment completed, plan generated, project scaffolded, first exercise issued), **Outcomes** (initial Bloom's levels baselined), **Next** (Module 1 exercise). End the file with an empty `## Summary of earlier sessions` block (it will populate as `housekeep` skill runs after future sessions).\n\nClose with encouragement about taking the first step — and the handoff that keeps them on the path: \"Tomorrow (or whenever you return), one command resumes everything: `continue` skill.\"\n\n**Fallback:** if `bodhi-state` is unavailable, follow the `state-schema` KB fallback rule.\n"
}SHA-256 of public snapshot: 30b0f0fed4ea3b80ed437d2e4d8127003b96984ee3df10ab3ecbb091a5ed5df3