Back to Details

to-prd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Skill: to-prd

Skill: to-prd

Você é responsável por criar o 
docs/prd.md
do projeto. Este documento é a fonte da verdade dos requisitos — arquitetura, specs e implementação derivam dele. Um PRD ruim contamina tudo que vem depois.
你负责创建项目的 
docs/prd.md
。该文档是需求的 source of truth（唯一事实来源）——架构、specs 和实现都由它派生。糟糕的 PRD 会污染后续的一切。

Pré-condições

前置条件

Antes de começar, verifique:
  1. Output do grill-me: há entendimento do projeto na conversa atual ou em arquivos? Esse é seu ponto de partida — extraia tudo que já foi discutido antes de perguntar ao usuário.
  2. PRD existente: se 
    docs/prd.md
    já existe, pergunte se quer revisar seções específicas ou refazer do zero.
  3. Diretório 
    docs/
    : crie se não existir.
开始前，请确认：
  1. grill-me 输出：当前对话或文件中是否有对项目的理解？这是你的起点——在询问用户之前，先提取已经讨论过的所有内容。
  2. 现有 PRD：如果 
    docs/prd.md
    已存在，询问用户希望审查特定章节还是从头重做。
  3. docs/
    目录    ：如果不存在则创建。

Processo

流程

Trabalhe seção por seção de forma interativa. Para cada seção:
  1. Proponha uma versão inicial baseada no contexto disponível (não pergunte o que você pode inferir)
  2. Apresente ao usuário com as suposições claramente sinalizadas
  3. Colete feedback e refine
  4. Só avance com aprovação explícita
Nunca produza o documento inteiro de uma vez sem validação intermediária.
逐节以交互方式推进。对于每一节：
  1. 根据可用上下文提出一个初始版本（不要询问你本可推断的信息）
  2. 向用户展示，并清楚标出其中的假设
  3. 收集反馈并完善内容
  4. 只有在得到明确批准后才继续
绝不要在没有中间验证的情况下一次性生成整份文档。

Estrutura do PRD

PRD 结构

Seção 1 — Goals and Background Context

第 1 节——Goals 与 Background Context（目标与背景上下文）

Goals (bullet list): outcomes concretos que o projeto precisa entregar. Foco em resultado, não em funcionalidade.
Background Context (1-2 parágrafos): o que este projeto resolve e por que agora. Não repita os goals.
Change Log (tabela): 
Date | Version | Description | Author
Goals（目标）（项目必须交付的具体成果的 bullet list）：聚焦结果，而非功能。
Background Context（背景上下文）（1–2 个段落）：说明该项目要解决什么问题，以及为什么现在要做。不要重复 goals。
Change Log（变更日志）（表格）：
Date | Version | Description | Author

Seção 2 — Requirements

第 2 节——Requirements（需求）

Functional Requirements: o que o sistema faz. Prefixo 
FR
, numerados sequencialmente.
FR1: [descrição da capacidade funcional]
FR2: ...
Non-Functional Requirements: qualidade, performance, segurança, escala. Prefixo 
NFR
.
NFR1: [critério mensurável — ex: "p95 < 200ms para todas as rotas de API"]
NFR2: ...
Cada NFR deve ter um critério mensurável. "O sistema deve ser rápido" não é um NFR.
Functional Requirements（功能需求）：系统做什么。使用 
FR
前缀并按顺序编号。
FR1: [descrição da capacidade funcional]
FR2: ...
Non-Functional Requirements（非功能需求）：质量、性能、安全性和扩展性。使用 
NFR
前缀。
NFR1: [critério mensurável — ex: "p95 < 200ms para todas as rotas de API"]
NFR2: ...
每项 NFR 都必须包含可衡量的标准。“系统应该够快”不属于 NFR。

Seção 3 — User Interface Design Goals (somente se houver UX/UI)

第 3 节——User Interface Design Goals（仅当存在 UX/UI 时）

  • Overall UX Vision: 2-3 frases sobre a experiência que o produto deve transmitir
  • Key Interaction Paradigms: padrões de interação centrais (ex: drag-and-drop, inline editing, wizard steps)
  • Core Screens and Views: lista conceitual das telas principais para entregar o valor do produto — não é spec técnica, é perspectiva de produto
  • Accessibility: 
    None | WCAG AA | WCAG AAA
  • Branding: guia de cores, tipografia, tokens existentes (se houver)
  • Target Platforms: 
    Web Responsive | Mobile Only | Desktop Only | Cross-Platform
  • Overall UX Vision（整体 UX 愿景）：用 2–3 句话说明产品应传达的体验
  • Key Interaction Paradigms（关键交互范式）：核心交互模式（例如 drag-and-drop、inline editing、wizard steps）
  • Core Screens and Views（核心界面与视图）：用于交付产品价值的主要界面的概念性清单——它不是技术 spec，而是产品视角
  • Accessibility（无障碍）：
    None | WCAG AA | WCAG AAA
  • Branding（品牌）：颜色、字体和现有 tokens 的规范（如果已有）
  • Target Platforms（目标平台）：
    Web Responsive | Mobile Only | Desktop Only | Cross-Platform

Seção 4 — Technical Assumptions

第 4 节——Technical Assumptions（技术假设）

Decisões técnicas que vão guiar a arquitetura. Registre com rationale, não só a escolha.
  • Repository Structure: 
    Monorepo | Polyrepo
  • Service Architecture: 
    Monolith | Microservices | Serverless
  • Testing Requirements: nível de cobertura esperado (unit, integration, E2E, manual)
  • Additional Assumptions: qualquer outra premissa técnica relevante que surgir durante a elicitação
用于指导架构的技术决策。记录时需附上 rationale，而不只是选择结果。
  • Repository Structure（仓库结构）：
    Monorepo | Polyrepo
  • Service Architecture（服务架构）：
    Monolith | Microservices | Serverless
  • Testing Requirements（测试要求）：预期覆盖级别（unit、integration、E2E、manual）
  • Additional Assumptions（其他假设）：需求引出过程中出现的任何其他相关技术假设

Integrações e Serviços Externos

外部集成与服务

Para cada serviço externo (APIs de terceiros, provedores de infra, SDKs externos) que o projeto vai usar:
Serviço: [nome da categoria — ex: "Envio de mensagens WhatsApp"]
Escolha definitiva: [nome do serviço/biblioteca — ex: "Evolution API (self-hosted)"]
Alternativas descartadas: [ex: "Z-API (custo variável por tenant), Meta API oficial (complexidade de aprovação)"]
Rationale: [por que esta escolha — ex: "custo fixo independente do número de tenants, controle total do servidor"]
Como validar: [critério concreto de que está funcionando — ex: "webhook recebe mensagem real e resposta é entregue no WhatsApp"]
Regras:
  • Cada categoria tem exatamente uma escolha — nunca "X ou Y"
  • Se há dúvida real entre duas opções, resolva aqui com uma pergunta ao usuário antes de avançar
  • A coluna "Como validar" é obrigatória — define o que "funcionando" significa para aquele serviço
  • Os campos "Como validar" de todos os serviços, somados, são o checklist de cutover do projeto: a lista do que precisa ser conferido com dado real em produção antes de abrir para usuários. Escreva cada um como um critério executável por uma pessoa na virada — não como intenção vaga
对于项目将使用的每个外部服务（第三方 API、基础设施提供商、外部 SDK）：
Serviço: [nome da categoria — ex: "Envio de mensagens WhatsApp"]
Escolha definitiva: [nome do serviço/biblioteca — ex: "Evolution API (self-hosted)"]
Alternativas descartadas: [ex: "Z-API (custo variável por tenant), Meta API oficial (complexidade de aprovação)"]
Rationale: [por que esta escolha — ex: "custo fixo independente do número de tenants, controle total do servidor"]
Como validar: [critério concreto de que está funcionando — ex: "webhook recebe mensagem real e resposta é entregue no WhatsApp"]
规则：
  • 每个类别必须恰好有一个选择——绝不能写成“X 或 Y”
  • 如果确实在两个选项之间存在疑问，在继续之前通过向用户提问解决
  • “Como validar”字段为必填——它定义了该服务“正常运行”的含义
  • 所有服务的“Como validar”字段汇总后，就是项目的 cutover checklist：在向用户开放之前，必须使用生产环境真实数据核查的清单。将每一项写成切换上线时可由人员直接执行的标准，而不要写成模糊的意向

Stack Técnico

技术 Stack

CamadaTecnologiaDiretório
[ex: Backend][ex: Python + FastAPI][ex: backend/]
[ex: Frontend][ex: Next.js + TypeScript][ex: frontend/]
Regras:
  • Uma linha por camada executável independente
  • Diretório é o path relativo à raiz do repositório
  • Se for monolito (sem subdivisões): uma linha apenas
  • Esta tabela informa a escolha de stack. Ela não alimenta a seção 
    ## Commands
    do arquivo de instruções: o 
    /setup-project
    deriva os comandos do manifesto do projeto (
    package.json
    , 
    Cargo.toml
    , 
    pyproject.toml
    ) e mede cada um antes de gravar. O manifesto é a realidade; esta tabela é plano, e plano não é executável.
层级技术目录
[例如：后端（Backend）][例如：Python + FastAPI][例如：backend/]
[例如：前端（Frontend）][例如：Next.js + TypeScript][例如：frontend/]
规则：
  • 每个可独立执行的层占一行
  • 目录是相对于仓库根目录的 path
  • 如果是单体应用（没有进一步划分）：只写一行
  • 此表记录的是 stack 选择。它不会为指令文件的 
    ## Commands
    章节提供内容：
    /setup-project
    根据项目的 manifest（
    package.json
    、
    Cargo.toml
    、
    pyproject.toml
    ）生成命令，并在写入前逐一测量。Manifest 才是现实；此表只是计划，而计划不可执行。

Seção 5 — Lista de SPECs (alto nível)

第 5 节——SPEC 清单（高层级）

Liste todas as SPECs com título + 1 frase de goal. Apresente ao usuário para aprovação antes de avançar.
Regras críticas de sequenciamento:
  • SPEC 1 SEMPRE estabelece a infraestrutura base: setup do projeto, Git, CI/CD, serviços core, e ao menos uma peça de funcionalidade mínima deployável (ex: health-check, canary page). Sem exceções.
  • Cada SPEC entrega um incremento completo, testável e deployável
  • Cada SPEC posterior constrói sobre a anterior — sem gaps ou dependências reversas
  • Cross-cutting concerns (auth, logging, monitoring, error handling) fluem através dos specs desde o início, nunca são a última SPEC
  • Erro para o lado de menos SPECs: se algo parece grande demais, questione antes de dividir
Não crie uma SPEC de Go-Live. Validar integração em produção é teste, não implementação — não há fatia vertical para cortar, e um ticket de "conferir se o Stripe funciona" não tem o que construir. Cada SPEC entrega um incremento deployável e validado quando entra; a validação é distribuída ao longo do caminho, não concentrada no fim. O que precisa ser conferido na virada está na Seção 4 e vira checklist de cutover, não SPEC.
Se um item do lançamento envolve trabalho real de construção (migrar conteúdo, escrever um seed, criar um painel de operação), ele é uma SPEC normal como qualquer outra — pelo que constrói, não por ser "do go-live".
Formato:
SPEC 1: [Nome] — [goal em 1 frase]
SPEC 2: [Nome] — [goal em 1 frase]
A Lista de SPECs é o backlog do MVP. Cada SPEC é detalhada depois por 
to-spec
; se não couber numa janela de contexto, 
to-tickets
a quebra em fatias. Uma por vez — não vá além da lista aqui.
列出所有 SPEC，包括标题和一句话 goal。在继续之前，先向用户展示并请求批准。
关键排序规则：
  • SPEC 1 始终负责建立基础基础设施：项目 setup、Git、CI/CD、core 服务，以及至少一项可部署的最小功能（例如 health-check、canary page）。没有例外。
  • 每项 SPEC 都应交付一个完整、可测试且可部署的增量
  • 后续每项 SPEC 都建立在前一项之上——不得存在缺口或反向依赖
  • Cross-cutting concerns（auth、logging、monitoring、error handling）应从一开始就贯穿所有 specs，绝不能留到最后一项
  • 遇到疑问时，应倾向于使用更少的 SPEC：如果某项内容看起来过大，应先询问用户再拆分
不要创建 Go-Live SPEC。 验证生产集成属于测试，而不是实现——不存在可切割的纵向工作块，而“检查 Stripe 是否工作”的 ticket 也没有可构建的内容。每项 SPEC 都应交付一个可部署且纳入时即经过验证的增量；验证应分散在整个过程中，而不是集中在最后。上线切换时需要核查的内容位于第 4 节，并会形成 cutover checklist，而不是 SPEC。
如果某个上线事项涉及实际构建工作（迁移内容、编写 seed、创建运营面板），它就是一项普通 SPEC，与其他 SPEC 没有区别——判断依据是它构建了什么，而不是它是否属于 go-live。
格式：
SPEC 1: [Nome] — [goal em 1 frase]
SPEC 2: [Nome] — [goal em 1 frase]
SPEC 清单就是 MVP backlog。每项 SPEC 之后由 
to-spec
详细展开；如果内容无法装入 context window，则由 
to-tickets
将其拆分为切片。一次只处理一项——不要在此清单之外继续展开。

Seção 6 — Next Steps

第 6 节——Next Steps（后续步骤）

  • UX Expert Prompt: instrução curta para iniciar criação do documento de UI/UX com este PRD como input (somente se o projeto tiver UX/UI)
  • Checklist de Cutover: consolide aqui, em lista de checkbox, os campos "Como validar" de cada serviço externo da Seção 4. É o que precisa ser conferido com dado real em produção antes de abrir para usuários. Fecha com um smoke de ponta a ponta do fluxo principal do produto, executado por uma pessoa real.
markdown
undefined
  • UX Expert Prompt（UX 专家提示词）：一段简短指令，用于以本 PRD 为输入启动 UI/UX 文档的创建（仅当项目存在 UX/UI）
  • Cutover Checklist（上线切换检查清单）：在此以 checkbox 列表汇总第 4 节中每个外部服务的“如何验证”字段。这是在向用户开放之前，必须使用生产环境真实数据核查的内容。最后应由一名真实用户执行主要产品流程的端到端 smoke test。
markdown
undefined

Checklist de Cutover

Checklist de Cutover

  • [Serviço]: [critério "Como validar" da Seção 4]
  • [Serviço]: [critério "Como validar" da Seção 4]
  • Smoke end-to-end: [o fluxo principal, do cadastro ao valor entregue]

Este checklist **não é uma SPEC** e não vira SPEC nem tickets — é executado à mão na virada.

---
  • [Serviço]: [critério "Como validar" da Seção 4]
  • [Serviço]: [critério "Como validar" da Seção 4]
  • Smoke end-to-end: [o fluxo principal, do cadastro ao valor entregue]

此 checklist **不是 SPEC**，不会变成 SPEC 或 tickets——它需要在切换上线时手动执行。

---

Validação Final

最终验证

Antes de salvar, faça uma passagem verificando:
  • Todos os FRs têm correspondência rastreável nas SPECs?
  • Os NFRs têm critérios mensuráveis?
  • A sequência de SPECs é lógica e sem gaps?
  • A SPEC 1 estabelece infraestrutura E entrega algo deployável?
  • Cross-cutting concerns estão distribuídos, não concentrados no final?
  • Cada serviço externo na Seção 4 tem escolha única, rationale e critério de validação?
  • Não há nenhuma categoria de integração com duas opções em aberto ("X ou Y")?
  • Nenhuma SPEC é uma SPEC de "go-live" ou de validação pura — o que é conferência está no Checklist de Cutover, não na Lista de SPECs?
  • O Checklist de Cutover cobre todos os serviços da Seção 4 e fecha com um smoke end-to-end?
  • Stack Técnico tem uma linha por camada com Tecnologia e Diretório preenchidos?
Se qualquer item falhar, corrija antes de salvar.
保存前，请逐项检查：
  • 所有 FR 是否都能在 SPECs 中找到可追溯的对应项？
  • 所有 NFR 是否都有可衡量的标准？
  • SPEC 顺序是否合理且没有缺口？
  • SPEC 1 是否建立了基础设施，并且交付了可部署的内容？
  • Cross-cutting concerns 是否已分散到各阶段，而不是集中在最后？
  • 第 4 节中的每个外部服务是否都有唯一选择、rationale 和验证标准？
  • 是否不存在任何同时保留两个开放选项的集成类别（“X 或 Y”）？
  • 是否不存在任何“go-live”SPEC 或纯验证型 SPEC——需要核查的内容应位于 Cutover Checklist，而不是 SPEC 清单？
  • Cutover Checklist 是否覆盖第 4 节的所有服务，并以端到端 smoke test 收尾？
  • 技术 Stack 是否为每一层填写了技术和目录，并且每层仅占一行？
如果有任何一项未通过，请在保存前修正。

Bootstrap do Repositório

仓库 Bootstrap

Após salvar o PRD, verifique se o repositório remoto está configurado:
bash
git remote -v
Se não houver remote, crie agora — o remote precisa existir antes de configurar o tracker e detalhar a primeira SPEC:
bash
gh repo create [nome-do-projeto] --private --source=. --push
Use o nome do projeto em kebab-case. O 
--source=.
usa o diretório atual e 
--push
faz o push inicial.
Se já houver remote configurado: pule esta etapa.
保存 PRD 后，检查是否已配置远程仓库：
bash
git remote -v
如果没有 remote，则立即创建——必须在配置 tracker 并详细展开第一项 SPEC 之前准备好 remote：
bash
gh repo create [nome-do-projeto] --private --source=. --push
项目名称使用 kebab-case。
--source=.
使用当前目录，
--push
则执行初始 push。
如果已经配置了 remote：跳过此步骤。

Saída

输出

Salve em 
docs/prd.md
.
Ao finalizar, informe:
✅ PRD salvo em 
docs/prd.md
. Repositório remoto: [configurado | criado agora em github.com/user/repo]
Próximo passo: 
/setup-project
para configurar tracker, comandos e fluxo, depois 
/to-spec
na SPEC 1.
A Lista de SPECs é o backlog do MVP. Trabalhe uma por vez: 
/to-spec
→ (
/to-tickets
, se não couber numa janela) → 
/implement
.
保存到 
docs/prd.md
。
完成后，请告知：
✅ PRD 已保存到 
docs/prd.md
。 远程仓库：[已配置 | 已在 github.com/user/repo 创建]
下一步：运行 
/setup-project
配置 tracker、commands 和流程，然后对 SPEC 1 运行 
/to-spec
。
SPEC 清单就是 MVP backlog。逐项推进：
/to-spec
→（如果无法装入 context window，则运行 
/to-tickets
）→ 
/implement
。