/strategic-review
从CEO/战略视角进行商业价值评审,评估市场契合度、ROI、竞争优势、风险和战略对齐
$ npx -y skills add echoVic/boss-skill --skill strategic-review --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/strategic-review
Context preview
The summary Claude sees to decide when to auto-load this skill.
从CEO/战略视角进行商业价值评审,评估市场契合度、ROI、竞争优势、风险和战略对齐
SKILL.md
strategic-review.SKILL.mdname: pm/strategic-review
description: 从CEO/战略视角进行商业价值评审,评估市场契合度、ROI、竞争优势、风险和战略对齐
version: 1.0.0
agent: pm
type: methodology
user-invocable: true
agent-invocable: true
dependencies:
- pm/competitive-analysis
triggers:
- 用户请求战略评审或商业价值评估时
- 使用 /boss-review 命令时
- 需要从商业角度判断项目是否值得投入时
- 产品方向存在争议需要高层决策时
战略评审(Boss Review)
适用场景
当需要从 CEO/战略高度评估一个功能或项目的商业价值时使用。不同于技术评审关注实现质量,战略评审关注**做不做**和**为什么做**。
典型场景:
- 新功能立项前的价值论证
- 资源有限时的优先级决策
- 产品方向调整的论证
- 投资人/利益相关者沟通准备
核心方法
第一维度:市场契合度(Market Fit)
评估产品/功能与市场需求的匹配程度:
| 评估项 | 问题 | 评分标准 | |--------|------|----------| | 目标市场 | TAM/SAM/SOM 分别多大? | 清晰可量化 = 高分 | | 痛点强度 | 用户痛点是止痛药还是维生素? | 必须有 > 最好有 > 可以有 | | 时机 | 为什么是现在? | 有明确时间窗口 = 高分 | | 验证程度 | 有多少用户验证? | 付费验证 > 使用验证 > 口头验证 > 假设 |
第二维度:投资回报率(ROI)
量化投入产出比:
| 评估项 | 问题 | 评分标准 | |--------|------|----------| | 开发成本 | 需要多少人天? | 精确估算 = 高分 | | 运营成本 | 上线后持续投入? | 低维护 = 高分 | | 收益模型 | 直接/间接收益如何? | 有历史数据支撑 = 高分 | | 回收周期 | 多久能回本? | <3个月 = 优 / <6个月 = 良 / >12个月 = 需论证 | | 机会成本 | 不做什么来做这个? | 机会成本可控 = 高分 |
第三维度:竞争优势(Competitive Advantage)
评估护城河和差异化:
| 评估项 | 问题 | 评分标准 | |--------|------|----------| | 技术壁垒 | 竞对复制需要多久? | >6个月 = 强壁垒 | | 网络效应 | 用户越多越好用吗? | 有强网络效应 = 高分 | | 数据优势 | 有独占数据资产吗? | 数据不可替代 = 高分 | | 品牌认知 | 能否建立心智定位? | 有清晰定位 = 高分 | | 切换成本 | 用户迁移难度? | 高切换成本 = 高分 |
第四维度:风险矩阵(Risk Assessment)
识别和评估风险:
| 风险类型 | 评估要素 | 缓解方案 | |----------|----------|----------| | 市场风险 | 需求是否真实、市场是否足够大 | MVP 验证、用户访谈 | | 技术风险 | 是否有未验证的技术假设 | 技术 spike、原型验证 | | 执行风险 | 团队是否有能力按时交付 | 分阶段交付、招聘计划 | | 合规风险 | 是否涉及法规/政策限制 | 法务咨询、合规审查 | | 依赖风险 | 是否依赖不可控的外部因素 | 备选方案、合同约束 |
第五维度:战略对齐(Strategic Alignment)
评估与公司战略的一致性:
| 评估项 | 问题 | 评分标准 | |--------|------|----------| | 愿景匹配 | 与公司3-5年愿景一致吗? | 强关联 = 高分 | | 能力杠杆 | 能否复用现有优势? | 高杠杆 = 高分 | | 协同效应 | 与其他产品线有协同吗? | 1+1>2 = 高分 | | 资源匹配 | 现有资源能否支撑? | 资源充足 = 高分 |
评审决策框架
综合评分规则
每个维度 1-5 分,加权计算综合分:
- 市场契合度:权重 30%
- ROI:权重 25%
- 竞争优势:权重 20%
- 风险评估:权重 15%(此项为风险可控程度)
- 战略对齐:权重 10%
决策映射
| 综合分 | 决策 | 说明 | |--------|------|------| | ≥ 4.0 | ✅ 推进 | 全力推进,优先分配资源 | | 3.0 - 3.9 | ⚠️ 需调整 | 方向正确但需优化具体方案 | | < 3.0 | ❌ 暂缓 | 暂不投入,需重新论证或等待时机 |
输出要求
使用 `strategic-review.md.template` 模板输出到 `.boss/<feature>/strategic-review.md`,包含:
1. **执行摘要**:商业价值评级(1-5)、推荐决策、关键洞察(1-2句) 2. **五维分析详情**:每个维度的评分和关键判断依据 3. **风险矩阵表**:风险项 × 影响程度 × 发生概率 × 缓解方案 4. **战略建议**:具体的行动建议(推进/调整/暂缓的理由和下一步) 5. **关键假设**:列出评审中的关键假设,标注验证状态
Read more
name: pm/strategic-review description: 从CEO/战略视角进行商业价值评审,评估市场契合度、ROI、竞争优势、风险和战略对齐 version: 1.0.0 agent: pm type: methodology user-invocable: true agent-invocable: true dependencies: - pm/competitive-analysis triggers: - 用户请求战略评审或商业价值评估时 - 使用 /boss-review 命令时 - 需要从商业角度判断项目是否值得投入时 - 产品方向存在争议需要高层决策时
战略评审(Boss Review)
适用场景
当需要从 CEO/战略高度评估一个功能或项目的商业价值时使用。不同于技术评审关注实现质量,战略评审关注**做不做**和**为什么做**。
典型场景:
- 新功能立项前的价值论证
- 资源有限时的优先级决策
- 产品方向调整的论证
- 投资人/利益相关者沟通准备
核心方法
第一维度:市场契合度(Market Fit)
评估产品/功能与市场需求的匹配程度:
| 评估项 | 问题 | 评分标准 | |--------|------|----------| | 目标市场 | TAM/SAM/SOM 分别多大? | 清晰可量化 = 高分 | | 痛点强度 | 用户痛点是止痛药还是维生素? | 必须有 > 最好有 > 可以有 | | 时机 | 为什么是现在? | 有明确时间窗口 = 高分 | | 验证程度 | 有多少用户验证? | 付费验证 > 使用验证 > 口头验证 > 假设 |
第二维度:投资回报率(ROI)
量化投入产出比:
| 评估项 | 问题 | 评分标准 | |--------|------|----------| | 开发成本 | 需要多少人天? | 精确估算 = 高分 | | 运营成本 | 上线后持续投入? | 低维护 = 高分 | | 收益模型 | 直接/间接收益如何? | 有历史数据支撑 = 高分 | | 回收周期 | 多久能回本? | <3个月 = 优 / <6个月 = 良 / >12个月 = 需论证 | | 机会成本 | 不做什么来做这个? | 机会成本可控 = 高分 |
第三维度:竞争优势(Competitive Advantage)
评估护城河和差异化:
| 评估项 | 问题 | 评分标准 | |--------|------|----------| | 技术壁垒 | 竞对复制需要多久? | >6个月 = 强壁垒 | | 网络效应 | 用户越多越好用吗? | 有强网络效应 = 高分 | | 数据优势 | 有独占数据资产吗? | 数据不可替代 = 高分 | | 品牌认知 | 能否建立心智定位? | 有清晰定位 = 高分 | | 切换成本 | 用户迁移难度? | 高切换成本 = 高分 |
第四维度:风险矩阵(Risk Assessment)
识别和评估风险:
| 风险类型 | 评估要素 | 缓解方案 | |----------|----------|----------| | 市场风险 | 需求是否真实、市场是否足够大 | MVP 验证、用户访谈 | | 技术风险 | 是否有未验证的技术假设 | 技术 spike、原型验证 | | 执行风险 | 团队是否有能力按时交付 | 分阶段交付、招聘计划 | | 合规风险 | 是否涉及法规/政策限制 | 法务咨询、合规审查 | | 依赖风险 | 是否依赖不可控的外部因素 | 备选方案、合同约束 |
第五维度:战略对齐(Strategic Alignment)
评估与公司战略的一致性:
| 评估项 | 问题 | 评分标准 | |--------|------|----------| | 愿景匹配 | 与公司3-5年愿景一致吗? | 强关联 = 高分 | | 能力杠杆 | 能否复用现有优势? | 高杠杆 = 高分 | | 协同效应 | 与其他产品线有协同吗? | 1+1>2 = 高分 | | 资源匹配 | 现有资源能否支撑? | 资源充足 = 高分 |
评审决策框架
综合评分规则
每个维度 1-5 分,加权计算综合分:
- 市场契合度:权重 30%
- ROI:权重 25%
- 竞争优势:权重 20%
- 风险评估:权重 15%(此项为风险可控程度)
- 战略对齐:权重 10%
决策映射
| 综合分 | 决策 | 说明 | |--------|------|------| | ≥ 4.0 | ✅ 推进 | 全力推进,优先分配资源 | | 3.0 - 3.9 | ⚠️ 需调整 | 方向正确但需优化具体方案 | | < 3.0 | ❌ 暂缓 | 暂不投入,需重新论证或等待时机 |
输出要求
使用 `strategic-review.md.template` 模板输出到 `.boss/<feature>/strategic-review.md`,包含:
1. **执行摘要**:商业价值评级(1-5)、推荐决策、关键洞察(1-2句) 2. **五维分析详情**:每个维度的评分和关键判断依据 3. **风险矩阵表**:风险项 × 影响程度 × 发生概率 × 缓解方案 4. **战略建议**:具体的行动建议(推进/调整/暂缓的理由和下一步) 5. **关键假设**:列出评审中的关键假设,标注验证状态
Boss is an auditable agent-team workflow for coding agents. It turns one coding agent into a structured engineering team: PM, Architect, UI Designer, Tech Lead, Scrum Master, Frontend, Backend, QA, and DevOps.
Repo: echoVic/boss-skill
Other skills on boss.
- /architecture-design
系统架构设计方法论,包含架构模式选择、系统分层、目录结构设计
Open skill - /data-api-design
数据模型和API设计方法论,包含ERD设计、数据字典、RESTful API规范
Open skill - /tech-research
技术调研方法论,通过系统性调研和对比分析,为技术选型提供数据支持
Open skill - /api-development
后端API开发方法论,包括RESTful/GraphQL设计、请求验证、错误处理和安全实现
Open skill - /testing-guide
后端测试编写指南,包括单元测试、集成测试和E2E测试的编写方法和最佳实践
Open skill - /brainstorming
需求澄清 Skill。当用户只给了模糊描述时自动触发,通过业务提问把一句话翻译成完整需求,交给 Boss 流水线执行。 Triggers: '我想做一个', '帮我做', '有个想法', 'brainstorm', '帮我规划一下', '做个XX', 'I want to build' Does NOT trigger: - 需求已经完整(包含做什么 + 给谁用 + 核心场景) - 纯技术问题或 bug 修复 Output: .boss/<feature>/design-brief.md 需求设计简报
Open skill

