check-impl-against-spec
$
npx mdskill add warpdotdev/oz-for-oss/check-impl-against-specVerify PR code matches approved spec context immediately.
- Detects behavioral or structural deviations from documented requirements.
- Reads spec_context.md and pr_diff.txt for comparison data.
- Evaluates intent preservation while ignoring harmless naming changes.
- Outputs flagged mismatches directly into review.json.
SKILL.md
.github/skills/check-impl-against-specView on GitHub ↗
--- name: check-impl-against-spec description: 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. --- # 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.txt` may contain additional scope or rationale. - The working tree contains the PR branch contents. ## How to evaluate spec alignment 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 2. Compare those commitments against the actual implementation in `pr_diff.txt` and the checked-out files. 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. 4. 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 ## How to report mismatches - 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 from warpdotdev/oz-for-oss
- bootstrap-issue-configBootstrap the issue triage configuration for a repository by analyzing existing issues, labels, and contributors to generate `.github/issue-triage/config.json` and `.github/STAKEHOLDERS`. Use when setting up triage automation on a new or existing repository for the first time.
- create-product-specCreate a product spec from a GitHub issue in this repository by applying the local shared `write-product-spec` workflow with Oz-specific issue context and output paths. Use when an issue should be turned into a product spec artifact stored under `specs/GH<issue-number>/product.md` and the agent should prepare file changes only, without creating commits or pull requests itself unless a cloud workflow explicitly asks for it.
- create-tech-specCreate a technical spec from a GitHub issue in this repository by applying the local shared `write-tech-spec` workflow with Oz-specific issue context and output paths. Use when an issue should be turned into a tech spec artifact stored under `specs/GH<issue-number>/tech.md` and the agent should prepare file changes only, without creating commits or pull requests itself unless a cloud workflow explicitly asks for it.
- dedupe-issueDetect duplicate GitHub issues by comparing the incoming issue's title and description against the repository issue list. Use during triage to identify 2+ existing issues that are similar and surface them as potential duplicates.
- dedupe-issue-localRepo-specific dedupe guidance for oz-for-oss. Only the categories declared overridable by the core dedupe-issue skill may be specialized here.
- implement-issueImplement a GitHub issue in this repository by applying the local shared `implement-specs` workflow with Oz-specific issue, spec-context, and summary-file handling. Use when issue details are provided in the prompt and the agent should produce the repository diff and a concise implementation summary, without creating commits or pull requests itself unless a cloud workflow explicitly asks for it.
- implement-specsImplement an approved feature from the repository's product and tech specs, keeping specs and code aligned in the same change as implementation evolves. Use after the product and tech specs are approved and the next step is building the feature.
- review-pr-localRepo-specific review guidance for oz-for-oss. Only the categories declared overridable by the core review-pr skill may be specialized here.
- review-specReview a spec/plan pull request diff and write structured feedback to review.json for the workflow to publish. Use when reviewing a PR that only modifies files under specs/ and producing machine-readable review output instead of posting directly to GitHub.
- review-spec-localRepo-specific spec-review guidance for oz-for-oss. Only the categories declared overridable by the core review-spec skill may be specialized here.