review-pr-local

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

Refine Oz-For-Oss PR reviews with localized text and safety rules.

  • Ensures natural phrasing and consistent terminology in user messages.
  • Prevents broken output when dynamic data is missing or empty.
  • Preserves debugging context while prioritizing safe error messages.
  • Delivers specialized guidance aligned with core review-pr schema.

SKILL.md

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

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

This file is a companion to the core `review-pr` 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.

## User-facing strings

- Flag interpolated text that would read unnaturally at runtime (e.g. wrong casing after a sentence fragment like "The triage concluded that {summary}").
- Link text should be descriptive (e.g. "triage session on Warp"), not bare URLs or generic "click here" labels.
- Verify that terminology is consistent across related messages in the same PR.

## Graceful degradation

- When code renders optional dynamic data (URLs, session links, metadata), flag cases where a missing value would produce empty or broken output. The fix is usually to omit the element entirely and show a short fallback message.
- Prefer starting with generic, user-safe error messages over exposing internal details.

## Debugging and observability

- Do not suggest removing session links, workflow URLs, or other debugging context from error paths. These are valuable for post-incident investigation even when the operation failed.

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