원클릭으로
define-workflow-refine
从模糊想法变成明确的 spec。当有一个模糊的想法需要结构化收敛,或提到"提炼""收敛""需求""spec"
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
从模糊想法变成明确的 spec。当有一个模糊的想法需要结构化收敛,或提到"提炼""收敛""需求""spec"
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
结构化脑暴——发散探索 + 收敛评估。当想法模糊、面临开放性问题或需要方案对比,或提到"脑暴""想法""方案对比""怎么办"
恢复保存的工作上下文。当新 session 需要继续之前的工作,或提到"恢复""restore""继续上次"
保存工作上下文。当需要保存当前工作状态供后续 session 恢复,或提到"保存""save""checkpoint""挂起"
架构决策记录(ADR)。当面临技术选型、架构决策、方案取舍需要记录,或提到"ADR""决策记录""为什么这样做"
发布或导出检查 → Go/No-Go → 归档。当审查通过后需要上线或交付最终产物,或提到"发布""上线""ship""Go/No-Go"
合并 PR → 等待 CI → 验证生产。当 PR 已创建需要合并到主分支并验证部署,或提到"合并""merge""PR""land"
| name | define-workflow-refine |
| description | 从模糊想法变成明确的 spec。当有一个模糊的想法需要结构化收敛,或提到"提炼""收敛""需求""spec" |
| argument-hint | [feature-name 或模糊想法] |
领域: workflow | 宪法: 第 1(Surface Assumptions)、第 8(Manage Confusion)条
docs/features/YYYYMMDD-<name>/01-spec.md + 用户批准define-workflow-specrefine-artifacts.md(Goal Review 评分表、External Scan 模板、Scout Output 模板、Spec One-Pager 模板、好坏示例)/refine 主执行 persona 是 agents/requirements-analyst.md。
agents/refine-ceo-scout.md、agents/refine-eng-scout.md、agents/refine-design-scout.md、agents/refine-content-scout.md
artifact_type: software → 默认 CEO + Eng;涉及 UI / 合规 → 加 Designartifact_type: document / article → 默认 CEO + Contentartifact_type: deck → 默认 CEO + Content;涉及明显视觉/版式方向时加 Designartifact_type: visual → 默认 CEO + Design逐一询问澄清问题,一次一个,不列清单。优先用结构化提问工具(如 AskUserQuestion);不可用时退化为简短纯文本。
执行规则:
artifact_type,默认 software)、约束、上下文software / content / visual提出方案前,先判断是否需要搜索外部世界。使用当前宿主可用的 WebSearch/browser/文档检索。工具不可用时记录 "Search unavailable"。
执行规则:
artifact_type 非 software、引入新依赖、用户问"有没有已有方案"refine-artifacts.md)[可能过时];按产物类型搜索目标见 refine-artifacts.mdPhase 1 完成后、提出方案前,并行分派 scout 验证可行性。
执行规则:
refine-artifacts.md):Verdict + Evidence + Findings + Spec Impact提出 2-3 种方案,每种含优点和代价。
执行规则:
Step 1.1 探索项目上下文(5W1H 锚点执行规则 2)
Step 1.2 Scope 检查 — 多个独立子系统时先分解成子项目,只 refine 第一个
Step 1.2.5 Goal Review — 评分维度和模板见 refine-artifacts.md。10-12 = accepted;7-9 = needs-refinement;0-6 = blocked。小型变更可 skip 但要有完成标准
Step 1.3 5W1H 澄清(锚点执行)
Step 1.4 Phase 1.4:External Scan(锚点执行)
Step 1.5(可选)涉及 UI mockup/流程图时,单独一条消息询问是否用 browser 展示
Step 1.6 Scout Army(锚点执行)
基于 Phase 1 全部输入,提出 2-3 种方案并 Pressure Test(锚点执行)。
输出结构化 one-pager 到 docs/features/YYYYMMDD-<name>/01-spec.md。完整模板见 refine-artifacts.md。"不做清单"是 spec 最有价值的部分之一。
| 失败场景 | 处理方式 |
|---|---|
| 用户拒绝方向 | 问清原因,修正假设,回到 Phase 1 |
| 未能收敛到方案 | 扩大搜索范围或缩小目标范围 |
| 隐藏假设被推翻 | 更新假设集,评估影响,可能调整方向 |
| 发现已有类似方案 | 分析差别,确认需要新方案后才继续 |
| 范围暴增 | 分解为子项目,只 refine 第一个 |
| 说辞 | 现实 | 后果 |
|---|---|---|
| "这个很简单不需要设计" | 简单项目正是未检查假设导致最多返工的地方。 | 跳过澄清的"简单"项目返工 3-5x |
| "先做一个方向看看" | 单方案无法比较 trade-off。 | 方向错误发现时修复成本 10-50x |
| "之后再加这些功能" | MVP 的范围定义就是专注。不做清单比做清单更重要。 | 需求膨胀 → 发布延期 2-4 周 |
| "别问了,直接做吧" | 跳过澄清的问题一定会回来。15 分钟澄清 > 15 小时返工。 | 假设在实现阶段暴露,每次推翻增加 4-8 小时 |
# [功能名称] — Spec
artifact_type: [software/document/article/deck/visual]
delivery_class: [software/content/visual] # 仅在需要表达长期项目真相时使用
Goal Review Score: [score]/12 | Status: [accepted/needs-refinement/blocked]
One-line Goal: [一句话]
Done When: [Functional + Technical + Regression + Output]
Stop Conditions: [停止条件]
External References: [Fact/Pattern/Inference/Unknown/Adopt/Reject]
核心假设: [假设 — 验证方式]
MVP 范围: Include [最小可验证] / Exclude [明确排除]
不做清单: [事项 — 理由]
完整模板和好坏示例见 refine-artifacts.md。