Back to Details

shape

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Shape — Auto-Grill to PRD

Shape — 自动盘问生成PRD

Take a rough product idea and turn it into a complete PRD in one shot. No interactive grilling — Claude walks the decision tree itself, answers each question with software-engineering best practices, streams the Q&A live so you can spot bad assumptions, and writes the PRD.
Use 
/shape
when you trust Claude's judgment and want speed. Use 
/grill-me
+ 
/write-a-prd
when you want hands-on control over every decision.
将一个初步的产品想法一键转化为完整的PRD。无需交互式盘问——Claude会自行遍历决策树，使用软件工程最佳实践回答每个问题，实时流式输出问答内容方便你发现错误假设，最终生成PRD。
如果你信任Claude的判断且追求效率，请使用 
/shape
。如果你想要手动控制每一项决策，请使用 
/grill-me
+ 
/write-a-prd
。

Pipeline Position

流水线位置

StepCommandWhat It Does
1a
/grill-me
+ 
/write-a-prd
Manual path — interactive interview, then PRD
1b
/shape
Fast path — auto-grill + PRD in one shot
2
/prd-to-issues
Break the PRD into vertical-slice sub-issues
3
/ralph
Implement each sub-issue autonomously with TDD + code review
shape
produces the same PRD format as 
write-a-prd
, so 
/prd-to-issues
and 
/ralph
consume its output without changes.
步骤命令功能说明
1a
/grill-me
+ 
/write-a-prd
手动路径——交互式访谈，然后生成PRD
1b
/shape
快速路径——自动盘问+一键生成PRD
2
/prd-to-issues
将PRD拆分为垂直切片的子issue
3
/ralph
基于TDD+代码评审自主实现每个子issue
shape
生成的PRD格式与 
write-a-prd
完全一致，因此 
/prd-to-issues
和 
/ralph
可以直接使用其输出无需修改。

Instructions

使用说明

When the user invokes this skill:
当用户调用该技能时：

1. Capture the idea

1. 收集想法

If the user passed an idea as an argument, use it. Otherwise ask once:
What do you want to build? (one paragraph is fine)
Then proceed without further interactive questions until step 8.
如果用户传入了想法作为参数，直接使用该内容。否则发起一次询问：
你想要构建什么内容？（一段话描述即可）
之后无需再发起交互式提问，直到第8步。

2. Explore the codebase

2. 探查代码库

Before answering anything, ground your decisions in reality:
  • Read 
    README.md
    , 
    CLAUDE.md
    , and any architecture docs
  • Identify existing modules, conventions, test patterns, and prior art the feature should match
  • Verify any factual assertions in the user's idea — don't trust them, check
  • Note the language, framework, test runner, and directory layout
If there is no codebase (empty directory or greenfield), skip to step 3 and record this in the PRD's Further Notes.
在输出任何内容前，先基于实际情况确定决策：
  • 读取 
    README.md
    、
    CLAUDE.md
    以及所有架构相关文档
  • 识别现有模块、约定、测试模式、以及该功能应该匹配的已有实现
  • 验证用户想法中所有事实性表述——不要默认信任，自行核实
  • 记录使用的编程语言、框架、测试运行器、目录结构
如果不存在代码库（空目录或者全新项目），直接跳到第3步，并将该情况记录到PRD的补充说明中。

3. Walk the decision tree

3. 遍历决策树

For each branch below, generate the questions a thorough engineer would ask, then answer each one yourself. Do not skip a branch even if it feels obvious — that is the entire point of this skill.
  • Actors & user stories — who uses this, what they want, what success looks like
  • Happy-path flow — primary interaction step by step
  • Edge cases — empty inputs, large inputs, concurrent access, partial failures, network errors, permission denied, missing data, unicode/encoding, time zones
  • Data model & schema — entities, relationships, indexes, migrations
  • Module boundaries — deep modules, public interfaces, what stays internal
  • API contracts — request/response shapes, error codes, idempotency, versioning
  • Testing strategy — what to test, what to mock (only at boundaries), prior art in the repo
  • Security — authn/authz, input validation, secrets, rate limiting
  • Observability — what to log, what to surface as metrics
  • Out of scope — explicit non-goals to prevent scope creep
  • Dependencies & blockers — what must exist first
针对以下每个分支，生成资深工程师会提出的问题，然后自行回答每个问题。即使分支内容看起来很显而易见也不要跳过——这是本技能的核心价值。
  • Actors & user stories——适用人群、用户需求、成功判定标准
  • Happy-path flow——核心交互的完整步骤
  • Edge cases——空输入、大输入、并发访问、部分失败、网络错误、权限不足、数据缺失、unicode/编码问题、时区问题
  • Data model & schema——实体、关系、索引、迁移脚本
  • Module boundaries——深度模块、公共接口、内部私有内容
  • API contracts——请求/响应结构、错误码、idempotency、版本控制
  • Testing strategy——测试范围、mock内容（仅在边界处mock）、代码库内的已有测试模式
  • Security——authn/authz、输入校验、密钥、限流
  • Observability——日志采集内容、指标上报内容
  • Out of scope——明确的非目标功能，防止范围蔓延
  • Dependencies & blockers——前置依赖项

4. Best-practice defaults

4. 最佳实践默认规则

When self-answering, prefer:
  • Boring over clever — simple, well-understood patterns
  • Deep modules (Ousterhout) — wide functionality behind a simple, stable interface
  • Match the codebase over external standards — project conventions win
  • TDD-friendly design — testable through public interfaces, not internals
  • Validate at system boundaries — trust internal callers, fail loudly at the edge
  • YAGNI — no speculative abstractions, no features the user didn't ask for
  • Parameterized queries, never string concatenation
  • Rate limit auth endpoints
  • Never log secrets, tokens, or PII
  • Mock only at system boundaries (external APIs, DBs, time, randomness, filesystem) — never mock internal collaborators
Codebase facts always beat generic best practices. If the project already does X, the answer is X.
自行作答时，优先遵循以下规则：
  • 宁朴素勿炫技——选用简单、被广泛验证的模式
  • 深度模块（Ousterhout法则）——在简单、稳定的接口背后提供丰富功能
  • 匹配代码库规则优先于外部标准——项目约定优先级更高
  • TDD友好的设计——通过公共接口而非内部逻辑实现可测试性
  • 在系统边界处做校验——信任内部调用，在边界处明确报错
  • YAGNI原则——不做推测性抽象，不开发用户未提出的功能
  • 参数化查询，永远不要用字符串拼接
  • 认证接口做限流
  • 永远不要日志输出密钥、token或者PII
  • 仅在系统边界处mock（外部API、数据库、时间、随机数、文件系统）——永远不要mock内部依赖
代码库实际规则永远优于通用最佳实践。 如果项目已经采用了X方案，就直接使用X方案。

5. Stream the Q&A live

5. 实时流式输出问答

For every decision, emit a block in this exact format as you make the call — do not batch:
Q: <the question>
A: <the chosen answer>
Why: <one sentence — cite a codebase reference if relevant>
This is the user's chance to spot a bad assumption early.
针对每一项决策，按照以下固定格式实时输出内容，不要批量输出：
Q: <the question>
A: <the chosen answer>
Why: <one sentence — cite a codebase reference if relevant>
这是用户提前发现错误假设的机会。

6. Write the PRD

6. 编写PRD

Use this template exactly. It matches 
/write-a-prd
, so the rest of the pipeline accepts it unchanged.
markdown
undefined
严格使用以下模板。该模板与 
/write-a-prd
完全匹配，因此流水线的后续步骤可以直接使用无需修改。
markdown
undefined

Problem Statement

Problem Statement

The problem the user is facing, from the user's perspective.
从用户视角描述用户面临的问题。

Solution

Solution

The solution, from the user's perspective.
从用户视角描述解决方案。

User Stories

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.
完整的编号列表：
  1. 作为 <actor>，我想要 <功能>，以便于 <收益>
覆盖决策树中梳理出的功能的所有维度。

Implementation Decisions

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.
  • 需要构建或修改的模块
  • 这些模块的公共接口
  • 架构决策
  • schema变更
  • API contracts
  • 具体交互逻辑
不要包含文件路径或者代码片段——这些内容很快就会过期。

Testing Decisions

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

Out of Scope

Explicit non-goals.
明确的非目标功能。

Further Notes

Further Notes

Anything else worth recording.
其他值得记录的内容。

Decisions Log

Decisions Log

Every Q/A/Why block from step 5, in the order they were decided.
undefined
第5步中所有Q/A/Why块，按照决策顺序排列。
undefined

7. Save the PRD locally

7. 本地保存PRD

  • Generate a kebab-case slug from the idea (e.g. "rate-limited /healthz endpoint" → 
    rate-limited-healthz-endpoint
    )
  • Create 
    ./prds/
    if it doesn't exist
  • Write the PRD to 
    ./prds/<slug>.md
  • Print the absolute path
  • 基于产品想法生成kebab-case格式的slug（例如："rate-limited /healthz endpoint" → 
    rate-limited-healthz-endpoint
    ）
  • 如果 
    ./prds/
    目录不存在则创建
  • 将PRD写入 
    ./prds/<slug>.md
  • 输出文件的绝对路径

8. Offer to push to GitHub

8. 询问是否推送到GitHub

After saving, ask the user once:
Push this as a GitHub issue? [y/N]
On 
y
, run:
bash
gh issue create --title "<slug>" --body-file ./prds/<slug>.md
Print the issue URL.
On 
n
or no answer, stop. The local file is enough — the user can push later.
保存完成后，发起一次询问：
是否要将该PRD推送为GitHub issue？[y/N]
如果用户输入 
y
，执行：
bash
gh issue create --title "<slug>" --body-file ./prds/<slug>.md
输出issue的URL。
如果用户输入 
n
或者无应答，终止流程。本地文件已经足够——用户可以后续自行推送。

Rules

规则

  • Don't ask the user questions during the decision tree. The whole point is auto-answering. The only interactive moments are: capturing the idea (if not given) and the GitHub push prompt at the end.
  • Don't skip branches. Even trivial-feeling branches get walked — completeness is the value.
  • Codebase facts beat generic best practices. If the project already does X, X is the answer.
  • No speculative scope. If the user didn't ask for it and the codebase doesn't require it, it goes in Out of Scope.
  • The PRD template is fixed. It must match 
    /write-a-prd
    exactly so 
    /prd-to-issues
    and 
    /ralph
    keep working.
  • 遍历决策树期间不要询问用户问题。 核心目标就是自动作答。仅有的交互场景是：收集想法（如果用户未提供）和末尾的GitHub推送询问。
  • 不要跳过决策分支。 即使看起来非常琐碎的分支也要遍历——完整性是核心价值。
  • 代码库实际规则优于通用最佳实践。 如果项目已经采用了X方案，就直接使用X方案。
  • 不做推测性范围扩展。 如果用户没有提出需求且代码库没有相关要求，就放入非目标功能中。
  • PRD模板是固定的。 必须与 
    /write-a-prd
    模板完全匹配，确保 
    /prd-to-issues
    和 
    /ralph
    可以正常运行。