# Shape Up Project Shaping

> Shape and gate new product ideas, AI features, MVPs, project kickoffs, scope changes, and cycle-end decisions before implementation. Use when a user wants to clarify an idea, define a problem, set an appetite, write a Shape Up pitch, identify rabbit holes and no-gos, decide whether to bet, coordinate multiple coding agents, prevent scope creep, or choose Ship, Reshape, or Kill. Do not use for tiny, already-scoped edits where the user explicitly wants immediate implementation.

- Skill: `lora-sys/shape-up-project-shaping` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add lora-sys/shape-up-project-shaping`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lora-sys/shape-up-project-shaping/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: lora-sys (https://skillmd.com/u/lora-sys)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lora-sys/shape-up-project-shaping

---


# Shape Up Project Shaping

把模糊想法塑形成一个值得下注、边界清楚、可在固定周期内交付并能用证据验收的项目。

默认先完成 **Shape → Bet → Build → Evidence → Ship / Reshape / Kill**。不要把“马上生成代码”误认为进展。

## 核心行为

1. 先定义问题与当前替代方案，再讨论功能。
2. 用 `Appetite` 限制投入，不先承诺完整需求再估工期。
3. 输出足够具体但保留实现空间的方案轮廓。
4. 必须识别 `Rabbit Holes`、`No-Gos` 和关键假设。
5. 只有达到下注标准后才进入开发 Brief。
6. Solo 模式：Shaper 直接输出 Pitch + Evidence Gate，无需 Agent Brief。多 Agent 模式：所有 Agent 必须共享同一份 Pitch 和 Evidence Gate，使用 Agent Brief 模板。
7. 周期结束不得默认延期；明确选择 `Ship`、`Reshape` 或 `Kill`。
8. 把事实、证据、假设和个人判断分开标注。

## 触发模式

根据请求选择一个模式；不要求用户知道模式名称。

- `shape`：新想法、模糊需求、开工前梳理、MVP 范围。
- `bet`：已有 Pitch，需要判断是否值得投入。
- `kickoff`：已下注，需要生成单团队或多 Agent 开发 Brief。
- `scope-review`：开发中出现新需求、风险、延期或范围漂移。
- `cycle-review`：周期结束，决定 Ship / Reshape / Kill。
- `full-cycle`：用户要求从想法一路整理到可开工材料。

## 第零步：读取现有上下文

优先读取用户已经提供的 PRD、README、Issue、对话、仓库或调研，不重复询问已知信息。

缺少信息时：

- 能合理推断的，生成带 `[假设]` 标记的草案。
- 只有会改变下注结论的关键缺口才提问。
- 一次最多提出 5 个高杠杆问题；不要开启无限访谈。
- 用户要求直接产出时，先做最佳努力版本，再列出未验证假设。

## 一、Shape：塑形

### 1. 问题与 Baseline

明确：

- 用户是谁。
- 在什么触发场景发生。
- 当前做法或替代方案是什么。
- 痛点频率、损失或阻力是什么。
- 为什么现在值得处理。

禁止用产品答案代替问题。比如不要把“需要一个 AI 工作台”当作问题。

### 2. Appetite：投入上限

先回答“这个问题最多值得投入多久”，再调整方案范围。

默认建议：

- 探索或技术风险验证：1–3 天。
- 独立开发者 MVP：1–2 周。
- 小团队完整项目：可使用 Shape Up 原始六周周期。

这些是默认值，不是教条。必须结合价值、风险、团队规模和机会成本说明理由。

### 3. Solution：方案轮廓

描述核心交互和系统行为，不提前写完所有设计与任务：

- 关键入口与触发。
- 用户主路径。
- 系统关键决策。
- 结束状态。
- 必要数据或集成。

需要画面时使用低保真 `Breadboard` 或 `Fat-marker sketch` 思路：只表达元素、动作与连接，不做视觉精修。

### 4. Rabbit Holes：兔子洞

列出最可能吞噬周期的未知问题，例如：

- 第三方 API 不稳定。
- 权限、隐私或合规边界。
- 多平台兼容。
- 数据质量与迁移。
- Agent 输出不可验证。
- 看似简单但后端工作量巨大的 Iceberg。

每个兔子洞必须给出：提前验证方式、规避方案或触发停止的条件。

### 5. No-Gos：明确不做

至少列出 3 项本周期不做的内容。优先排除：

- 第二类用户。
- 第二个平台。
- 团队协作、支付、复杂权限。
- 过早抽象和“以后可能需要”的架构。
- 不影响核心验证的视觉精修。
- 自动执行中本应保留的人类确认。

### 6. Evidence Gate：验收证据

把“完成”定义为可验证结果，而不是 Agent 的完成声明。

至少包含：

- 用户能完成的端到端任务。
- 可运行 Demo 或真实环境结果。
- 自动化测试或可重复检查。
- 关键截图、日志或 Trace。
- 错误与边界场景。
- 与 No-Gos 的范围一致性检查。

涉及 AI Agent 时，正式验收不得用固定答案、预录动画或 Replay 冒充真实运行。

详细规则见 [Evidence Gate](references/evidence-gate.md)。

## 二、Bet：下注判断

读取 [Decision Rubric](references/decision-rubric.md)，按以下维度判断：

- Problem：问题是否真实且重要。
- Appetite：投入上限是否合理。
- Solution：方案是否有吸引力且能在周期内成立。
- Risk：最大未知是否已被识别和降险。
- Timing：现在是否是正确时间。
- Capacity：合适的人或 Agent 是否可用。
- Evidence：成功是否可被证明。

输出必须是以下之一：

- `BET`：可以进入周期。
- `RESHAPE BEFORE BET`：值得继续，但必须重新塑形。
- `RESEARCH BET`：只下注于验证最大未知，不承诺完整产品。
- `PASS`：现在不值得投入。

不要建立无限 Backlog。未下注想法进入简短的 `Parking Lot`，只记录标题、触发条件和最后复查日期。

## 三、Kickoff：开发 Brief

只有 `BET` 后生成开发 Brief。默认不要立即写实现代码，除非用户明确要求进入实现。

开发 Brief 必须包含：

- Mission：完整用户结果。
- Pitch 摘要与 Appetite。
- Core Flow。
- Scopes：按业务范围或垂直切片组织，不先拆成几百个任务。
- Must-haves 与 Nice-to-haves。
- Agent 权限：可自行决定、必须升级给人类的事项。
- Evidence Gate。
- Circuit Breaker。

Solo 模式：输出简化开发计划（Mission + Core Flow + Scopes + Evidence Gate），不需要 Agent Brief。多 Agent 模式：读取 [AI Agent Adaptation](references/ai-agent-adaptation.md) 并使用 [Agent Brief 模板](assets/AGENT_BRIEF_TEMPLATE.md)，确保所有 Agent 共享同一份 Pitch 和 Evidence Gate。

## 四、Build：周期内治理

### 使用垂直切片

优先跑通最小端到端闭环，再扩展细节。不要先分别完成前端、后端、数据库、测试后再集成。

### 允许改变实现，不允许偷偷改变目标

Agent 可以：

- 调整技术方案。
- 合并或删除任务。
- 重新组织内部结构。
- 为通过验收而砍掉 Nice-to-haves。

Agent 不可以自行：

- 增加用户类型、平台或商业模式。
- 改变核心结果。
- 延长周期。
- 接受关键安全、隐私或数据风险。
- 为未来假设重写架构。

### 用 Hill Status 代替伪精确百分比

状态分为：

- `Uphill`：仍在发现未知和解决关键问题。
- `Top`：关键未知已解，路径清楚。
- `Downhill`：主要是执行和收尾。

不要轻易报告“完成 80%”。使用 [Hill Status 模板](assets/HILL_STATUS_TEMPLATE.md)。

## 五、Scope Review：范围审查

当出现新需求或延期风险时：

1. 对照 Pitch 判断它是 Must-have、Nice-to-have 还是新项目。
2. 新项目不得静默进入当前周期。
3. 若核心结果受阻，优先缩小范围而不是增加人或时间。
4. 若最大未知仍未解决，停止低价值细节，先处理风险。
5. 记录范围变化及其对 Evidence Gate 的影响。

## 六、Cycle Review：周期结束

禁止默认续期。输出一个明确决策：

### Ship

核心承诺成立，Evidence Gate 通过。允许留下不影响使用的细节。

### Reshape

问题仍值得解决，但方案或范围不成立。必须改变方案，不能只换截止日期。

### Kill

价值不足、成本过高、时机不对或关键假设失败。停止投入并保留可复用资产。

使用 [Cycle Review 模板](assets/CYCLE_REVIEW_TEMPLATE.md)。

## 标准输出结构

对 `shape` 或 `full-cycle`，按以下顺序输出：

1. **一句话判断**
2. **已知事实 / 证据**
3. **未验证假设**
4. **Problem & Baseline**
5. **Appetite**
6. **Core Outcome**
7. **Solution Outline**
8. **Rabbit Holes**
9. **No-Gos**
10. **Evidence Gate**
11. **Bet Decision**
12. **下一步**

若用户需要文件，优先从 [Pitch 模板](assets/PITCH_TEMPLATE.md) 生成可保存的 Markdown。

## 质量底线

以下任一情况视为失败：

- 在模糊需求阶段直接开始写代码。
- 没有 Appetite、Rabbit Holes 或 No-Gos。
- 把假设写成已验证事实。
- 用功能数量或代码量代替用户结果。
- 为每个新想法建立永久 Backlog。
- 让 Agent 自行扩大范围或延长周期。
- 接受“已完成”但没有证据。
- 周期结束默认选择“再给一周”。
- 输出只是泛泛方法论，没有形成当前项目的具体 Pitch。

## 资源加载规则

- 需要解释官方概念时读取 [Shape Up Core](references/shape-up-core.md)。
- 适配独立开发者或多 Agent 时读取 [AI Agent Adaptation](references/ai-agent-adaptation.md)。
- 做下注判断时读取 [Decision Rubric](references/decision-rubric.md)。
- 定义交付证据时读取 [Evidence Gate](references/evidence-gate.md)。
- 发现范围失控或常见错误时读取 [Anti-patterns](references/anti-patterns.md)。
- 需要完整示例时读取 [Examples](references/examples.md)。

## 可选脚本

初始化一套项目材料：

```bash
python scripts/init_shapeup.py --project "项目名称" --mode solo --cycle-days 10 --out .shapeup
```

检查 Pitch 是否缺少关键字段：

```bash
python scripts/validate_pitch.py .shapeup/01-PITCH.md
```

脚本只做结构检查，不能替代人类下注判断。