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.
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.
review-prwarpdotdevReview 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.27.8 k27.8 k instalaciones en skills.sh0
spec-driven-implementationwarpdotdevDrive 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.27.7 k27.7 k instalaciones en skills.sh0
write-product-specwarpdotdevWrite a PRODUCT.md spec for a significant user-facing feature in Warp, focused on detailed behavior and validation. Use when the user asks for a product spec, desired behavior doc, or PRD, wants to define feature behavior before implementation, or when the feature is substantial or behaviorally ambiguous enough that a written spec would improve implementation or review.27.6 k27.6 k instalaciones en skills.sh0
fix-errorswarpdotdevFix compilation errors, linting issues, and test failures in the warp Rust codebase. Covers presubmit checks, WASM-specific errors, and running specific tests. Use when the user hits build errors, clippy or fmt failures, test failures, or needs to run or interpret presubmit before a PR.27.5 k27.5 k instalaciones en skills.sh0
write-tech-specwarpdotdevWrite a TECH.md spec for a significant Warp feature after researching the current codebase and implementation constraints. Use when the user asks for a technical spec, implementation plan, or architecture doc tied to a product spec.27.5 k27.5 k instalaciones en skills.sh0
