Back to Details

spec

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Spec

规格说明

Turn a vague idea into a buildable specification through a short, structured interview.
Announce at start: "I'm using the spec skill to help you define this."
通过简短的结构化访谈，将模糊的想法转化为可落地的规格说明。
开始时告知用户： "我将使用规格说明技能帮你明确需求。"

Workflow

工作流程

Interview → Synthesize → Draft → Review → Save
  1. Interview — ask structured questions to understand the idea
  2. Synthesize — identify scope, constraints, and open questions
  3. Draft — write a SPEC.md covering all dimensions
  4. Review — walk through the spec with the user, revise until approved
  5. Save — write the final spec to disk
<HARD-GATE> Do NOT generate the spec document until you have completed the interview and the user has confirmed you understand their idea correctly. Do NOT skip to implementation. The output of this skill is a spec document, not code. </HARD-GATE>
访谈 → 梳理整合 → 起草 → 评审 → 保存
  1. 访谈 —— 提出结构化问题以理解想法
  2. 梳理整合 —— 确定范围、约束条件和待解决问题
  3. 起草 —— 撰写涵盖所有维度的SPEC.md文档
  4. 评审 —— 与用户一起审阅规格说明，修订直至获得认可
  5. 保存 —— 将最终规格说明写入磁盘
<HARD-GATE> 在完成访谈且用户确认你已正确理解其想法之前，请勿生成规格文档。请勿跳过直接进入实现环节。本技能的输出是规格文档，而非代码。 </HARD-GATE>

Interview

访谈环节

Ask questions one at a time. Prefer multiple-choice when possible. Keep it to 5-8 questions total — infer the rest from context.
Question sequence (adapt to context):
  1. What is this? — one-sentence description in the user's words
  2. Who is it for? — target user or audience (multiple-choice if obvious candidates exist)
  3. What's the trigger? — when/why does someone reach for this?
  4. What does success look like? — concrete outcome, not metrics
  5. What's the scope? — MVP vs full vision (multiple-choice: minimal / moderate / ambitious)
  6. What exists already? — prior art, constraints, systems it must integrate with
  7. What's explicitly out of scope? — things that might seem related but aren't part of this
  8. Any hard constraints? — tech stack, timeline, platform, compliance, etc.
Rules:
  • One question per message. Never batch questions.
  • If the user's answer implies the next question's answer, skip it.
  • If something is ambiguous, ask a follow-up before moving on.
  • Mirror the user's language — don't introduce jargon they didn't use.
一次只提一个问题。尽可能采用选择题形式。总共控制在5-8个问题——其余信息从上下文推断。
问题顺序（根据上下文调整）：
  1. 这是什么？ —— 用用户的语言进行一句话描述
  2. 面向谁？ —— 目标用户或受众（如有明确候选群体，采用选择题形式）
  3. 触发场景是什么？ —— 用户何时/为何会使用它？
  4. 成功的标准是什么？ —— 具体的成果，而非指标
  5. 范围如何？ —— 最小可行产品（MVP） vs 完整愿景（选择题：最小化 / 适中 / 宏大）
  6. 已有哪些相关成果？ —— 先例、约束条件、必须集成的系统
  7. 明确排除的范围是什么？ —— 看似相关但不属于本次范畴的内容
  8. 有哪些硬性约束？ —— 技术栈、时间线、平台、合规要求等
规则：
  • 每次只发一个问题，切勿批量提问
  • 如果用户的回答已经暗示了下一个问题的答案，可以跳过该问题
  • 若有模糊之处，先提出跟进问题再继续
  • 沿用用户的语言风格——不要引入用户未使用的术语

Synthesis checkpoint

梳理整合确认环节

Before drafting, summarize what you've learned in 3-5 bullets and ask: "Does this capture it? Anything I'm missing or got wrong?"
Only proceed to drafting after the user confirms.
起草之前，用3-5个要点总结你所了解的信息，并询问：“这些内容是否准确涵盖了需求？有没有遗漏或理解错误的地方？”
只有在用户确认后，才能进入起草环节。

Spec Document Format

规格文档格式

Write the spec as a markdown document with these sections. Scale each section to the complexity of the idea — a simple feature gets a few sentences per section, not paragraphs.
markdown
undefined
将规格说明写成包含以下章节的Markdown文档。根据想法的复杂度调整各章节的篇幅——简单功能每个章节只需几句话，无需长篇大论。
markdown
undefined

[Feature/Product Name]

[功能/产品名称]

Problem

问题

What problem does this solve? Why does it matter?
这能解决什么问题？为什么重要？

Solution

解决方案

What are we building? One-paragraph description.
我们要构建什么？一段描述。

Users

用户群体

Who uses this and what's their context?
谁会使用它？使用场景是什么？

Requirements

需求

Must have

必备功能

  • ...
  • ...

Should have

推荐功能

  • ...
  • ...

Won't have (this version)

本次版本不包含的功能

  • ...
  • ...

Design

设计

How it works at a high level. Architecture, key flows, data model — whatever is relevant. Use diagrams if they clarify.
整体工作机制。架构、核心流程、数据模型——任何相关内容。如有帮助可使用图表。

Open questions

待解决问题

Unresolved decisions that need input before or during implementation.
在实现之前或过程中需要输入才能决定的未解决事项。

Out of scope

排除范围

Explicitly excluded to prevent scope creep.

**Principles:**
- Requirements are concrete and testable, not vague ("fast" → "responds in <200ms")
- "Won't have" is just as important as "Must have"
- Open questions are honest — don't paper over unknowns
- Keep it short enough that someone will actually read it
明确排除的内容，以防止范围蔓延。

**原则：**
- 需求需具体且可测试，不能模糊（例如将“快速”改为“响应时间<200ms”）
- “本次版本不包含的功能”与“必备功能”同样重要
- 待解决问题需如实记录——不要掩盖未知事项
- 文档要简洁到有人愿意去读

Saving the spec

保存规格文档

Save to: 
SPEC.md
in the project root, unless the user specifies a different location.
If a 
SPEC.md
already exists, ask whether to replace or save alongside it (e.g., 
SPEC-<feature-name>.md
).
保存至：项目根目录下的
SPEC.md
，除非用户指定其他位置。
如果
SPEC.md
已存在，询问用户是替换还是另行保存（例如：
SPEC-<功能名称>.md
）。

After the spec

规格文档完成后

Present the saved file path and ask what the user wants to do next. Do NOT automatically invoke implementation skills — the user decides the next step.
告知用户保存的文件路径，并询问用户下一步想要做什么。请勿自动调用实现类技能——由用户决定下一步操作。