shape

Shape — 自动评审并生成 PRD

只需一步，即可将粗略的产品创意转化为完整的 PRD。无需互动式提问——Claude 会自行走完决策树，根据软件工程最佳实践回答每个问题，实时呈现问答，方便你及时发现错误假设，并撰写 PRD。

信任 Claude 的判断并追求速度时，使用 /shape。希望亲自掌控每个决策时，使用 /grill-me + /write-a-prd。

流水线位置

步骤	命令	作用
1a	/grill-me + /write-a-prd	手动路径——互动式访谈，然后生成 PRD
1b	/shape	快速路径——自动评审并一步生成 PRD
2	/prd-to-issues	将 PRD 拆分为垂直切片子问题
3	/ralph	通过 TDD + 代码审查自主实现每个子问题

shape 生成的 PRD 格式与 write-a-prd 相同，因此 /prd-to-issues 和 /ralph 无需修改即可使用其输出。

说明

用户调用此技能时：

1. 收集创意

如果用户在参数中提供了创意，就使用它。否则只询问一次：

你想构建什么？（一段话即可）

然后继续，不再提出其他互动式问题，直到第 8 步。

2. 探索代码库

在回答任何问题之前，先结合实际情况做出判断：

• 阅读 README.md、CLAUDE.md 和所有架构文档
• 找出功能应遵循的现有模块、约定、测试模式和先例
• 核实用户创意中的事实陈述——不要轻信，先检查
• 记录使用的语言、框架、测试运行器和目录布局

如果没有代码库（目录为空或从零开始），则跳到第 3 步，并在 PRD 的 Further Notes 中记录这一点。

3. 遍历决策树

针对以下每个分支，生成一位资深工程师会提出的问题，然后自行回答每个问题。即使某个分支看起来显而易见，也不要跳过——这正是此技能的全部意义。

• 参与者与用户故事——谁会使用它，他们想要什么，怎样才算成功
• 顺利路径流程——主要交互的逐步过程
• 边缘情况——空输入、大输入、并发访问、部分失败、网络错误、权限被拒、缺失数据、Unicode/编码、时区
• 数据模型与架构——实体、关系、索引、迁移
• 模块边界——深模块、公共接口、内部实现
• API 契约——请求/响应结构、错误代码、幂等性、版本管理
• 测试策略——测试内容、模拟对象（仅限边界），以及代码库中的先例
• 安全性——身份验证/授权、输入验证、机密信息、速率限制
• 可观测性——需要记录的日志、需要呈现的指标
• 范围之外——明确的非目标，防止范围蔓延
• 依赖项与阻塞因素——哪些内容必须先具备

4. 最佳实践默认原则

自行回答时，优先采用：

• 朴实胜过巧妙——选择简单且广为人知的模式
• 深模块（Ousterhout）——通过简单、稳定的接口提供丰富功能
• 遵循代码库，而非外部标准——以项目约定为准
• 利于 TDD 的设计——通过公共接口测试，而非内部实现
• 在系统边界进行验证——信任内部调用方，在边界处明确报错
• YAGNI——不添加推测性的抽象，也不添加用户未要求的功能
• 使用参数化查询，绝不拼接字符串
• 对身份验证端点进行速率限制
• 绝不记录机密信息、令牌或个人身份信息
• 仅在系统边界模拟（外部 API、数据库、时间、随机性、文件系统）——绝不模拟内部协作者

**代码库中的事实始终优先于通用最佳实践。**如果项目已经采用 X，答案就是 X。

5. 实时呈现问答

每做出一项决策，就按以下精确格式输出一个区块——不要批量输出：

Q: <the question>
A: <the chosen answer>
Why: <one sentence — cite a codebase reference if relevant>

这样用户就有机会尽早发现错误假设。

6. 编写 PRD

请严格使用此模板。它与 /write-a-prd 相匹配，因此后续流程可以原样接收。

## Problem Statement

The problem the user is facing, from the user's perspective.

## Solution

The solution, from the user's perspective.

## User Stories

A long, numbered list:
1. As a <actor>, I want a <feature>, so that <benefit>

Cover every aspect of the feature surfaced in your decision tree.

## Implementation Decisions

- Modules to build or modify
- Public interfaces of those modules
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions

Do NOT include file paths or code snippets — they go stale fast.

## Testing Decisions

- What makes a good test here (test external behavior, never implementation details)
- Which modules will be tested
- Prior art for the tests (similar patterns already in the codebase)

## Out of Scope

Explicit non-goals.

## Further Notes

Anything else worth recording.

## Decisions Log

Every Q/A/Why block from step 5, in the order they were decided.

7. 在本地保存 PRD

• 根据创意生成 kebab-case slug（例如，“rate-limited /healthz endpoint” → rate-limited-healthz-endpoint）
• 如果 ./prds/ 不存在，则创建它
• 将 PRD 写入 ./prds/<slug>.md
• 输出绝对路径

8. 提议推送到 GitHub

保存后，询问用户一次：

将此内容作为 GitHub issue 推送？[y/N]

如果用户输入 y，运行：

gh issue create --title "<slug>" --body-file ./prds/<slug>.md

输出 issue URL。

如果用户输入 n 或没有回答，则停止。本地文件已经足够，用户之后可以再推送。

规则

• 不要在决策树过程中向用户提问。 自动作答正是整个流程的目的。只有两个交互环节：记录创意（如果用户尚未提供）以及最后询问是否推送到 GitHub。
• 不要跳过任何分支。 即使某些分支看起来微不足道，也要逐一处理——完整性才是重点。
• 代码库事实优先于通用最佳实践。 如果项目已经采用了方案 X，答案就是 X。
• 不要推测范围。 如果用户没有提出某项需求，且代码库也不要求该项内容，就将其列入范围外。
• PRD 模板是固定的。 必须与 /write-a-prd 完全一致，确保 /prd-to-issues 和 /ralph 继续正常工作。