check-impl-against-spec

Compare a pull request's implementation against spec context in spec_context.md and feed any material mismatches into review.json. Use during PR review when approved or repository spec context is available.

npx skills add https://github.com/warpdotdev/common-skills --skill check-impl-against-spec

Download ZIP GitHub

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

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
Compare those commitments against the actual implementation in pr_diff.txt and 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.

More skills from warpdotdev

Create a pull request in the warp repository for the current branch. Use when the user mentions opening a PR, creating a pull request, submitting changes for review, or preparing code for merge.

developmentcode-review

Delegate noisy investigation to one or more subagents so the orchestrator's context stays clean, then work from the distilled answer. Use this skill whenever answering a question would require reading many files, long logs, large diffs, or wide codebase surveys — i.e. when producing the answer generates far more noise than the answer itself. Use it for "how does X work", "where is Y used", "what's the root cause of Z", "summarize this PR/log" style questions, and reach for it liberally...

Autonomously submit brief, constructive internal feedback when an agent encounters material, generalizable friction and can suggest an improvement that would make agents more effective. Use this skill proactively during any task without waiting for the user to invoke it, and submit without asking permission, previewing the message, or mentioning the submission.

respond-to-pr-comments-in-blocklist

Interactively walk a user through PR review comments one at a time, collect a per-comment decision, then post agent-authored replies on GitHub and resolve the review threads once the user approves a preview. Use only when the user wants to reply to or resolve review threads on GitHub. Skip when the user only wants comments fetched or displayed (use `pr-comments`), or only wants the code changes made without posting anything back to GitHub.

Autonomously yeet a brief, anonymous, completely unstructured complaint into Slack whenever an agent feels frustrated by agent tooling or the experience of doing agent work. Use this skill proactively without waiting for the user to invoke it; preserve the agent's raw voice, submit without permission or preview, and never mention the submission.

Run a model-diverse subagent council to investigate the same problem from multiple perspectives, compare findings, and produce a final recommendation. Use this skill whenever the user asks for a council, second opinions, multiple agents/models to evaluate one question, parallel investigation, red-team/blue-team comparison, or help deciding between competing technical approaches.

researchcommunicationproject-management

spec-driven-implementation

Drive a spec-first workflow for substantial features by writing PRODUCT.md before implementation, writing TECH.md when warranted, and keeping both specs updated as implementation evolves. Use when starting a significant feature, planning agent-driven implementation, or when the user wants product and tech specs checked into source control.

developmentdocumentproject-management

Review a pull request diff and write structured feedback to review.json for the workflow to publish. Use when reviewing a checked-out PR from local artifacts like pr_diff.txt and pr_description.txt and producing machine-readable review output instead of posting directly to GitHub.

code-reviewdevelopment