---
id: gh-check-impl-against-spec
name: "check-impl-against-spec"
url: https://skills.yangsir.net/skill/gh-check-impl-against-spec
author: warpdotdev
domain: ai-code-generation-quality
tags: ["code-review", "spec-compliance", "quality-assurance", "pr-automation", "development-workflow"]
install_count: 9500
rating: 4.50 (120 reviews)
github: https://github.com/warpdotdev/common-skills/tree/main/.agents/skills/check-impl-against-spec
---

# check-impl-against-spec

> 此技能在代码审查期间，将拉取请求的实现与技术规范进行对比，自动识别并报告任何实质性不符之处。它能显著减少手动审查的工作量，确保代码实现严格遵循设计要求，从而提升项目质量和开发效率。特别适用于需要严格遵守规范的开发流程。

**Stats**: 9,500 installs · 4.5/5 (120 reviews)

## Before / After 对比

### 规范审查效率

**Before**:

开发者在没有此技能之前，需要手动逐行比对代码实现与冗长的技术规范文档，耗时耗力且容易遗漏关键性差异，导致潜在的质量问题和返工。

**After**:

此技能能够自动高效地完成代码与规范的对比，快速识别实质性不符之处，大幅减少手动审查时间，确保代码质量和规范一致性，加速PR审批流程。

| Metric | Before | After | Change |
|---|---|---|---|
| 规范审查时长 | 120分钟 | 15分钟 | -88% |

## Readme

# Check implementation against spec

Use this skill only when `spec_context.md` exists during PR review.

## Goal

Determine whether the implementation in the checked-out PR materially matches the approved spec context. This is a supplement to the normal code review, not a separate output.

## Inputs

- `spec_context.md` contains the spec context to compare against. It may include both product spec content (intended behavior, acceptance criteria) and tech spec content (implementation details, file changes).
- `pr_diff.txt` contains the annotated diff for the PR.
- `pr_description.md` may contain additional scope or rationale.
- The working tree contains the PR branch contents.

## Process

1. Read `spec_context.md` and extract the concrete commitments it makes:
   - required behaviors (from the product spec)
   - required files or subsystems to change (from the tech spec)
   - stated constraints
   - required follow-up steps, validation, or migrations
2. Compare those commitments against the actual implementation in `pr_diff.txt` and the checked-out files.
3. Treat small implementation-level adjustments as acceptable when they preserve the spec's intent. Do not flag harmless differences in naming, structure, or low-level technique.
4. Flag a mismatch only when it is material, such as:
   - required behavior in the product spec is missing
   - the implementation contradicts a spec decision
   - the change introduces significant unplanned scope
   - a required validation, migration, or compatibility step from the tech spec is absent

## Outputs

- Do not create a separate report file.
- Fold spec-alignment findings into `review.json`.
- Put broad spec-drift concerns in the review summary.
- Add inline comments only when the mismatch can be tied to changed lines in the diff.
- Treat material spec drift as at least an important concern.
- If the implementation matches the spec closely enough, do not add comments just to mention alignment.

## Boundaries

- Do not require literal one-to-one implementation of the spec when the PR achieves the same outcome safely.
- Do not speculate about spec details that are not actually present in `spec_context.md`.
- Do not post to GitHub directly.


---
*Source: https://skills.yangsir.net/skill/gh-check-impl-against-spec*
*Markdown mirror: https://skills.yangsir.net/api/skill/gh-check-impl-against-spec/markdown*