菜单
Build something already designed, together with the user, then verify it and offer to commit. Use when a design is agreed and the work is ready to write, or when another skill needs the shared build discipline.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/asermax/claude-plugins --skill build命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Load first when working with any zenku skill. Carries the vocabulary, the two rules, how to find the project's vault and conventions, and the habits for writing into it.
Lay out the current shape so the user can settle a new one — which modules exist, where the seams are, how data flows, and what earlier quests already decided. Use when the user wants to design a feature or a module, work out an interface, decide where a boundary belongs, or when another skill needs a shape agreed before code.
Talk something through with the user relentlessly, round by round, until you reach a shared understanding. Use when the user wants their thinking stress-tested, says to grill or press or challenge them, or when another skill needs a decision settled by the person who owns it.
基于 SOC 职业分类
正在显示 SKILL.md
| name | build |
| description | Build something already designed, together with the user, then verify it and offer to commit. Use when a design is agreed and the work is ready to write, or when another skill needs the shared build discipline. |
Load zenku:codex.
The decision is already made and the design is already agreed — the user took it down to the types and signatures with zenku:design, and settled it. What is left is writing it.
Build it with the user, not for them. Work in slices that each leave the thing working, and show each one as it lands. A slice that came out differently from the design is the most useful thing you will say all session: say it when it happens, while it is still cheap to go the other way.
New or changed behaviour gets new or updated automated coverage, and nothing exists only to make a test pass.
Verify. Run the project's **Checks**, then launch it and drive the path a real caller would. Green checks say the code runs, not that the thing works, and the gap between those two is where the failure that passes every test lives. Anything red: say which, and stop. Stay in the local or development environment throughout.
Write the lore, if this is a loose quest. Load zenku:lore. A change to how something works that leaves no lore is half done, and the quest's design is most of the draft already.
Under a raid, do not. The lore gets written once, at the raid's end, out of every quest's design at once, the journey's and the raid's together. A slice that documents itself as it lands produces one page per slice, each describing a part of a shape nobody has seen whole yet, and reconciling those afterwards costs more than writing the page once. Leave the detail on the quest and go on.
Close the quest with zenku:solve, if a quest record covers this. Building it is not finishing it: an unclosed quest still shows as in reach and still blocks whatever waited on it.
Then say it is ready to commit, and stop. Committing is zenku:commit and it is the user's to invoke. Approval of the work is not an instruction to commit it: they may want to keep going, fold this into other work, or handle the commit themselves.