菜单
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).
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/devenjarvis/lathe --skill lathe-verify命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
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.
基于 SOC 职业分类
| 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.