Back to Details

to-spec

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
本技能获取当前的对话上下文和对代码库的理解，产出一份 spec。不要盘问用户——只综合你已经知道的内容。
issue 跟踪器和分类标签词汇应该已经提供给你了——如果没有，运行 
/setup-matt-pocock-skills
。
This skill takes the current conversation context and understanding of the codebase to produce a spec. Do not interrogate the user — only synthesize what you already know.
The issue tracker and category label vocabulary should have been provided to you — if not, run 
/setup-matt-pocock-skills
.

流程

Process

  1. 如果还没探索过，先探索仓库，了解代码库的当前状态。整个 spec 都使用项目的领域词汇表术语，并尊重你正在触碰的区域的任何 ADR。
  2. 勾勒出你将测试该功能的接缝。已有接缝应优先于新接缝。用尽可能高的接缝。如果需要新接缝，在你能达到的最高点提出。代码库中的接缝越少越好——理想数量是一个。
    与用户确认这些接缝符合他们的预期。
  3. 用下面的模板写 spec，然后发布到项目的 issue 跟踪器。打上 
    ready-for-agent
    分类标签——不需要再做分类。
<spec-template>
  1. If you haven't explored it yet, first explore the repository to understand the current state of the codebase. Use the project's domain glossary terms throughout the spec, and respect any ADRs in the areas you are touching.
  2. Outline the seams where you will test the feature. Existing seams should take precedence over new seams. Use the highest possible seams. If new seams are needed, propose them at the highest point you can achieve. The fewer seams in the codebase, the better — ideally one.
    Confirm with the user that these seams meet their expectations.
  3. Write the spec using the template below, then publish it to the project's issue tracker. Apply the 
    ready-for-agent
    category label — no further categorization is needed.
<spec-template>

问题陈述

Problem Statement

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

解决方案

Solution

问题的解决方案，从用户的角度描述。
The solution to the problem, described from the user's perspective.

用户故事

User Stories

一个长长的、编号的用户故事列表。每个用户故事遵循以下格式：
  1. 作为一个<角色>，我想要<功能>，以便<收益>
<user-story-example> 1. 作为手机银行客户，我想看到我账户的余额，以便能对消费做出更明智的决定 </user-story-example>
这份用户故事列表应该极其详尽，覆盖该功能的方方面面。
A long, numbered list of user stories. Each user story follows the format:
  1. As a <role>, I want <feature> so that <benefit>
<user-story-example> 1. As a mobile banking customer, I want to see my account balance so that I can make more informed spending decisions </user-story-example>
This list of user stories should be extremely detailed, covering all aspects of the feature.

实现决策

Implementation Decisions

已作出的实现决策列表。可以包括：
  • 将要构建/修改的模块
  • 将被修改的那些模块的接口
  • 来自开发者的技术澄清
  • 架构决策
  • Schema 变更
  • API 契约
  • 具体交互
不要包含具体的文件路径或代码片段。它们可能很快就过时了。
例外：如果原型产出了比散文更精确地编码某个决策的片段（状态机、reducer、schema、类型形态），把它内联进相关决策中，并简要注明它来自原型。裁到决策密集的部分——不是可运行的演示，只是重要的片段。
A list of implementation decisions made. This can include:
  • Modules to be built/modified
  • Interfaces of those modules that will be modified
  • Technical clarifications from developers
  • Architectural decisions
  • Schema changes
  • API contracts
  • Specific interactions
Do not include specific file paths or code snippets. They can quickly become outdated.
Exception: If a prototype produces a snippet (state machine, reducer, schema, type shape) that encodes a decision more precisely than prose, inline it into the relevant decision and briefly note that it comes from a prototype. Cut to the decision-dense parts — not a runnable demo, just the important snippets.

测试决策

Testing Decisions

已作出的测试决策列表。包括：
  • 什么构成好测试的描述（只测外部行为，不测实现细节）
  • 哪些模块将被测试
  • 测试的先例（即代码库中类似的测试类型）
A list of testing decisions made. Include:
  • A description of what constitutes a good test (test only external behavior, not implementation details)
  • Which modules will be tested
  • Testing precedents (i.e., similar types of tests in the codebase)

范围外

Out of Scope

本 spec 范围之外的内容描述。
A description of content outside the scope of this spec.

补充说明

Additional Notes

关于该功能的任何补充说明。
</spec-template>
Any additional notes about the feature.
</spec-template>