warpdotdev.

bootstrap-issue-config

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

create-product-spec

Create 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-spec

Create 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-issue

Detect 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-local

Repo-specific dedupe guidance for oz-for-oss. Only the categories declared overridable by the core dedupe-issue skill may be specialized here.

implement-issue

Implement 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-specs

Implement 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-local

Repo-specific review guidance for oz-for-oss. Only the categories declared overridable by the core review-pr skill may be specialized here.

review-spec

Review 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-local

Repo-specific spec-review guidance for oz-for-oss. Only the categories declared overridable by the core review-spec skill may be specialized here.

security-review-pr

Audit a pull request diff for common security concerns (input validation, sanitization, authentication and authorization, secrets management, unsafe dependencies, and related risks) and fold findings into the same review.json produced by the base PR review. Use as a supplement to `review-pr` whenever a code PR is being reviewed.

security-review-spec

Audit a product or tech spec pull request diff for high-level security concerns (threat surface, authentication and authorization model, trust boundaries, sensitive data handling, secrets and key management, dependency posture, and abuse or misuse cases) and fold findings into the same review.json produced by the base spec review. Use as a supplement to `review-spec` whenever a spec PR is being reviewed.

spec-driven-implementation

Drive a spec-first workflow for substantial features by writing a product spec before implementation, writing a tech spec when warranted, and keeping both specs updated as implementation evolves. Use when starting a significant feature, planning agent-driven implementation, or when the user wants product and tech specs checked into source control.

triage-issue-local

Repo-specific triage guidance for oz-for-oss. Only the categories declared overridable by the core triage-issue skill may be specialized here.

update-dedupe

Update the repo-local dedupe-issue-local companion skill using closed-as-duplicate signals. Use when maintainers repeatedly close issues as duplicates of the same canonical thread and that pattern should feed back into triage duplicate detection.

update-pr-review

Update the repo-local review-pr-local and review-spec-local companion skills using human feedback left on pull request conversations. Use when aggregating replies to agent-authored PR review comments, incorporating broader human review comments, extracting repeated reviewer feedback, and refining .agents/skills/review-pr-local/SKILL.md and .agents/skills/review-spec-local/SKILL.md with evidence-backed adjustments.

update-triage

Update the repo-local triage-issue-local companion skill using signals from recently triaged issues (maintainer re-labels, re-opens, follow-up comments). Use when refining repo-specific triage heuristics and label taxonomy based on how maintainers overrode previous triage output.

verify-pr

Run repository-defined PR verification skills, aggregate the results, and hand back a verification report plus any uploaded artifacts without mutating GitHub directly.

write-product-spec

Write a PRODUCT.md-style spec for a significant user-facing feature in this repository, focused on detailed behavior and validation. Use when the user asks for a product spec, desired behavior doc, or PRD, wants to define feature behavior before implementation, or when the feature is substantial or behaviorally ambiguous enough that a written spec would improve implementation or review.

write-tech-spec

Write a TECH.md-style spec for a significant feature in this repository after researching the current codebase and implementation constraints. Use when the user asks for a technical spec, implementation plan, or architecture doc tied to a product spec.