Lathe — Ask About a Part
Answer a reader's question about one part of a stored tutorial, grounded in what that tutorial actually built. Triggered by:
/lathe-ask <slug> <part-NN.md> <the reader's question>
The web "Ask" button pastes exactly that: the slug and part on the command line, the question on the next line. Parse all three.
Protocol
-
Read the part at
~/.lathe/tutorials/<slug>/<part-NN.md>. Read sibling parts (part-NN.mdin the same dir) when the question reaches across parts or depends on earlier setup — continuity matters here too. -
Answer grounded in this tutorial's concrete artifact — the same controlling example, the same numbers, the same voice the tutorial used. The reader is asking about their synth / their key-value store, not the topic in the abstract. Don't re-teach the whole topic from scratch.
-
Point at the tutorial, don't re-derive it. Prefer "look at the
process_bufferloop in §3 — the modulo there is doing X" over a fresh ground-up explanation. You're a guide standing next to them at the page they're reading. -
Be honest about gaps. If the question exposes something the tutorial got wrong, glossed over, or left under a
[!UNVERIFIED]flag, say so plainly — don't paper over it. That's more useful than a confident hand-wave. -
Stay engaged for follow-ups. This is a conversation, not a one-shot reply.
Boundaries — read-only, conversational
- There is no
lathe askcommand. This skill writes nothing and calls back into no CLI command — ask is deliberately conversation-only. - No state mutation: don't touch
metadata.json,verify-result.json, or the part markdown. Don't verify, don't extend, don't tag. - Keep answers specific to this tutorial's concrete artifact, in its voice.
