SkillsAdd

warpdotdev/common-skills

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.

All-time #923 Trending #1001 Hot #66 First seen May 20, 2026
8-week activity · all time api

Installation

$ npx skills add warpdotdev/common-skills --skill check-impl-against-spec
View on skills.sh ↗ GitHub repository ↗

Security audits

Partner security reviews for this skill.

agent-trust-hub SAFE

Analyzed May 20, 2026

This skill performs code reviews by comparing implementations against a specification. It is generally safe but processes untrusted input from pull request diffs and descriptions, creating a surface for indirect prompt injection that could potentially influence the review process.

snyk LOW

Analyzed May 20, 2026

No issues detected.

socket Score 0.9000 · 0 alerts

Analyzed May 20, 2026

  • license 1
  • maintenance 1
  • quality 0.9
  • supply chain 1
  • vulnerability 1

0 alerts

Also in this package

Other skills from warpdotdev/common-skills · top by installs.

npx skills add warpdotdev/common-skills
review-pr 24.7K spec-driven-implementation 24.6K write-product-spec 24.6K write-tech-spec 24.5K resolve-merge-conflicts 24.5K fix-errors 24.5K implement-specs 24.4K diagnose-ci-failures 24.4K update-skill 24.4K create-pr 24.4K

Browse all from warpdotdev/common-skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 559
License LICENSE
Default branch main
Open issues 7
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,477 B
  • docs SUMMARY.md 237 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 23,000 installs

SKILL.md

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

  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

  1. Compare those commitments against the actual implementation in pr_diff.txt and the checked-out files.
  2. 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.
  3. 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.