菜单
Verify that a stored Lathe tutorial actually works by following it end to end in a fresh scratch dir, in session. Use when the user invokes /lathe-verify with a slug like "/lathe-verify digital-synth-zig" (the "Verify this tutorial" button in `lathe serve` hands you that command).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Run the Lathe worker loop so the web UI's Ask / Verify / Add-a-part buttons drive work directly in this session instead of handing back a command to paste. Use when the user invokes /lathe-work (start it once per session while `lathe serve` is running). Works in any coding agent.
Generate hands-on technical tutorials for any topic on demand. Use when the user invokes /lathe with a topic like "/lathe build a digital synth in Zig" or "/lathe how to build a compiler in Rust".
Write the next part of an existing Lathe tutorial, in session. Use when the user invokes /lathe-extend with a slug like "/lathe-extend digital-synth-zig" (the "Add a new part" button in `lathe serve` hands you that command), optionally followed by guidance for where the part should go.
Author a custom writing voice for Lathe tutorials, in session, then persist it via the CLI. Use when the user invokes /lathe-voice (optionally with a name like "/lathe-voice terse") to craft a new tone/register preset that /lathe can generate in.
Answer a reader's question about a specific part of a Lathe tutorial, in session. Use when the user invokes /lathe-ask with a slug and part like "/lathe-ask digital-synth-zig part-02.md" followed by the question on the next line (the "Ask" button in `lathe serve` pastes exactly this).
Pick or backfill the search tags on a stored Lathe tutorial, in session. Use when the user invokes /lathe-tag with a slug like "/lathe-tag digital-synth-zig" to choose good tags for the `lathe serve` search and tag filters, or to backfill tags on a tutorial that has none.
| name | lathe-verify |
| description | Verify that a stored Lathe tutorial actually works by following it end to end in a fresh scratch dir, in session. Use when the user invokes /lathe-verify with a slug like "/lathe-verify digital-synth-zig" (the "Verify this tutorial" button in `lathe serve` hands you that command). |
Follow a stored tutorial exactly as a reader would, in a throwaway directory, and record whether it actually works. Triggered by /lathe-verify <slug>. Isolation is by instruction — a fresh mktemp -d, under the user's normal interactive permissions. No sandbox-exec, no Docker.
This skill is read-only with respect to the tutorial: never edit the parts or the metadata. The only writes are status updates through lathe verify-result.
Mark it in-flight first:
lathe verify-result <slug> --status verifying
This sets the spinner badge in the web UI. If it errors with "cannot verify while it is extending", stop — a part is mid-flight; don't verify on top of it.
Make a fresh scratch dir and work there:
cd "$(mktemp -d)"
Everything the tutorial tells the reader to create happens here, not in the user's project. (Status is set by this skill, never by the web/CLI button — so an unclicked button can never strand a tutorial at verifying.)
Follow each part in order. Read ~/.lathe/tutorials/<slug>/part-NN.md from part-01 up. Install the prerequisites, create the files and paste the code blocks exactly as written, in order, then run the ## Checkpoint command and compare against the stated expected output.
> [!PREDICT], > [!RECALL], and > [!UNVERIFIED] are not verifiable steps. They prompt the reader or flag uncertainty; there's nothing to execute.Record the terminal result with the matching command:
lathe verify-result <slug> --status verifiedlathe verify-result <slug> --status skipped
This is not a failure — it's the ⚠️ Skipped badge, meaning "couldn't run it here," not "the tutorial is wrong." Use it whenever the toolchain the tutorial needs (compiler, runtime, SDK) is missing locally.lathe verify-result <slug> --status failed \
--part <part-NN.md> \
--failed-step <1-indexed step number within that part> \
--error "<the error message or mismatched output>"
Report to the user what happened — verified clean, skipped (and which tool was missing), or where exactly it failed.
part-NN.md, metadata.json, or verify-result.json directly — the only state writes are via lathe verify-result.mktemp -d scratch dir plus instruction, under the user's normal permission model. Don't reach for sandbox-exec or Docker.skipped. Reserve failed for the tutorial being genuinely broken.