to-spec

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

To Spec

生成规格文档

Take the current conversation and codebase understanding and produce a spec (a PRD), then publish it as a GitHub issue. This is the validation gate of the workflow: a feature exists as a reviewed spec issue before any code is written.

Do not interview the user — synthesize what you already discussed. The issue tracker and label vocabulary come from

docs/agents/issue-tracker.md

; run

bootstrap

if it's missing. Use the glossary in

docs/agents/domain.md

throughout, and respect ADRs in the area you touch.

基于当前对话和对代码库的理解生成一份规格文档（即PRD），然后将其发布为GitHub Issue。这是工作流程中的验证关卡：在编写任何代码之前，功能需以经过审核的规格Issue形式存在。

请勿询问用户——直接整合已讨论的内容。Issue追踪器和标签词汇来自

docs/agents/issue-tracker.md

；如果该文件缺失，请运行

bootstrap

。全程使用

docs/agents/domain.md

中的术语表，并遵循你所涉及领域的ADR。

Process

流程

Explore the repo to understand current state if you haven't already. Stay on the minimalism ladder (
```
docs/agents/workflow.md
```
): name the minimum seams and the minimum interface the feature needs — never speculative scaffolding or "for later" flexibility.
Update the strategic docs so the feature is maintainable by humans and other agents. Sharpen any new terminology into
```
CONTEXT.md
```
and, if the feature commits to a non-obvious approach, record it as an ADR in
```
docs/adr/
```
(per
```
docs/agents/domain.md
```
). The spec issue references these.
Sketch the seams at which you'll test the feature. Prefer existing seams to new ones; use the highest seam possible; fewer is better (ideal: one). Name the feature-driven test(s) and the property-based stability invariant(s) you expect
```
implement
```
to satisfy. Confirm the seams match the user's expectations.
Write the spec using the template, then publish it as an issue. This issue is the meta issue for the work (strategic, like an epic) — label it
```
ready-for-human
```
so a human approves direction before any code. Set its milestone (the target release), assignee, project, type, and priority at creation; keep the body to relevant content only (per
```
docs/agents/issue-tracker.md
```
). Hand back the issue URL;
```
to-tickets
```
parents the tactical tickets to it.

<spec-template>

探索代码库以了解当前状态（如果尚未了解）。遵循极简原则（参考
```
docs/agents/workflow.md
```
）：明确功能所需的最少衔接点和最简接口——绝不添加推测性的脚手架或“为未来预留”的灵活性。
更新战略文档，确保功能可由人类和其他Agent维护。将任何新术语完善到
```
CONTEXT.md
```
中；如果功能采用了非显而易见的实现方式，请在
```
docs/adr/
```
中记录为ADR（遵循
```
docs/agents/domain.md
```
）。规格Issue需引用这些文档。
勾勒测试衔接点。优先使用现有衔接点而非新增；尽可能使用最高层级的衔接点；越少越好（理想情况：一个）。命名由功能驱动的测试以及你期望
```
implement
```
满足的基于属性的稳定性不变量。确认衔接点符合用户预期。
使用模板编写规格文档，然后发布为Issue。此Issue是工作的元Issue（战略层面，类似史诗任务）——为其添加
```
ready-for-human
```
标签，以便人类在编写代码前批准方向。创建时设置其里程碑（目标版本）、经办人、项目、类型和优先级；Issue正文仅保留相关内容（遵循
```
docs/agents/issue-tracker.md
```
）。返回Issue URL；
```
to-tickets
```
会基于此创建战术性子任务。

<spec-template>

Problem Statement

问题陈述

The problem the user faces, from the user's perspective.

从用户视角描述用户面临的问题。

Solution

解决方案

The solution, from the user's perspective.

从用户视角描述解决方案。

User Stories

用户故事

A long, numbered list, each:

As an <actor>, I want <feature>, so that <benefit>

. Cover all aspects of the feature — be extensive.

编号长列表，每条格式为：

作为<角色>，我想要<功能>，以便<收益>

。涵盖功能的所有方面——尽可能详尽。

Implementation Decisions

实现决策

Modules built/modified, their interfaces, technical clarifications, architectural decisions, schema changes, API contracts, specific interactions. Do NOT include file paths or code snippets (they go stale fast) — the exception is a snippet from a prototype that encodes a decision more precisely than prose.

</spec-template>

涉及的模块/修改的模块、它们的接口、技术说明、架构决策、 schema 变更、API 契约、具体交互。请勿包含文件路径或代码片段（它们很快会过时）——例外情况是原型中的代码片段，其比文字更精准地体现决策。

</spec-template>

Publishing

发布

Create the issue via the GitHub MCP (

GitHub_issue_write

) or

gh issue create

, per

docs/agents/issue-tracker.md

, setting labels, milestone, assignee, and project. Title it in the domain's vocabulary. Hand back the issue URL.

通过GitHub MCP（

GitHub_issue_write

）或

gh issue create

创建Issue（遵循

docs/agents/issue-tracker.md

），设置标签、里程碑、经办人和项目。使用领域词汇命名标题。返回Issue URL。

Boundaries

边界

Produces one spec issue. Does not break it into tickets (that's

to-tickets

) and does not implement it (that's

implement

生成一份规格Issue。不将其拆分为子任务（那是

to-tickets

的工作），也不实现功能（那是

implement

的工作）。