check-impl-against-spec
This skill automatically compares a pull request's implementation against its technical specification during code review, identifying and reporting any material mismatches. It significantly reduces manual review effort, ensuring code adheres strictly to design requirements, thereby enhancing project quality and development efficiency. Particularly useful in development processes requiring strict adherence to specifications.
npx skills add https://github.com/warpdotdev/common-skills --skill check-impl-against-specBefore / After Comparison
1 组Without this skill, developers had to manually compare code implementation against lengthy technical specification documents line by line, which was time-consuming, labor-intensive, and prone to missing critical differences, leading to potential quality issues and rework.
This skill automatically and efficiently compares code with specifications, quickly identifying material mismatches. It significantly reduces manual review time, ensures code quality and specification consistency, and accelerates the PR approval process.
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.mdcontains 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.txtcontains the annotated diff for the PR.pr_description.mdmay contain additional scope or rationale.- The working tree contains the PR branch contents.
Process
- Read
spec_context.mdand 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
- Compare those commitments against the actual implementation in
pr_diff.txtand the checked-out files. - 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.
- 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.
User Reviews (0)
Write a Review
No reviews yet
Statistics
User Rating
Rate this Skill