Temper-Skills（库模式）是做什么的？

将智能体技能或提示词的决策逻辑转化为确定性Python代码——推理时零LLM调用——通过驱动已安装的temper-skills CLI。你编排CLI并转发其输出；库负责处理tempering。你无需自己编写决策树。

在你自己无法使用原生子智能体/Task原语来运行循环时使用此技能。在Claude Code内部，优先使用子智能体模式技能（它无需密钥运行，并带有实时面板）。此模式改为通过CLI执行命令。

何时使用

一个.md技能、系统提示词或playbook包含路由/决策逻辑（关于结构化输入的if-this-then-that），这些逻辑应该是可测试的、可在PR中diff的，或对模型更新具有韧性。
适用场景：票务路由、分类规则、资格检查——基于可预先计算的特征的分类决策。
不适合：连续评分、文本生成，或者模型无法访问文档的逻辑。

不可协商的规则

始终通过其CLI调用库。永远不要用自然语言重新实现决策逻辑来替代运行它。
永远不要跳过模式批准。 你批准的模式是循环后续共同演化的简单种子（schema_critic扩展它，earn-a-branch守卫修剪它），所以种子中的静默提取错误仍然会污染一切。即使没有连接终端，也要使用下面的基于文件的关卡（--propose-schema）。请审查共同演化的模式以及CLI在最后打印的任何schema gaps / schema grew注释。
永远不要静默安装。 如果关卡（步骤0）报告库或后端缺失，请在运行pip install或更改其环境之前询问用户。
永远不要声称树是“正确”的——只声称它是确定性的和可审计的。正确性由用户通过已批准的示例（validate，步骤4）确定。
逐字转发CLI的关卡和裁决——审计裁决、角色面板、灰色地带、等待批准的案例。不要对它们进行总结。

步骤0 — 检查安装和后端

运行python scripts/check_install.py并根据退出码进行分支：

0 — 就绪，继续。
10 — 已安装但没有模型后端。告诉用户：temper-skills需要一个后端——已登录的claude或opencode CLI，或者环境中的ANTHROPIC_API_KEY。询问他们希望如何提供。在后端就绪之前不要继续。
11 — 未安装。 询问：“temper-skills未安装。现在安装它吗？（pip install temper-skills）”仅在明确确认后安装。

步骤1 — 使用`guide`进行分类（此处的引导步骤）

找到包含决策逻辑的.md文件或提示词（如果不明确，与用户确认路径），然后运行单命令导览：

temper-skills guide <path/to/skill.md> --json

如果用户指向一个目录（技能库），则扫描该目录而不是引导单个文件——审计本身就是一个值得转发的报告：

temper-skills audit <dir> --json --report audit.md

转发排名后的结果（JSON是一个按可操作性排序的按技能报告列表），并提供引导最佳候选者。audit.md是一个可共享的Markdown版本，适用于PR。

始终传递--json。 guide和ingest然后在stdout上发出机器可读清单，并将人类可读的Rich面板发送到stderr——读取清单，不要抓取面板。guide的清单是：

{ "audit": { "verdict": "...", "recommended_action": "...", ... },
  "action_taken": "temper|decompose|...",
  "status": "compiled|stopped_for_ratification|action_not_auto_run",
  "final_skill_path": "...", "artifacts": ["..."] }

guide 审计技能，然后遵循recommended_action。向用户转发审计裁决和操作：

temper — 一个树状决策。guide对其进行temper（快速）；status: compiled。
decompose — 一个流程（≥2个决策）。guide为每个决策发出模式并停止；status: stopped_for_ratification。
externalize_data / build_normalizer / delegate_prose — 不是tempering任务。status: action_not_auto_run；转发操作提示并停止。

guide是导览：它运行quick配置文件并自动接受推断的模式。这对于“显示这个做什么”来说没问题，但如果是用户将依赖的树，请转到步骤2以便批准模式。

步骤2 — 生成持久树（已批准的流程）

2a. 草拟模式并停止等待批准

temper-skills ingest <path/to/skill.md> --propose-schema --json

这会写入schema.proposed.py并停止——循环永远不会在未批准的模式上运行。stdout上的JSON给出{proposed_schema_path, fn_name, features:[{name,type,description}], constraints}。向用户展示建议的特征，并准确询问一件事：接受这些特征，还是编辑列表？ 将他们的编辑应用到schema.proposed.py。

在此处不要询问用户任何其他内容——不要问特征范围，不要问保留哪些分支。修剪是循环的工作（过度工程批评者），而不是用户的工作。

2b. 针对已批准的模式进行编译

temper-skills ingest <path/to/skill.md> \
  --schema schema.proposed.py \
  --profile standard \
  --json

与用户一起选择配置文件——quick | standard | audit-grade，默认standard；在推荐之前请参阅references/profiles.md。--json意味着非交互式：循环运行直到收敛（当以这种方式驱动时，它无法为每轮关卡暂停——该关卡是人工终端功能）并在stdout上发出结果清单。读取它，不要抓取面板。（如果审计裁决是skip，则--require-fit会以退出码3提前中止；添加它以避免在不适用的内容上浪费循环。）

2c. 如果操作是`decompose`

流程必须首先拆分；单独对每个决策进行temper：

temper-skills decompose <path/to/skill.md> --temper-each --out-dir out/

这会为每个决策发出一个模式并停止等待批准。向用户展示模式，让用户编辑它们，然后重新运行相同的命令以将每个决策编译为一个树加上编排技能（--yes-unratified跳过停止——除非用户要求，否则避免使用它）。

步骤3 — 报告工件（来自清单）

ingest --json清单是真相来源——读取这些字段，不要抓取：

{ "tree_path": "...", "tempered_skill_path": "...",
  "validation_dataset_path": "..." , "validation_case_count": 0,
  "gray_zones": [{"node": 1, "condition": "...", "note": "..."}],
  "features": ["..."], "node_count": 0, "profile": "...", "cost_usd": 0.0 }

向用户展示所有三个工件：

tree_path — 决策树：不导入任何内容，推理时零LLM调用，带有generated_at + 模型头部和每节点溯源注释；
tempered_skill_path — 经过temper的skill.md：原始技能被重写为调用冻结的树，而不是重新决策。一半的交付物；不要丢弃它；
validation_dataset_path — 循环为其灰色地带构建的已提交的.validation.jsonl，等待批准（validation_case_count）。"agrees": false的行是用户需要裁决的最高价值分歧。旁边的行为锁定测试（test_<stem>.py）保持绿色；只有已批准的标签才能使测试变红。

告诉用户路径、配置文件、cost_usd和gray_zones。重申规则4：确定性和可审计性，而非“正确”。

步骤4（可选）— 在CI中固定

一旦用户批准了一个带标签的数据集，根据它验证树：

temper-skills validate decision_tree.generated.py ratified.json --min-agreement 1.0

不一致时非零退出——这就是在CI中固定树的方式。每个不一致要么是树错误，要么是标签错误的示例；转发它们以供签核。

参考

在推荐配置文件之前，请参阅references/profiles.md了解每轮/收敛/角色面板/每配置文件成本。

绝对禁止

绝对不要用自然语言编写树逻辑来代替运行库。
绝对不要跳过模式批准，即使在quick演示中（quick会删除溯源注释，但不会删除关卡）。
绝对不要在未经明确确认的情况下安装或修改环境。
绝对不要声称生成的树是“正确”的。

Temper-Skills（库模式）