mcpField
S
st-refine-plan

st-refine-plan

github.com/e0ipsoAgent 工作流58281 次安装今天更新
代码仓库

关于 st-refine-plan

st-refine-plan 是用于根据数字 ID 审查和完善现有 Strikethroo 计划的技能。它记录计划缺口、处理澄清、原位更新计划，并运行计划后置钩子。

主要功能

  1. 01定位并验证计划
  2. 02审查背景、技术、风险和范围缺口
  3. 03交互式或自主澄清不确定事项
  4. 04修订计划并追加变更记录
  5. 05运行计划后置钩子

适用场景

  1. 01在实施前审查现有计划
  2. 02澄清计划疑问并记录决策
  3. 03更新计划结构和风险缓解措施

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/e0ipso/strikethroo --skill st-refine-plan

安装后在 Claude Code 中输入/st-refine-plan确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

scripts/
check-for-updates.cjs
find-strikethroo-root.cjs
validate-plan-blueprint.cjs

详细介绍

st-refine-plan

输入

用户通过对话提供数字计划 ID，以及任何可选的细化备注。

操作流程

1. 定位 strikethroo 根目录

在用户的工作目录中运行 scripts/find-strikethroo-root.cjs。如果退出码非零，则停止并请用户运行 npx strikethroo init。

后续所有步骤均将其输出的路径视为 <root>。

委派执行的工作线程跳过此步骤，且不发送更新通知。

使用此技能的脚本路径，单独运行 scripts/check-for-updates.cjs "<root>"。保持用户的工作目录不变。读取 stdout 中的一行 JSON。如果存在 notice，则在面向用户的最终回复中保留其原文。切勿暂停等待许可，也不要运行更新。

2. 解析计划

运行 scripts/validate-plan-blueprint.cjs <plan-id> planFile，以获取计划文件的绝对路径。指定其他字段名则输出对应字段。

如果脚本退出码非零，则停止并请用户确认计划 ID。不要猜测其他 ID。

3. 加载项目上下文

读取 <root>/config/STRIKETHROO.md，了解此项目的目录约定。 读取 <root>/config/hooks/PRE_PLAN.md，并在继续之前执行其中的指示。读取 <root>/config/templates/PLAN_TEMPLATE.md；细化后的计划仍必须符合该模板。读取 <root>/config/shared/clarification-gate.md，并在澄清循环中遵循其要求。

4. 基线审查

从头到尾阅读整个计划，不作任何修改。按以下角度记录发现的所有矛盾和缺漏：

  • 上下文缺漏：背景缺失、假设、优先级冲突。
  • 技术缺漏：架构说明不充分、接口不明确、缺少图示。
  • 风险缺漏：未跟踪的风险、缺少缓解措施、成功指标含糊其辞。
  • 范围问题：过度设计、边界模糊、与 YAGNI 相矛盾的需求。

将每项记录为 {section, issue, severity, proposed fix}。

5. 澄清循环

默认采用交互式澄清。 只有在以下任一情况明确成立时，才切换到自主澄清：

  • 用户的请求通过意图明确指定了模式，并使用了诸如“auto”“autonomous”“non-interactive”“without asking me”或“don't ask”等关键词。
  • 上游协调器（例如 st-full-workflow 技能）在传递给此技能的提示中声明本次调用采用自主模式。

否则，使用交互式澄清，即使不确定用户是否在线。不要根据间接信号推断自主模式，例如提示简短、输入看似脚本化，或用户近期没有发消息。

两个分支都从基线审查中记录的缺漏开始。提出问题前要深入思考；只提出有据可引的不确定事项。

将每项解决方案追加到计划文档的“Plan Clarifications”表格中，沿用其现有的问答格式，并标明每项的来源。

交互式澄清

遵循 <root>/config/shared/clarification-gate.md 中的澄清节奏。

  1. 按照该节奏一次只问一个问题；切勿一次性列出所有问题。
  2. 每个问题都预填最合理的答案，并始终提供“其他 / 开放回答”选项，以涵盖你未预料到的细节。
  3. 停止并询问：向用户提出每个问题，然后暂停执行并等待其输入。不要模拟用户的回答。在收到明确答复并确认已解决的范围之前，不要继续执行第 6 步。
  4. 如果用户无法或不愿回答某个问题，则将其记为未解决，并附上缓解说明，以便下游助手了解相关风险，然后根据现有上下文继续。
  5. 重新评估答案是否引出了新的缺漏。如果有，则重复此循环。
自主澄清
  1. 根据代码库、其配置文件、文档和项目既有模式，解决每项信息缺口。只有在这些内容都无法提供答案时，才采用合理假设。
  2. 标注每项结论的来源为“自动解决”（已在代码库中确认）或“假设”（尽力作出的猜测，并说明理由）。
  3. 对无法以任何方式解决的信息缺口，将其标记为未解决，并附上缓解说明，以便下游助手了解风险。
6. 完善计划

在步骤 2 确定的路径中直接完善计划。

  1. 保持身份不变：保留现有 id 和目录。切勿分配新的计划 ID，也不要移动计划。
  2. 遵循结构规范：确保计划符合 <root>/config/templates/PLAN_TEMPLATE.md，并补充任何缺失章节。
  3. 更新内容：
    • 根据澄清结果更新执行摘要。
    • 更新架构章节、图示及针对信息缺口的风险缓解措施。
    • 删除未明确要求的范围扩张内容。
    • 让每个受影响的章节都指向问答表。
  4. 新增章节：在 Notes 下添加计划现在需要的小节（Decision Log、Data Contracts），并清晰标注。
  5. 变更日志：在 Notes 中追加一条要点，说明本次会话的更改，例如： - 2025-03-16: Clarified auth flow tokens and updated architecture diagram
7. 运行计划后置钩子

执行 <root>/config/hooks/POST_PLAN.md。

如果存在保留的更新 notice，请将该完整句子追加在结构化摘要块之后；如果此技能不生成摘要块，则追加在最终回复之后。该 notice 后不得有任何内容。

失败模式

  • 辅助脚本意外失败。 将 stderr 输出给用户并停止操作——不得改用手动路径查找。

评论

支持 Markdown