executive-summary

执行摘要

根据 Sherpy 规划文档生成面向高管的摘要文档，帮助非技术利益相关者清晰了解业务问题、解决方案、时间线和成功标准。

用法

/executive-summary [base-directory]

如果未提供目录，则自动在当前目录中查找 requirements/business-requirements.yaml 并据此确定目录。

如果未找到，则提示用户：“你的规划文档位于哪里？”

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

必需文档

此技能会根据标准 Sherpy 文件夹结构自动发现以下文件：

文件	位置	用途
business-requirements.yaml	requirements/	业务问题、功能、成功指标
technical-requirements.yaml	requirements/	技术背景、风险、依赖项
timeline.yaml	delivery/	交付时间线和里程碑

流程

第 1 步：确定基础目录并扫描必需文档

如果未提供目录参数，则检查当前目录中是否存在 requirements/business-requirements.yaml。

• 如果找到，则将当前目录用作 base_directory
• 如果未找到，则提示：“你的规划文档位于哪里？”并等待用户回复

确定 base_directory 后，在标准位置扫描必需文件。显示状态：

## Executive Summary — Dependency Check

Scanning for required artifacts...

 ✓  requirements/business-requirements.yaml
 ✓  requirements/technical-requirements.yaml
 ✓  delivery/timeline.yaml

3 of 3 required files found.

图例： ✓ 已找到 · ✗ 缺失

第 2 步：处理缺失文件

如果缺少任何必需文件，则询问：

“缺少必需文件：timeline.yaml

选项：

1. 使用部分数据继续 — 根据现有信息生成摘要（缺失的部分将标记为 [Not Available]）
2. 退出 — 先补齐缺失文档（运行 /delivery-timeline 以生成 timeline.yaml）

你想怎么做？”

等待用户回复：

• 如果用户选择 1（继续）：使用现有数据继续，并清晰标记缺失部分
• 如果用户选择 2（退出）：显示要运行的技能并正常退出

第 3 步：加载并解析文档

读取所有可用文件并提取：

从 business-requirements.yaml 中提取：

• 项目名称和描述
• 业务目标和问题陈述
• 目标用户和用户画像
• 核心功能和能力
• 成功标准和 KPI
• 范围和限制条件

从 technical-requirements.yaml 中提取：

• 解决方案架构概述
• 技术风险和依赖项
• 外部集成
• 合规与安全要求
• 资源需求（团队、基础设施）

从 timeline.yaml 中提取（如果可用）：

• 里程碑交付日期
• 生产环境部署日期
• 项目总时长
• QA 和评审阶段

第 4 步：生成执行摘要

创建 summaries/executive-summary.md。

输出文档包括：标题（时间戳、项目名称）、Business Problem（当前状态、业务影响）、Solution Overview（方法、优势）、Key Features & Capabilities（按类别分组）、Timeline & Milestones（含日期的表格）、Success Metrics（主要和次要指标）、Risks & Dependencies（风险表、外部依赖、假设）、Resource Requirements（团队、基础设施、时间投入）和 Conclusion。

完整的文档规范（包括章节结构、写作指南和格式规则）请参阅 references/output-spec.md。

完整示例请参阅 references/example.md。

第 5 步：妥善处理缺失数据

缺少必需文件时，插入明确的占位内容：

## Timeline & Milestones

[Not Available - `timeline.yaml` not found. Run `/delivery-timeline` to generate delivery timeline.]

**Estimated Duration:** [If milestones.yaml exists, sum milestone estimates]
**Target Completion:** TBD

部分数据缺失时：

## Risks & Dependencies

### Technical Risks
[Not Available - detailed risk analysis requires `technical-requirements.yaml`]

### External Dependencies
- [List any dependencies mentioned in available documents]

第 6 步：确认

生成摘要后，显示：

## Executive Summary Generated ✓

**Location:** summaries/executive-summary.md
**Size:** [file size]

Summary includes:
  ✓ Business problem statement
  ✓ Solution overview
  ✓ Key features & capabilities
  ✓ Timeline & milestones
  ✓ Success metrics
  ✓ Risks & dependencies
  ✓ Resource requirements

The summary is ready for stakeholder review and communication.

内容提取逻辑

业务问题部分

来源： business-requirements.yaml

从以下字段提取：

• description 或 overview - 整体背景
• business_goals.primary_goal - 主要业务驱动因素
• problem_statement - 明确的问题描述
• why 或 rationale - 这为何重要

结构：

1. 当前状态 - 目前的情况，以及存在的问题
2. 业务影响 - 现状带来的成本、低效和风险

写作指南：

• 使用业务语言，避免技术术语
• 尽可能量化影响（成本、时间、受影响用户）
• 关注业务价值，而非技术挑战
• 内容具体明确

示例：

“客户支持团队目前无法了解系统的实时状态，需要手动检查多个仪表板，导致事件响应延迟。这种信息分散的状况使平均 MTTR 达到 45 分钟，每年因生产力损失和客户流失造成约 $150K 的损失。”

解决方案概述部分

来源： business-requirements.yaml + technical-requirements.yaml

从以下内容提取：

• solution_overview 或 proposed_solution
• architecture.approach - 高层技术方案（转述为业务语言）
• key_capabilities - 系统将提供的功能

结构：

1. 方案 - 我们要构建什么（非技术性描述）
2. 收益 - 如何解决问题

写作指南：

• 将技术概念转化为业务价值
• 关注成果，而非实现方式
• 说明解决方案如何解决问题
• 突出差异化特点或主要优势

示例：

“我们将构建一个统一的监控仪表板，在单一界面中汇总系统运行状况指标、警报和事件历史记录。该解决方案可帮助支持团队在几分钟内发现并响应事件，将 MTTR 降低 70%，并提升客户满意度。”

关键功能部分

来源： business-requirements.yaml

从以下内容提取：

• functional_requirements - 具体功能
• features 或 capabilities - 功能列表
• user_stories - 面向用户的功能

分类：

• 将相关功能分组
• 使用便于业务理解的类别名称
• 关注用户可以做什么，而非功能如何实现

类别示例：

• 用户管理
• 数据与分析
• 集成
• 自动化
• 报告
• 安全与合规

每项功能的格式：

- **[Feature Name]** - [Business value / what it enables]

示例：

### Monitoring & Alerting
- **Real-Time Status Dashboard** - View system health across all services at a glance
- **Smart Alert Routing** - Automatically notify the right team based on alert severity and service ownership
- **Historical Trends** - Identify patterns and predict potential issues before they impact users

时间线与里程碑部分

来源： timeline.yaml（优先）或 milestones.yaml（备用）

从 timeline.yaml 提取：

• 提取 workback.project_start
• 提取 workback.production_deploy
• 提取时间线中的里程碑日期
• 提取 QA 轮次及持续时间

从 milestones.yaml 提取（timeline 不可用时）：

• 汇总 estimated_duration，计算总时长
• 列出里程碑顺序
• 注明此估算为初步结果，未包含 QA/PR 时间

呈现方式：

• 使用表格清晰展示里程碑
• 突出关键交付日期
• 展示开发、QA 和部署阶段
• 便于快速浏览

成功指标部分

来源： business-requirements.yaml

从以下内容提取：

• success_criteria - 明确的成功衡量标准
• measurable_outcomes - 可量化的目标
• kpis 或 metrics - 跟踪指标

分类：

• 主要指标 - 必须达成的目标（通常与业务目标相关）
• 次要指标 - 有则更好的改进项

格式：

- **[Metric Name]:** [Target value] - [What this measures and why it matters]

示例：

### Primary Metrics
- **Mean Time to Resolution (MTTR):** < 15 minutes - Measures incident response speed and system reliability
- **Customer Satisfaction Score:** > 4.5/5.0 - Indicates user satisfaction with support response

风险与依赖项部分

来源： technical-requirements.yaml

从以下内容提取：

• risks - 技术和项目风险
• external_dependencies - 第三方服务、API、团队
• constraints - 限制或要求
• assumptions - 假设为真的条件

风险表格列：

• 风险 - 清晰描述可能出错的事项
• 影响 - 高/中/低严重程度
• 缓解措施 - 如何应对风险

依赖项格式：

- **[Dependency Name]:** [What it provides, who owns it, current status]

示例：

### External Dependencies
- **Stripe Payment API:** Payment processing service, owned by Finance team, production-ready
- **SendGrid Email Service:** Transactional emails, third-party SaaS, requires account setup (in progress)

资源需求部分

来源： technical-requirements.yaml + business-requirements.yaml + timeline.yaml

从以下内容提取：

• 技术需求中的 resources 部分
• 业务需求中的 team 或 stakeholders
• 用于计算资源容量的时间线时长

结构：

• 团队 - 角色、规模、投入时间
• 基础设施 - 所需的关键技术资源
• 时间线承诺 - 总时长和资源容量

示例：

### Team
- **Development Team:** 3 engineers (2 backend, 1 frontend), full-time for 8 weeks
- **QA/Testing:** 1 QA engineer, 2 weeks during QA phases
- **Product:** 0.5 FTE for requirements and acceptance
- **DevOps:** 0.25 FTE for infrastructure setup and deployment

### Infrastructure
- PostgreSQL database (AWS RDS)
- Redis cache cluster
- Kubernetes cluster (existing infrastructure)
- Estimated cloud costs: $500/month

错误处理

文件未找到

如果必需文件不存在：

• 首先检查标准的 docs/ 位置
• 找不到时检查根目录
• 显示尝试查找的确切路径
• 建议使用哪个 Sherpy 技能生成该文件

YAML 无效

如果文件无法解析：

• 显示清晰的解析错误
• 显示文件路径和行号
• 建议重新生成文件

缺少必需字段

如果缺少预期字段：

• 使用「[Not Specified]」占位符
• 根据现有数据继续处理
• 在确认信息中注明缺失内容

输出位置

始终输出到：{base_directory}/summaries/executive-summary.md

如果目录不存在，则创建该目录：

mkdir -p {base_directory}/summaries

写作风格指南

语气

• 专业、清晰
• 使用非技术性语言
• 聚焦业务价值
• 对风险保持自信但务实的态度

受众

• C 级高管
• 产品经理
• 业务相关方
• 非技术决策者

避免

• 未加解释的技术术语
• 实施细节
• 代码或命令引用
• 未定义的缩写词

包含

• 业务影响和价值
• 清晰的时间线和承诺
• 可衡量的成果
• 对风险的说明及缓解措施

与 Sherpy Flow 集成

此技能设计为在 /sherpy-flow 的第 10 步中作为最后一部分调用，并在 /developer-summary 之后执行。由 sherpy-flow 调用时，它会接收 base_directory 作为参数。它应当：

• 在所有规划文档完成后运行
• 从 base_directory 中整理好的文件夹结构自动发现文件
• 如果缺少可选部分，不应失败
• 所有文件齐全时，无需用户交互即可生成摘要

示例

完整的执行摘要示例请参见 references/example.md。

相关技能

• /developer-summary - 生成面向开发者的技术摘要
• /sherpy-flow - 完整的规划工作流（最后包含此技能）
• /business-requirements-interview - 生成 business-requirements.yaml
• /technical-requirements-interview - 生成 technical-requirements.yaml
• /delivery-timeline - 生成 timeline.yaml