wellwelwel/blue-spec

模拟 Blue Spec 命令

此技能的存在是因为模拟命令很容易出错，从而浪费用户的时间和信任。多次实战会话产出了四条不可妥协的规则和一个方法。请严格遵循。

只要用户要求“模拟”、“演示”、“实际展示”、“运行”或“查看实际效果”任何 /bluespec.* 命令（charter、detect、plan、harden、verify），或想要在发布前预览命令的行为，请使用此技能。

开始前（必须执行）

在以下两项按顺序确定之前，不要开始模拟、构建场景或复制测试项目：

1. 用户必须告诉你模拟哪个 Blue Spec 命令。 这是必须的，切勿假设或自行选择。如果用户未指定命令（charter、detect、plan、harden 或 verify），请在执行任何操作前询问。如果用户指定了多个，请确认执行顺序。
2. 然后列举可用的测试项目，让用户选择。 确定命令后，列出可用的测试项目（位于 .claude/skills/simulate/fixtures/），以编号列表的形式呈现，每个项目附带一行场景描述，并请用户通过编号选择。不要默默默认使用某个测试项目。即使只有一个测试项目，也要呈现并确认后再使用。如果没有适合当前命令的测试项目，请告知并提供新增测试项目的选项（见测试项目部分）。

只有在命令被指定且测试项目被选择后，才能继续执行下面的规则和方法。

为什么存在此技能（请先阅读）

Blue Spec 命令不是一个独立的程序。它是一个指令文件（spec/commands/bluespec.<phase>.md，作为智能体读取的技能被搭建），告诉 AI 智能体如何执行安全工作的某个阶段。“运行命令”意味着智能体遵循这些指令。没有二进制程序能产生独立于智能体的确定性结果。因此，“模拟”就是智能体针对真实场景实际执行命令的步骤，同时展示其工作过程。

需要避免的失败模式：叙述你_想象_命令会输出的内容，将其格式化为终端样式，并呈现为已运行的状态。那是表演。用户无法区分发明出来的输出和真实输出，他们会（正确地）称之为闹剧。以下所有内容旨在使模拟真实且可由用户验证，而不是一场表演。

四条硬性规则

规则 1：在 ./temp 下运行场景

模拟所涉及的一切（测试项目、各阶段产生的 .bluespec/memory/ 工件、任何输入）都应在仓库根目录下的 ./temp 内构建，绝不能放在系统的 /tmp 中。

• /tmp 对用户不可见：用户无法在编辑器中打开这些文件，因此你在那里所做的一切都变成了“相信我”。./temp 在用户的工作区中，可打开、可检查。
• ./temp 已被 .gitignore 忽略，因此模拟永远不会污染提交。
• 模拟完成后清理 ./temp，或留待用户检查，但需先询问。

测试项目：每次模拟都从一个开始

此技能附带了一些中立的示例项目，每个项目位于 .claude/skills/simulate/fixtures/<name>/ 目录下。选择场景适合命令需求的测试项目，或新增一个（见下文）。每个测试项目都是一个小的真实项目，故意包含健壮和脆弱的代码，以中性配对的方式存在，因此命令必须分析代码，而不是读取标签。

可用测试项目：

• image-upload-service：一个小型 ESM HTTP 服务，接受图片上传并返回。
• template-toolkit：一个可发布的 ESM npm 包（一个库加上一个 tmpl CLI），用于渲染模板和解析文本。

始终通过将一个测试项目原样复制到 ./temp 来开始模拟。 如果 ./temp 已存在且不为空，请先清空，以便每次运行都从干净状态开始（将 <name> 替换为你选择的测试项目）：

rm -rf ./temp && mkdir -p ./temp
cp -R .claude/skills/simulate/fixtures/<name>/. ./temp/

然后在 ./temp 上通过实际运行上游阶段（依据规则 4）来构建链条，这样命令读取的 .bluespec/memory/*.md 工件是由其自身阶段产生的，而非手写。严格按照命令的规范（依据规则 3）对 ./temp 执行命令的步骤，并根据规则 2 展示每个步骤的输出。

要添加测试项目，创建 .claude/skills/simulate/fixtures/<new-name>/ 作为一个小的真实项目，带有自己的 package.json，保持健壮和脆弱代码的中性配对，不添加任何暗示性注释或名称，并在上面列出。当某个命令需要当前测试项目未覆盖的材料（不同的语言或技术栈、机密处理、认证、数据库等）时，添加一个新的。

规则 2：将提示和响应以围栏代码块的形式展示在聊天消息中

这是花了最长时间才学会的规则。当你运行一个工具（Bash、Read）时，用户的界面会显示该工具 IN 和 OUT 的截断预览。你无法控制显示多少，通常会截断。如果支持某个论断的证据只存在于工具调用的输出中，用户看不到它，而你描述它的任何句子都会被理解为编造。

因此：

• 运行工具后，将相关的原始输出复制到围栏代码块（三个反引号）中，放在你的普通聊天消息中。围栏代码块在每个界面中都能完整且一致地渲染。这就是用户所说的“黄色字母”：一个 Markdown 代码块。
• 命令的提示和交互内容（/bluespec.<phase> 运行时的逐步过程、作用域决策、判定等）也要放在围栏代码块中，格式类似于抄本。
• 绝对不要写“上面的输出显示 X”指向工具调用。要指向你粘贴的围栏代码块，用户可以完整阅读。
• 当你抄本中的某个数字或行来自实际运行时，它必须与你粘贴的原始输出匹配。如果你写了一个抄本行，但没有粘贴原始输出作为支撑，那你就是在编造，所以停下来。

一个可靠的模式：运行命令，将原始输出重定向到 ./temp 下的文件（例如 ./temp/run.log），然后 Read 该文件（Read 结果会完整显示给你），并将其内容粘贴到围栏代码块中。用户也可以打开 ./temp/run.log 进行验证。

边执行边展示，绝不要最后批量处理。 触发点是每一步：一旦某一步产生了用户应该看到的内容（读取的输入、其抄本、写入的工件），就在同一条消息中将其粘贴到围栏代码块中，然后再进行下一步。如果你即将开始下一阶段或修复，而前一步的输出尚未显示在屏幕上，请停下来先粘贴输出。如果用户需要提醒你显示命令的输出，那规则已经失效了。

规则 3：你就是命令，所以严格按照规范执行

“运行命令”就是你逐步执行 spec/commands/bluespec.<phase>.md，而不是按你自己的方式执行该阶段并称之为命令。

• 首先打开该规范，将其视为唯一真实来源。 按顺序遵循其步骤。不要凭记忆或此技能的摘要来运行该阶段。
• 执行规范中设置的每一处确认停止，真实执行。 harden 必须在编辑任何代码前确认；完整的 detect 扫描必须确认，因为它会消耗大量 token。以抄本块的形式呈现规范要求的内容，然后等待。未经确认，切勿编辑代码或运行需停顿的步骤。
• 按照规范步骤确定作用域、判定、修复、优先级和发现项，针对实际场景。如果你无法指出规范中的哪个步骤证明输出中的某一行合理，那你就是在作为你自己行事，所以停下来，遵循规范。

规则 4：每个阶段的输入必须来自运行前一阶段，而不是来自你

链条是 charter → detect → plan → harden → verify，每个阶段读取前一阶段写入的内容。手动编写包含你预期答案的下游工件（例如编写一个 harden.md，其中记录了你希望 verify 确认或捕获的精确内容）是失败的：下游阶段随后会针对你的预测进行测试，而不是针对现实，因此会错过你所漏掉的内容。

• 通过运行其阶段来产生每个上游工件，在其自己的规范下，并根据规则 2 展示。要演示 verify，先运行 detect（读取代码），然后 plan（读取 detect.md），然后 harden（读取 plan.md，编辑代码）。即使用户从链条中间开始，也要按顺序通过这种方式构建缺失的工件。
• 让工件说出实际运行产生的内容，包括差距：Partial、Blocked、你未预见到的发现项。一个可疑的干净工件说明这条规则被违反了。
• 故意偏离的场景是可以的（harden 应用了所有更改，然后代码被还原，这样 verify 必须发现差异），但要将偏离引入过程可见地展示出来（在显示的工具调用中进行还原，保留真实的工件），绝不能通过手写写入运行从未产生的记录。

分步方法

每个阶段读取前一阶段并写入一个工件。了解这个链条，不要破坏它：

阶段	读取的内容	写入
charter	项目上下文	.bluespec/memory/charter.md
detect	代码	.bluespec/memory/detect.md
plan	仅 detect.md，绝不阅读代码	.bluespec/memory/plan.md
harden	仅 plan.md 加上 charter，并编辑用户代码	.bluespec/memory/harden.md
verify	harden.md 和代码，将记录与现实对照，不更改任何内容	.bluespec/memory/verify.md

然后，对于你正在模拟的命令：

1. 将测试项目原样复制到 ./temp（规则 1）。
2. 通过按顺序运行每个上游阶段（针对 ./temp）来构建链条（规则 4）。
3. 在其 spec/commands/bluespec.<phase>.md 下严格按规范运行目标阶段（规则 3）。
4. 边执行边将每个输入、抄本和工件放入围栏代码块中展示（规则 2）。将每个输出工件写为真实文件，然后 Read 并展示。

呈现前的诚实检查

• 这是实际运行的结果，还是我在输入我认为会发生的事情？
• 每行抄本是否都由我粘贴的原始输出或用户可打开的 ./temp 文件支撑，而不是截断的工具调用输出？（规则 2）
• 到目前为止的每一步输出我都已经粘贴了吗，这样用户就无需再询问？（规则 2）
• 我是否遵循了每个阶段的规范，包括确认停止，而不是以我自己的方式行事？（规则 3）
• 每个上游工件是否来自运行其阶段，而不是我手写了想要的结果？（规则 4）
• 场景是否在 ./temp 下，而不是隐藏在 /tmp 中？（规则 1）

如果任何答案是“否”，请在发送前修正。用户宁愿看到真实但适中的输出，也不愿看到精心修饰的编造物。