---
id: gh-implement-specs
name: "implement-specs"
url: https://skills.yangsir.net/skill/gh-implement-specs
author: warpdotdev
domain: ai-project-management-collaboration
tags: ["feature-implementation", "spec-alignment", "development-workflow", "pr-management", "code-consistency"]
install_count: 1800
rating: 4.30 (120 reviews)
github: https://github.com/warpdotdev/common-skills/tree/main/.agents/skills/implement-specs
---

# implement-specs

> 根据已批准的产品和技术规范，在同一PR中实现新功能，确保代码与规范在整个开发过程中保持一致。此技能用于产品和技术规范获批后，指导功能构建。

**Stats**: 1,800 installs · 4.3/5 (120 reviews)

## Before / After 对比

### 减少规范与代码不一致导致的返工时间

**Before**:

在没有明确规范同步流程时，开发人员可能在实现功能后才发现代码与产品或技术规范存在偏差，导致需要花费大量时间进行返工和修改，延误发布周期。

**After**:

通过在同一PR中同步更新规范和代码，开发人员能够及时发现并解决不一致问题，显著减少因规范偏差导致的返工，提高开发效率和代码质量。

| Metric | Before | After | Change |
|---|---|---|---|
| 因规范不一致导致的返工时间 | 60分钟 | 10分钟 | -83% |

## Readme

# implement-specs

Implement an approved feature from `PRODUCT.md` and `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.

## 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

## Workflow

### 1. Read the approved specs first

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.

### 2. Offer optional implementation aids for large features

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.

### 3. Plan and implement against the specs

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.

### 4. Update specs as the implementation evolves

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.

### 5. Verify against the specs

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.

## Related Skills

- `spec-driven-implementation`
- `write-product-spec`
- `write-tech-spec`


---
*Source: https://skills.yangsir.net/skill/gh-implement-specs*
*Markdown mirror: https://skills.yangsir.net/api/skill/gh-implement-specs/markdown*