check-impl-against-spec
installsforks
How to install check-impl-against-spec?
warpdotdev/common-skills/check-impl-against-spec
$npx -y skills add warpdotdev/common-skills --skill check-impl-against-specCompare 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.
SKILL.md
| 1 | # Check implementation against spec |
| 2 | |
| 3 | Use this skill only when `spec_context.md` exists during PR review. |
| 4 | |
| 5 | ## Goal |
| 6 | |
| 7 | 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. |
| 8 | |
| 9 | ## Inputs |
| 10 | |
| 11 | - `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). |
| 12 | - `pr_diff.txt` contains the annotated diff for the PR. |
| 13 | - `pr_description.md` may contain additional scope or rationale. |
| 14 | - The working tree contains the PR branch contents. |
| 15 | |
| 16 | ## Process |
| 17 | |
| 18 | 1. Read `spec_context.md` and extract the concrete commitments it makes: |
| 19 | - required behaviors (from the product spec) |
| 20 | - required files or subsystems to change (from the tech spec) |
| 21 | - stated constraints |
| 22 | - required follow-up steps, validation, or migrations |
| 23 | 2. Compare those commitments against the actual implementation in `pr_diff.txt` and the checked-out files. |
| 24 | 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. |
| 25 | 4. Flag a mismatch only when it is material, such as: |
| 26 | - required behavior in the product spec is missing |
| 27 | - the implementation contradicts a spec decision |
| 28 | - the change introduces significant unplanned scope |
| 29 | - a required validation, migration, or compatibility step from the tech spec is absent |
| 30 | |
| 31 | ## Outputs |
| 32 | |
| 33 | - Do not create a separate report file. |
| 34 | - Fold spec-alignment findings into `review.json`. |
| 35 | - Put broad spec-drift concerns in the review summary. |
| 36 | - Add inline comments only when the mismatch can be tied to changed lines in the diff. |
| 37 | - Treat material spec drift as at least an important concern. |
| 38 | - If the implementation matches the spec closely enough, do not add comments just to mention alignment. |
| 39 | |
| 40 | ## Boundaries |
| 41 | |
| 42 | - Do not require literal one-to-one implementation of the spec when the PR achieves the same outcome safely. |
| 43 | - Do not speculate about spec details that are not actually present in `spec_context.md`. |
| 44 | - Do not post to GitHub directly. |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
