sherpy-flow

Sherpy Flow

从头到尾运行完整的 Sherpy 规划流程。根据现有产物检测你当前所处的工作流阶段，并从该阶段继续。你不必记住接下来要使用哪个技能，也不必记住它需要哪些输入。

用法

/sherpy-flow [output-directory]

如果未提供目录，请提示用户：“应将规划文档创建到哪里？”

等待用户提供路径后再继续。

流程

Step 1   Gap Analysis Worksheet         → gap-analysis-worksheet.md
Step 2   Business Requirements          → business-requirements.yaml
Step 3   Technical Requirements         → technical-requirements.yaml
Step 4   Style Anchors Collection       → style-anchors/index.yaml + *.md
Step 5   Implementation Planner         → milestones.yaml + milestone-m*.tasks.yaml (with optional acceptance_criteria)
Step 6   UX/Wireframe Planning          → wireframe-spec.yaml + wireframes/*.pen (conditional: auto-skips if no UI changes)
Step 7   Implementation Plan Review     → implementation-plan-review.yaml
Step 8   Architecture Decision Records  → adrs/INDEX.md + adrs/ADR-*.md
Step 9   Delivery Timeline              → timeline.yaml
Step 10  QA Test Plan                   → qa-test-plan.yaml
Step 11  Generate Summaries             → developer-summary.md + executive-summary.md

所有产物都会自动整理到：

<output-directory>/
├── requirements/       (requirements, gap analysis)
├── implementation/
│   ├── milestones.yaml (with optional acceptance_criteria)
│   └── tasks/          (milestone task files)
├── ux/                 (wireframe spec + Pencil wireframes)
│   ├── wireframe-spec.yaml
│   ├── wireframes.pen
│   └── PAGE-001.png
├── delivery/           (timeline, QA test plan)
├── architecture/
│   └── adrs/           (ADRs)
├── artifacts/          (reviews, interview transcripts, style anchors, CONTINUE.md, etc.)
└── summaries/          (developer & executive summaries)

流程说明

步骤 0：确定输出目录

如果未将目录作为参数提供，请提示用户：

“应将规划文档创建到哪里？”

等待用户回复。将所提供的路径存储为 base_directory。

此阶段不要创建任何文件夹。 各技能会在生成文件时按需创建文件夹。

步骤 1：扫描现有产物

检查 base_directory 中是否存在以下整理结构中的文件：

产物	预期位置	表示已完成的步骤
gap-analysis-worksheet.md	requirements/	步骤 1
business-requirements.yaml	requirements/	步骤 2
technical-requirements.yaml	requirements/	步骤 3
style-anchors/index.yaml	artifacts/style-anchors/	步骤 4
milestones.yaml	implementation/	步骤 5
milestone-m*.tasks.yaml	implementation/tasks/	步骤 5
wireframe-spec.yaml	ux/	步骤 6
implementation-plan-review.yaml	artifacts/	步骤 7
adrs/INDEX.md	architecture/adrs/	步骤 8
timeline.yaml	delivery/	步骤 9
qa-test-plan.yaml	delivery/	步骤 10
developer-summary.md	summaries/	步骤 11
executive-summary.md	summaries/	步骤 11

产物检测逻辑：

• 检查 base_directory 中的预期位置
• 如果文件存在，则视为该步骤已完成
• 技能会在生成文件时按需创建文件夹

步骤 2：显示流程状态

开始任何工作之前，显示流程的可视化状态：

## Sherpy Flow — [Project Directory]

 ✓  Step 1   Gap Analysis Worksheet
 ✓  Step 2   Business Requirements
 →  Step 3   Technical Requirements        ← resuming here
 ○  Step 4   Style Anchors Collection
 ○  Step 5   Implementation Planner
 ○  Step 6   UX/Wireframe Planning
 ○  Step 7   Implementation Plan Review
 ○  Step 8   Architecture Decision Records
 ○  Step 9   Delivery Timeline
 ○  Step 10  QA Test Plan
 ○  Step 11  Generate Summaries

Resuming from Step 3. Type "start over" to restart from Step 1,
or specify a step number to jump to a specific point.

图例： ✓ 已完成 · → 当前 · ○ 待处理

然后询问：

“准备从步骤 [n]：[步骤名称] 继续吗？（yes / start over / jump to step N）”

等待确认后再继续。

步骤 3：执行各个步骤

对于每个待处理步骤，将 base_directory 作为参数传递给对应技能并调用。每个步骤的行为与单独调用该技能时完全相同——sherpy-flow 是一个顺序执行器，而非替代品。

关键执行规则：

1. 未经用户明确确认，绝不进入下一步——每完成一步后都必须等待
2. 不得自动跳过步骤 4（样式锚点收集）——如果用户想跳过，始终先询问并显示风险警告
3. 如果某个步骤所需的输入不存在（例如，步骤 5 需要样式锚点），请停止并在继续前警告用户

重要： 将 base_directory 传递给每个技能，以便在正确位置创建文件。技能会在生成输出时创建所需文件夹。

每个技能都负责将文件输出到 base_directory 中的正确位置。 无需在技能运行后整理文件——技能从一开始就会在正确位置创建文件夹和文件。

预期输出位置

调用技能时，将 base_directory 作为参数传递（否则，技能会通过查找 requirements/business-requirements.yaml 自动检测）：

需求文档：

• gap-analysis-worksheet.md → {base_directory}/requirements/
• business-requirements.yaml → {base_directory}/requirements/
• technical-requirements.yaml → {base_directory}/requirements/

实施文档：

• milestones.yaml → {base_directory}/implementation/
• milestone-m*.tasks.yaml → {base_directory}/implementation/tasks/ 交付文档：
• timeline.yaml → {base_directory}/delivery/
• qa-test-plan.yaml → {base_directory}/delivery/

架构文档：

• adrs/INDEX.md + ADR-*.md → {base_directory}/architecture/adrs/

制品/评审文档：

• business-interview.jsonl → {base_directory}/artifacts/
• technical-interview.jsonl → {base_directory}/artifacts/
• style-anchors/index.yaml + *.md → {base_directory}/artifacts/style-anchors/
• implementation-plan-review.yaml → {base_directory}/artifacts/
• CONTINUE.md → {base_directory}/artifacts/
• FEATURE_FLAGS.md → {base_directory}/artifacts/
• UPDATES.md → {base_directory}/artifacts/

摘要文档：

• developer-summary.md → {base_directory}/summaries/
• executive-summary.md → {base_directory}/summaries/

步骤 1 — 差距分析工作表（/gap-analysis-worksheet）

• 如果项目目录中没有初始需求文档，则跳过此步骤。
• 如果存在初始需求文档（任何 .md、.txt 或 .docx 描述的文件），请针对该文档运行差距分析。
• 完成后，询问：“差距分析工作表已生成。是否继续进行业务需求访谈？”

步骤 2 — 业务需求访谈（/business-requirements-interview）

• 运行完整的访谈流程（一次提出一个问题，并在 business-interview.jsonl 中跟踪进度）。
• 生成 business-requirements.yaml 后，显示摘要并询问：“业务需求已完成。是否继续进行技术需求访谈？”

步骤 3 — 技术需求访谈（/technical-requirements-interview）

• 需要 business-requirements.yaml。
• 运行完整的访谈流程。
• 生成 technical-requirements.yaml 后，显示摘要并询问：“技术需求已完成。是否继续收集风格锚点？”

步骤 4 — 风格锚点收集（/style-anchors-collection）— 必须执行

• 需要 technical-requirements.yaml。
• 重要：不得跳过此步骤。风格锚点可防止实现过程中的架构偏移。
• 以交互方式收集展示已批准模式的代码示例。
• 对于技术需求中识别出的每种模式：
  • 请用户提供文件路径和行范围
  • 记录该模式展示的内容
  • 指定何时使用该模式
• 生成包含单独 .md 文件和 index.yaml 的 style-anchors/ 目录。
• 如果用户想跳过：询问“跳过风格锚点会显著增加偏移风险。确定要跳过吗？（输入 yes 跳过 / 输入 no 收集锚点）”
• 完成后，按类别显示锚点数量并询问：“风格锚点已收集。是否继续进行实现规划？”

步骤 5 — 实现规划器（/implementation-planner）

• 需要 business-requirements.yaml、technical-requirements.yaml。
• 强烈建议：使用步骤 4 生成的 style-anchors/index.yaml。
• 运行前：

  1. 如果不存在风格锚点，请停止并询问：

     “⚠️ 未找到风格锚点。生成的实现计划将不包含具体代码示例，这会显著增加架构偏移风险。

     你想要：

     1. 返回步骤 4 并立即收集风格锚点（推荐）
     2. 不使用风格锚点继续（不推荐）”

     • 如果用户选择选项 1，返回步骤 4。
     • 如果用户选择选项 2，请确认：“正在不使用风格锚点的情况下继续。预计实现过程中会出现更大的偏移。继续吗？（yes/no）”

  2. 提出受众选择问题：

     "此实施计划的主要受众是谁？

     1. AI Agent — 为自主开发提供完整的规范性细节
     2. Human Developers — 为经验丰富的团队提供高层次指导
     3. Hybrid — 为混合团队或结对编程提供适度细节

     这会影响任务说明的详细程度。AI Agent 会获得逐步的实施指导，而 Human Developers 只会获得高层次的目标和约束。"

  3. 等待用户回复，并通过 target_audience 参数传递给 implementation-planner skill。

• 生成 milestones.yaml + milestone-m*.tasks.yaml。
• 如果已收集，Step 4 中的风格参考会自动在任务说明中引用。
• 完成后，显示里程碑摘要并询问：“已生成实施计划。继续进行 UX/线框图规划吗？”

Step 6 — UX/线框图规划（/ux-wireframe-planning）— 有条件

• 需要 milestones.yaml + 任务文件 + technical-requirements.yaml。
• **检测：**扫描技术栈和任务文件，查找 UI/网页应用变更（React、.tsx 文件、组件、页面）。
• 如果没有 UI 变更：自动跳过。生成 wireframe-spec.yaml，其中 has_ui_changes: false。在管线状态中记录跳过情况。无需用户确认。
• 如果发现 UI 变更：生成 wireframe-spec.yaml，创建独立的 Pencil 线框图文件（wireframes.pen，包含所有组件和页面框架），并导出 PNG 预览图。
• 完成后（如果未跳过），显示页面/组件数量并询问：“已生成线框图。继续进行计划审查吗？”

Step 7 — 实施计划审查（/implementation-plan-review）

• 需要 milestones.yaml + 任务文件。
• 运行完整审查。
• 生成 implementation-plan-review.yaml 后，显示就绪度评分和关键问题。
• 如果存在关键问题，询问：

  "计划审查发现 [n] 个关键问题。你想要：

  1. 现在解决问题（返回 Step 5）
  2. 知悉问题后继续
  3. 先详细审查这些问题"

• 否则询问：“计划审查已通过。继续记录架构决策吗？”

Step 8 — 架构决策记录（/architecture-decision-record）

• 需要 technical-requirements.yaml。
• 生成包含所有 ADR 文件的 adrs/ 目录。
• 完成后，显示 ADR 数量并询问：“已记录架构决策。继续制定交付时间线吗？”

Step 9 — 交付时间线（/delivery-timeline）

• 需要 milestones.yaml。
• 按该 skill 中的定义，询问三个交付参数问题（生产部署日期、QA 轮次、每轮天数）。
• 生成 timeline.yaml。
• 完成后，显示倒排计划摘要（项目开始 → 部署日期）并询问：“已生成交付时间线。继续制定 QA 测试计划吗？”

Step 10 — QA 测试计划（/qa-test-plan）

• 需要 business-requirements.yaml + technical-requirements.yaml。
• 生成 qa-test-plan.yaml。
• 完成后，显示覆盖范围摘要并询问：“已生成 QA 测试计划。继续生成摘要吗？”

Step 11 — 生成摘要（/developer-summary + /executive-summary）

• 需要：business-requirements.yaml、technical-requirements.yaml、milestones.yaml、timeline.yaml。
• 先运行 /developer-summary，生成面向开发者的摘要。
• 然后运行 /executive-summary，生成面向高管/利益相关者的摘要。
• 两个 skill 都会从 docs/ 文件夹结构中自动查找所需文件。
• 生成两个摘要后，显示确认信息并进入最终摘要。

Step 4：最终摘要

完成所有步骤后，显示最终摘要：

## Sherpy Flow Complete ✓

**Project:** [name]
**Directory:** [path]

All artifacts organized in: [base_directory]/

📋 Requirements
  ✓ gap-analysis-worksheet.md       [if generated]
  ✓ business-requirements.yaml
  ✓ technical-requirements.yaml

🔨 Implementation
  ✓ milestones.yaml
  ✓ tasks/milestone-m*.tasks.yaml   ([n] task files)

🚀 Delivery
  ✓ timeline.yaml
  ✓ qa-test-plan.yaml

🏛️ Architecture
  ✓ adrs/INDEX.md + ADR-*.md        ([n] decision records)

📊 Summaries
  ✓ developer-summary.md
  ✓ executive-summary.md

📁 Artifacts
  ✓ implementation-plan-review.yaml
  ✓ business-interview.jsonl
  ✓ technical-interview.jsonl
  ✓ style-anchors/index.yaml + [n] anchor files

Timeline: [project start date] → [production deploy date]
Total Delivery Days: [n] business days
QA Rounds: [n] × [n] days each

Your project is fully planned and ready for development!

Next Steps:
- Review summaries/ for project overview
- Start development with implementation/milestones.yaml
- Use /create-continuation-prompt to hand off context to a new session

过渡规则

• 关键：务必确认后再进入下一步——绝不自动推进。每一步完成后都要等待用户明确确认。
• 步骤 4（风格锚点）为必做步骤：除非用户明确要求跳过，并在看到风险警告后再次确认，否则不得跳过此步骤。
• 返回上一步：如果用户说“返回”或“重做步骤 N”，则返回该步骤并重新运行。新的输出会覆盖之前的产物。
• 跳过：如果用户说“跳过步骤 N”：
  • 如果 N == 4（风格锚点）：显示有关风格偏移风险的警告，并要求用户明确回复“确认跳过”
  • 对于其他步骤：标记为已跳过，并在最终摘要中注明。若后续步骤需要其输出但输入缺失，则发出警告。
• 跳转：如果用户说“跳转到步骤 N”，则从该步骤开始运行后续流程。加载现有产物中的所有必需输入。
• 中断：如果用户需要在流程中途停止，提醒他们可以再次运行 /sherpy-flow 以继续——流水线状态会准确显示他们上次停在何处。