Back to Details

check-impl-against-spec

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Check implementation against spec

检查实现是否符合规范

Use this skill only when 
spec_context.md
exists during PR review.
仅在PR审查期间存在
spec_context.md
时使用此技能。

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.
确定已检出PR中的实现是否与已批准的规范上下文实质性匹配。这是对常规代码审查的补充，而非独立输出。

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.
  • spec_context.md
    包含用于对比的规范上下文，可能同时包含产品规范内容（预期行为、验收标准）和技术规范内容（实现细节、文件变更）。
  • pr_diff.txt
    包含PR的带注释差异内容。
  • pr_description.md
    可能包含额外的范围说明或基本原理。
  • 工作目录包含PR分支的内容。

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
  1. 读取
    spec_context.md
    并提取其中明确的要求：
    • 产品规范中的必填行为
    • 技术规范中要求变更的文件或子系统
    • 规定的约束条件
    • 要求的后续步骤、验证或迁移操作
  2. 将这些要求与
    pr_diff.txt
    和已检出文件中的实际实现进行对比。
  3. 当调整保留了规范意图时，将小范围的实现层面调整视为可接受。不要标记命名、结构或底层技术方面的无害差异。
  4. 仅当差异具有实质性时才标记不匹配，例如：
    • 产品规范中的必填行为缺失
    • 实现与规范决策相矛盾
    • 变更引入了重大的计划外范围
    • 技术规范中要求的验证、迁移或兼容性步骤缺失

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.
  • 不要创建单独的报告文件。
  • 将规范一致性检查结果整合到
    review.json
    中。
  • 将广泛的规范偏离问题放在审查摘要中。
  • 仅当不匹配可关联到差异中的变更行时，添加行内注释。
  • 将实质性的规范偏离视为至少是重要问题。
  • 如果实现与规范足够接近，不要仅为提及一致性而添加注释。

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.
  • 当PR安全地达成相同结果时，不要求严格按照规范逐字实现。
  • 不要对
    spec_context.md
    中未实际提及的规范细节进行推测。
  • 不要直接发布到GitHub。