implement-specs

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

implement-specs

Implement an approved feature from

PRODUCT.md

and

TECH.md

实现

PRODUCT.md

和

TECH.md

中已获批的功能。

Overview

概述

Use this skill after the product and tech specs are approved. The goal is to build the feature described by the specs while keeping the checked-in specs and the implementation aligned as the work evolves.

Approved specs should live directly under a ticket-named directory in

specs/

, for example

specs/APP-1234/PRODUCT.md

and

specs/APP-1234/TECH.md

In many cases, the implementation should be pushed in the same PR as the product and tech specs. As the engineer iterates, changes to

PRODUCT.md

TECH.md

, and the code should all be pushed in that same PR so review stays anchored to the feature that will actually ship.

在产品和技术规格获批后使用此技能。目标是根据规格文档描述开发功能，同时在工作推进过程中确保已提交的规格文档与实现代码保持一致。

获批的规格文档应直接存放在

specs/

specs/APP-1234/PRODUCT.md

和

specs/APP-1234/TECH.md

。

多数情况下，实现代码应与产品和技术规格文档提交到同一个PR中。工程师迭代开发时，对

PRODUCT.md

、

TECH.md

和代码的修改都应提交到同一个PR，以便评审始终围绕最终要发布的功能展开。

Prerequisites

前提条件

Before using this skill:

confirm that
```
PRODUCT.md
```
exists
confirm that
```
TECH.md
```
exists when the feature warranted one
confirm that the relevant specs have been reviewed and approved enough to start implementation

使用此技能前需确认：

```
PRODUCT.md
```
已存在
若功能需要技术规格，则
```
TECH.md
```
已存在
相关规格文档已通过评审并获批，可以开始实现

Workflow

工作流程

1. Read the approved specs first

1. 先阅读获批的规格文档

Treat:

```
PRODUCT.md
```
as the source of truth for user-facing behavior
```
TECH.md
```
as the source of truth for architecture, sequencing, and implementation shape

Make sure you understand the expected behavior, constraints, risks, and validation plan before writing code.

将以下文档视为权威依据：

```
PRODUCT.md
```
：用户侧行为的权威依据
```
TECH.md
```
：架构、执行顺序和实现框架的权威依据

编写代码前，务必理解预期行为、约束条件、风险点和验证方案。

2. Offer optional implementation aids for large features

2. 为大型功能提供可选的实现辅助工具

For large or long-running features, optionally offer one of these aids to the user before implementation begins:

```
PROJECT_LOG.md
```
to track checkpoints, explored paths, partial findings, and current implementation state
```
DECISIONS.md
```
to capture concrete product and technical decisions made during the PRD and tech design process

These are optional aids, not required deliverables. Offer them when they would reduce confusion or help future agents avoid re-exploring the same paths.

对于大型或周期较长的功能，可在开始实现前为用户提供以下辅助工具之一：

```
PROJECT_LOG.md
```
：用于记录检查点、探索过的方案、阶段性结论和当前实现状态
```
DECISIONS.md
```
：用于记录PRD和技术设计过程中做出的具体产品与技术决策

这些是可选的辅助工具，并非强制交付物。当它们能减少混淆或帮助后续开发人员避免重复探索相同路径时，才推荐使用。

3. Plan and implement against the specs

3. 基于规格文档规划并实现功能

Break the work into concrete implementation steps, then implement the feature against the approved specs.

During implementation:

keep behavior aligned with
```
PRODUCT.md
```
keep architecture and sequencing aligned with
```
TECH.md
```
add or update tests and verification artifacts as the work lands

Use the same PR for the specs and implementation when practical so the full feature evolution is reviewable in one place.

将工作拆解为具体的实现步骤，然后根据获批的规格文档开发功能。

实现过程中：

确保功能行为与
```
PRODUCT.md
```
一致
确保架构和执行顺序与
```
TECH.md
```
一致
随着工作推进，添加或更新测试及验证工件

在可行的情况下，将规格文档和实现代码提交到同一个PR，以便在一处查看功能的完整演进过程。

4. Update specs as the implementation evolves

4. 随着实现推进更新规格文档

If implementation reveals that the intended behavior or design should change, update the checked-in specs rather than letting them go stale.

In particular:

update
```
PRODUCT.md
```
when user-facing behavior, UX, edge cases, or success criteria change
update
```
TECH.md
```
when architecture, sequencing, module boundaries, or validation strategy change
keep those updates in the same PR as the corresponding code changes

The PR should describe the feature that actually ships, not just the initial draft of the specs.

如果实现过程中发现需要修改预期行为或设计，应更新已提交的规格文档，避免文档过时。

具体来说：

当用户侧行为、UX、边缘场景或成功标准发生变化时，更新
```
PRODUCT.md
```
当架构、执行顺序、模块边界或验证策略发生变化时，更新
```
TECH.md
```
将这些更新与对应的代码修改提交到同一个PR中

PR应描述最终要发布的功能，而非仅展示规格文档的初始版本。

5. Verify against the specs

5. 基于规格文档验证功能

Before considering the work complete, verify that the code matches the current specs.

Prefer:

unit tests and regression coverage that follow the repository's local testing conventions
integration or end-to-end tests for important user flows

在确认工作完成前，需验证代码是否与当前规格文档一致。

优先选择以下方式：

遵循仓库本地测试规范的单元测试和回归测试覆盖
针对重要用户流程的集成测试或端到端测试

Best Practices

最佳实践

Keep specs and code synchronized throughout implementation.
Prefer updating the spec immediately when decisions change rather than batching spec cleanup until the end.
Use optional tracking documents only when they add real value for a complex feature.
Keep the same PR coherent: spec updates, code changes, tests, and optional tracking docs should all support the same feature narrative.

在整个实现过程中保持规格文档与代码同步。
当决策发生变化时，优先立即更新规格文档，而非等到最后批量整理。
仅当可选跟踪文档能为复杂功能带来实际价值时才使用。
保持同一个PR的一致性：规格文档更新、代码修改、测试及可选跟踪文档都应围绕同一个功能展开。

implement-specs

Original

Translation

implement-specs

implement-specs

Overview

概述

Prerequisites

前提条件

Workflow

工作流程

1. Read the approved specs first

1. 先阅读获批的规格文档

2. Offer optional implementation aids for large features

2. 为大型功能提供可选的实现辅助工具

3. Plan and implement against the specs

3. 基于规格文档规划并实现功能

4. Update specs as the implementation evolves

4. 随着实现推进更新规格文档

5. Verify against the specs

5. 基于规格文档验证功能

Best Practices

最佳实践

Related Skills

相关技能