review-spec-local

$npx mdskill add warpdotdev/oz-for-oss/review-spec-local

Validate spec structure and linking for oz-for-oss pull requests.

  • Ensures product and tech markdowns contain required sections.
  • Checks for GitHub issue references and relative path conventions.
  • Verifies internal links use repo-root-relative formatting.
  • Reports structural gaps in spec pull request files.

SKILL.md

.github/skills/review-spec-localView on GitHub ↗
---
name: review-spec-local
specializes: review-spec
description: Repo-specific spec-review guidance for oz-for-oss. Only the categories declared overridable by the core review-spec skill may be specialized here.
---

# Repo-specific spec-review guidance for `oz-for-oss`

This file is a companion to the core `review-spec` skill. It does not
redefine the review output schema, severity labels, safety rules, or
evidence rules. It only specializes the override categories the core
skill marks as overridable.

## Required spec sections in this repository

Spec pull requests in this repo land under `specs/GH<issue-number>/` and
typically include both a `product.md` and a `tech.md`. When reviewing, check that:

- `product.md` clearly states the problem, goals, non-goals, user experience, and validation plan
- `tech.md` clearly states the problem, relevant code, current state, proposed changes, risks, and follow-ups
- both files reference the originating GitHub issue by number in the top-level heading
- internal links reference files and line ranges using the repo-root-relative convention (for example ``path/file:line`` or ``path/file (start-end)``)

## Linking conventions

- Prefer repo-root-relative links over absolute filesystem paths in spec prose.
- When a spec references another spec in the same repository, link to it via its relative path under `specs/`.

More from warpdotdev/oz-for-oss

SkillDescription
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.
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.
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.