Tutorials / Practice projects
Tutorial

Practise on a real project

Turn a published Nebular programme into hands-on project work. The lume CLI scaffolds a project from your programme’s skills, coaches you Socratically as you build it, and gates procedural mastery on the code you actually ship.

~20 min5 stepsupdated Jun 3, 2026
Before you start
Node 22 or later — required by @nebular-ai/lume
A published Nebular programme — complete the quick start or agentic authoring tutorial first
A terminal (any shell)

lume is an alpha CLI coach that runs in your terminal. Install it once globally, then authenticate so lume can reach your programmes and route all LLM calls through the Nebular backend proxy — your shell never needs a model API key.

lume requires Node 22 or later. Install it globally: alpha

bash
$npm install -g @nebular-ai/lume
Where credentials live
Credentials are stored at ~/.config/lume/credentials (mode 600). All model calls route through https://nebular.live — no model API key belongs in your shell environment. The only optional env vars are NEBULAR_API_URL and NEBULAR_PAT.
~ — lume
$lume login
Opening https://nebular.live/connect/cli …
Waiting for browser approval …
✓ logged in as jordan@example.com
# credentials saved to ~/.config/lume/credentials
$

Start fresh with lume scaffold — it interviews you, picks the programme, and generates the project layout. Already have a repo? Run lume init to attach it instead.

bash
$mkdir svd-recommender && cd svd-recommender
$lume scaffold
lume asks which programme to bind and what scope to use, then creates the project layout in the current directory.

During the interview, lume asks for a project scope. Choose the one that fits your time horizon:

module-scalerecommended
One mini-project per module — a 1–2 week arc. Each milestone maps to a single lesson. Recommended for most learners.
programme-scale
One long-running project across the entire programme. Better suited to learners who already have a concrete artefact in mind before they start.
none
Pure pedagogy — intuition and conceptual artefacts only. No project deliverables. Procedural mastery is not tracked.

The scaffold creates this layout in your working directory:

svd-recommender/
.nebular/
project.json # lume config + programme binding
enrolment.json # learner enrolment metadata from server
README.md # project brief (co-authored with you)
milestones.md # milestone → lesson → skills mapping
src/
tests/
deliverables/ # validator configs + expected outputs
~/svd-recommender — lume scaffold
$lume scaffold
Which programme?
› Introduction to linear algebra
Project scope?
› module-scale (recommended)
✓ created .nebular/
✓ created README.md, milestones.md
✓ created deliverables/
run `lume` to start coaching

After scaffolding, lume interviews you to produce README.md (your project brief) and milestones.md (a milestone-to-lesson table mapping each module’s skills to a concrete deliverable). These become the contract lume coaches against.

Each row in milestones.md links one milestone to one lesson and its skill ids. lume uses this table to decide which skills are under test at each coaching session and to route evidence to the right lesson in the learner runtime.

  1. 1Answer lume’s brief questions about the project goal — a few sentences is enough.
  2. 2Review the generated README.md and edit freely. lume keeps a working copy of the brief in memory while coaching.
  3. 3Open milestones.md to see the milestone table. You can rename milestones or reorder them; do not rename skill ids (they link to the programme).
lume won’t write your code
lume scaffolds one example file to show the expected shape of each deliverable. Every line of real project code is yours to write. That constraint is intentional — procedural mastery must come from work you actually produce, not from a generated stub.
milestones.md
# milestones
MilestoneLessonSkillsStatusM1Build the ratings matrixVectors & matricesvectors, matrix-multin-progressM2Compute cosine similarityInner productsdot-product, normpendingM3Run SVD factorisationDecompositionssvd, low-rank-approxpending

Run lume with no arguments in the project directory to enter coaching mode. lume works through the skills under test Socratically — it asks probing questions, you answer and write code. Per lesson the loop runs: intuition → conceptual → procedural.

Procedural evidence is read from your real project files — lume cites specific file paths and line numbers. When a deliverable validator confirms the work, lume records the evidence automatically to the learner runtime. You do not call any evidence API yourself.

  1. 1Run lume in svd-recommender/. lume prints the active milestone and the skills under test, then opens with a Socratic question.
  2. 2Answer and implement the milestone in src/. lume reads your code to verify the procedural component — it does not rewrite it.
  3. 3Once lume sees sufficient procedural evidence in your files, it records mastery and moves to the next skill. The per-lesson loop then advances: intuition → conceptual → procedural → next lesson.
Evidence is gated on real work
Procedural mastery is validated mechanically — lume reads the deliverable validator output, not a self-assessment. You cannot skip ahead by telling lume you understand something; it waits for the code.
~/svd-recommender — lume
$lume
programme: Introduction to linear algebra · M1
lume › Before you write any code: what shape should
the ratings matrix be, and why?
you › rows = users, columns = items, values = ratings
lume › Correct. Now, what happens to the matrix when
most users have only rated a few items?
you › it becomes sparse — most entries are zero
· evidence recorded: matrix-mult (procedural)
← src/ratings.py:18

Run lume validate at any point to execute each deliverable’s validator and see a pass/fail summary. Passing validators update evidence in the learner runtime automatically — mastery then appears on your /dashboard.

Validators live in the deliverables/ directory generated during scaffold. Each one is a lightweight script that checks a specific property of your output — shape, correctness, boundary conditions. The output tells you exactly which deliverable failed and why.

  1. 1Run lume validate from the project root. Each row in the output is one deliverable with a pass () or fail () and a short reason.
  2. 2Fix any failing deliverables, then re-run. There is no limit on how many times you can validate.
  3. 3Once all deliverables for a milestone pass, lume syncs the evidence to the learner runtime and the milestone advances. Mastery appears on /dashboard within a few seconds.
No manual evidence calls
lume records evidence to the nebular-learner MCP on your behalf. You never call an evidence API directly — validate your deliverables and your dashboard updates automatically.
~/svd-recommender — lume validate
$lume validate
running deliverable validators …
✓ ratings matrix shape src/ratings.py
✓ cosine similarity src/similarity.py
✗ top-N recommendations expected 5, got 3
mastery: 2 / 3 skillssynced to nebular-learner