to-spec
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese这个 skill 使用当前 conversation context 和 codebase understanding 产出 spec（你可能把这种文档称为 PRD）。不要访谈用户，只综合你已经知道的内容。
Issue tracker 和 triage label vocabulary 应该已经提供给你；如果没有，运行 。
/setup-matt-pocock-skillsThis skill uses the current conversation context and codebase understanding to generate a spec (you may refer to this type of document as PRD). Do NOT interview users, only synthesize what you already know.
Issue tracker and triage label vocabulary should have been provided to you; if not, run .
/setup-matt-pocock-skillsProcess
Process
-
如果还没有探索 repo，先探索它以理解 codebase 当前状态。在 spec 中始终使用项目 domain glossary vocabulary，并遵守相关 ADRs。
-
草拟你准备在哪些 seams 上测试这个 feature。优先使用现有 seams，而不是新增 seams。使用尽可能高层的 seam。如果确实需要新增 seams，尽可能在最高层提出。
Seams 越少越好，理想数量是一个。与用户确认这些 seams 是否符合预期。
- 使用下面模板写 spec，并发布到项目 issue tracker。应用 triage label；不需要额外 triage。
ready-for-agent
-
If you haven't explored the repo yet, explore it first to understand the current state of the codebase. Always use the project's domain glossary vocabulary in the spec and comply with relevant ADRs.
-
Draft the seams you plan to test this feature on. Prioritize using existing seams instead of adding new ones. Use the highest-level seams possible. If new seams are indeed needed, propose them at the highest level possible.
The fewer seams the better, ideally one. Confirm with the user whether these seams meet expectations.
- Write the spec using the template below and publish it to the project issue tracker. Apply the triage label; no additional triage is required.
ready-for-agent
Problem Statement
Problem Statement
用户正在面对的问题，从用户视角描述。
The problem the user is facing, described from the user's perspective.
Solution
Solution
问题的解决方案，从用户视角描述。
The solution to the problem, described from the user's perspective.
User Stories
User Stories
一份很长的编号 user stories 列表。每条 user story 使用以下格式：
- As an <actor>, I want a <feature>, so that <benefit>
这份 user stories 列表应该非常完整，覆盖 feature 的所有方面。
A long numbered list of user stories. Each user story follows the format:
- As an <actor>, I want a <feature>, so that <benefit>
This list of user stories should be very comprehensive, covering all aspects of the feature.
Implementation Decisions
Implementation Decisions
已作出的 implementation decisions 列表。可以包括：
- 将 build/modify 的 modules
- 将 modify 的 module interfaces
- 来自 developer 的技术澄清
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions
不要包含具体 file paths 或 code snippets。它们可能很快过时。
例外：如果 prototype 产出的 snippet 比 prose 更精确地编码了某个决策（state machine、reducer、schema、type shape），可以内联到相关 decision 中，并简短说明它来自 prototype。只保留决策密集部分，不要放完整 working demo。
A list of made implementation decisions. It can include:
- Modules to build/modify
- Module interfaces to modify
- Technical clarifications from developers
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions
Do not include specific file paths or code snippets. They may become outdated quickly.
Exception: If a snippet generated by a prototype encodes a decision more precisely than prose (state machine, reducer, schema, type shape), it can be inline in the relevant decision with a brief note stating it comes from a prototype. Only keep the decision-dense parts, do not include a complete working demo.
Testing Decisions
Testing Decisions
已作出的 testing decisions 列表。包括：
- 什么是好测试的描述（只测试 external behavior，不测试 implementation details）
- 哪些 modules 会被测试
- 测试的 prior art（即 codebase 中类似类型的 tests）
A list of made testing decisions. Includes:
- Description of what constitutes a good test (only test external behavior, not implementation details)
- Which modules will be tested
- Prior art for testing (i.e., similar types of tests in the codebase)
Out of Scope
Out of Scope
本 spec 范围外事项的描述。
Description of items outside the scope of this spec.
Further Notes
Further Notes
关于 feature 的其他 notes。
</spec-template>Other notes about the feature.
</spec-template>