First read config.yaml(if it cannot be read → state plainly that the configuration is missing and stop; do not use sample values to pretend they are the user's settings), then read zmm/references/交互规范.md（🔴 It is not read once and done: when wrapping up, follow §4's three-piece set — Recap · Before/After · next step gives numbered options; if information is missing, follow §4 and usemultiple-choice questionsto ask,only one at a time; for cases where it does not apply, see §5), then read zmm/references/家族公约.md, then read memory {config.paths.memory}/zmm-skillify/ + _通用/。
This skill's built-in criteria are in references/规则卡.md(criteria / why / how to check / strength); read it once before starting;{vault} when there is a corresponding rule file in the vault, the vault takes precedence and the rule card is the base.
🔴 Gatekeeper: if it has not been proven, it must not be solidified
This skill distills only from "a process that has already produced correct results." When entering, first check three things; if any is missing → explain what is missing and stop:
| What to check | When not satisfied |
|---|---|
| Has something really been completed in this session | Only discussion, no output → "there is nothing to solidify yet; finish this thing first" |
| Has the result been verified(user approval / data / an inspectable output) | Not verified → "this approach has not yet been proven effective; solidifying it is equivalent to writing unverified experience into a rule" |
| Will it happen again | One-time → "this thing is unlikely to recur, and the benefit of solidifying it is negative" — you may keep only a record, and not make it a skill |
⚠️ Do not skip the gatekeeper just because the user says "turn it into a skill." What the user wants is to save effort next time, not to have one more inaccurate skill.
Where to distill from: three sources, ordered by credibility
- The actual process of this session — the most credible. It was really done, there was output, and there was feedback.
{config.paths.memory}The skill memory in — corrections and effective methods accumulated previously.- The user's spoken "what I usually do" —— 🔴 Least credible. People's descriptions of their own processes and their actual practices are often different. They can only be used as clues; you must go back to ① or ② to find evidence; if none can be found, mark it as "unverified" in the finished product.
When the three conflict, ① takes precedence, and write the conflict itself into the skill ("what he said is X, what he actually did is Y, and Y takes precedence" is often the most valuable rule).
Five steps
Step 1 · Write out the problem contract
反复出现的问题：
什么情境下会遇到：
这次是怎么解决的（按实际发生的顺序，不是理想顺序）：
产出物是什么：
凭什么算做完了（可检查的证据，不是「感觉good」）：
明确不处理的邻近问题：
🔴 "What counts as done" cannot be written as inspectable evidence → stop. A skill without a completion criterion means no one will know next time whether it ran correctly.
Step 2 · Translate "good to use" into observable behavior
Users will say "it needs to be written naturally" or "the judgment needs to be accurate."These cannot go into a skill.They must be translated into something checkable:
必须做到（可观察）：
禁止出现（可观察）：
允许它自己发挥的部分：
最容易出的那个错：
出错时应该怎样（停下问 / 降级 / 明说做不到）：
Compare: "Judges accurately" ❌ → "Candidates must be chosen from the actually listed set; anything not listed must not be invented" ✅
Step 3 · Set the credibility level of the criteria
The family convention requires every conclusion to be labeled with its source.Every rule in the new skill must carry a level：
| Level | When to use it | How to write it |
|---|---|---|
| 🟢 Empirically tested | There is a concrete case backing it from this session or history | State the cost clearly: "Empirical cost: a full rewrite" |
| 🟡 Inferred | Derived from empirical testing, but not directly verified | Must add one sentence: "If this is wrong, where is it most likely to be wrong" |
| ⚪ Guess | It just sounds right | By default, do not write it into the skill. If you insist on writing it, mark it clearly, and it must not be used as a criterion |
🔴 Do not write 🟡 and ⚪ in the tone of 🟢. This is the easiest mistake to make in the family.
Step 4 · Generate the skill directory and self-check
zmm-<名字>/
SKILL.md 入口：门禁 + 主流程 + 停止条件 + 红线
references/ 条件性细节（只在某些情况下才读的）
scripts/ 重复且确定的活（能用脚本就别让模型算）
Keep the main entry light: SKILL.md only contains what must be followed every time; branch details go into references/。
Self-check list, go through item by item:
- frontmatter has
name(ASCII slug, consistent with the directory name),description(including Chinese trigger words),version - The description clearly stateswhen it should be used, not just what it can do
- Has gates: under what circumstances itshould notbe used and should stop
- Every rule carries a 🟢🟡⚪ level
- Has stop conditions: how far counts as done
- Has read the family convention and interaction spec, and ends with numbered options
- With the existing 20 skills,no overlap in responsibilities — if there is overlap, modify that one instead of creating a new one
🔴 The last item is the easiest to miss. First run bash zmm/scripts/list-skills.sh to look at the existing ones, and explicitly state "what is the boundary between it and zmm-xxx ". If you cannot state it clearly → you should not create a new one.
Step 5 · Let it run once before delivery (passing self-check does not mean it works)
The checklist above is all static items: files exist, fields are complete, rules have levels.If a skill is written and enters the skill directory without ever being run, you will only discover next time you actually use it that the gates cannot be run through — this is the same discipline as "people who write code cannot approve their own code." So before delivery, climb the ladder below; whichever level you reach, you may only speak at that level:
| Level | What was done | What may be said |
|---|---|---|
| 0 | Static self-check passed | "The files are complete."You may not say "it works" |
| 1 | Take a real input and, ina newly opened context , run through it according to SKILL.md; the output meets the completion evidence of the problem contract | "The main scenario ran through" |
| 2 | Ran a set of samples (see below), including at least onenear-neighbor counterexample, and the executor had not seen the answer | "It can distinguish what should be done from what should not" |
| 3 | After revising a version, rerun the same sample set; the hit count must be no lower than the previous version | "This version didn't regress" |
How to build samples(Put them in the skill directory evals/, so they travel with the skill):
sample-NN-<描述>.md: input given to the executor.sample-NN-答案.md: given only to the grader; list two tables, "must catch" and "must not false-positive", 1 point each- A set needs at least three categories:positive examples(should trigger and should be caught) · boundary(right on the gate) · near-neighbor counterexamples(looks similar but belongs to the skill next door, or looks like a problem but actually isn't) —— the trigger words of 22 skills overlap with each other, and near-neighbor counterexamples are what prevent false triggers
- Record results to
evals/results/sample-NN-v<版本>.md，evals/README.mdas one table: sample · version · hits / full score · false positives · conclusion.The version number points to theversionin SKILL.md, and it must not be called "latest version" - Run by hand first; don't write a runner. Three samples run by hand for ten minutes is enough
When a run fails, classify it first, then fix(if you don't classify, you'll just keep adding rules to SKILL.md, making it longer and longer):
| Where it fails | What it looks like | Where to change |
|---|---|---|
| Instruction | The rule is there; the executor understood it as something else | Reword that rule; add a counterexample |
| Trigger | Should have entered but didn't / shouldn't have entered but did | Change the trigger words in description and the "should not use it for" |
| Input | The sample itself is missing something; no one could do it | Change the sample, or add "stop if X is missing" to the gate |
| Criterion | The answer itself is disputed | First align on the answer with the user, then touch the skill |
| Fluctuation | The same input gives different results twice | The rule gave room but no criterion; add a criterion |
🔴 If the same failure has survived three revisions and you're still relying on "add one more rule for this sample", stop: that's not a missing rule; the boundary of this skill is drawn wrong. Go back to Step 1.
Ready-made examples:zmm-flow/evals/(run one version before and after the redesign; results for both v0.1.0 and v0.2.0 are there),zmm-resonate/evals/、zmm-review/evals/(created 2026-09-06).
Delivery boundary
By default, only make it work locally: generate the directory, put it in the user's skill directory, and tell him how to invoke it.
🔴 Publishing is a separate matter and must be done only when the user explicitly asks. This includes: pushing to a public repository, publishing to ClawHub / SkillHub, adding it to the packaged version. If the user didn't say "publish it", don't touch these —— once a freshly formed skill enters public channels, the cost of changing it is much higher than keeping it local.
Stopping conditions
Stop when any of the following is done; don't keep adding:
- The skill runs throughin a new contextthe scenario in the problem contract, and the deliverable meets the completion evidence (Step 5, level 1 or above)
- The user says it's enough
- You find it overlaps with an existing skill → change that one, don't create a new one
- You find the gate isn't passed → explain why, don't force it
Wrap-up
According to 〈Interaction Specification · IV〉: Recap (what has been solidified) · Before/After (if this skill is not done, what will need to be rethought next time) · Next step, provide numbered options.
Conveniently write a memory entry to {config.paths.memory}/zmm-skillify/: what was solidified this time, how the gatekeeping was passed, and whether any overlap was encountered.Check for duplicates first。