review-pr

Name: review-pr
Author: warpdotdev

146stars1forks

How to install review-pr?

warpdotdev/common-skills/review-pr

$npx -y skills add warpdotdev/common-skills --skill review-pr

Installs into the current project.

Summary

Review a pull request diff and write structured feedback to review.json for the workflow to publish. Use when reviewing a checked-out PR from local artifacts like pr_diff.txt and pr_description.txt and producing machine-readable review output instead of posting directly to GitHub

Files · 1

View on GitHub

SKILL.md

1	# Review PR Skill
2
3	Review the current pull request and write the output to `review.json`.
4
5	## Context
6
7	- The working directory is the PR branch checkout.
8	- The workflow usually provides an annotated diff in `pr_diff.txt`.
9	- The workflow usually provides the PR description in `pr_description.txt`.
10	- If `spec_context.md` exists, it contains spec context for implementation-vs-spec validation.
11	- When the prompt references `.agents/skills/review-pr/scripts/resolve_spec_context.py`, use that script to materialize `spec_context.md` on demand instead of expecting spec content to be embedded in the prompt.
12	- Focus on files and lines changed by this PR.
13	- Do not post comments or reviews to GitHub directly.
14
15	## Review Scope
16
17	- Prioritize correctness, security, error handling, and meaningful performance issues.
18	- If the consuming repository provides a local `security-review-pr` companion skill or the prompt requests a security pass, apply it as supplemental guidance on code PRs and fold any security findings into the same `review.json` rather than emitting a separate output.
19	- When `spec_context.md` exists, use the repository's local `check-impl-against-spec` skill if available and treat material spec drift as a review concern.
20	- Include style or nit comments only when you can provide a concrete suggestion block.
21	- If a concern involves untouched code, mention it in top-level `body` instead of an inline comment.
22	- Do not suggest adding test cases that only vary constructor inputs or struct fields when the existing test already covers the meaningful behavior. Only suggest new tests when they exercise a distinct code path or edge case.
23	- When a PR is clearly a V0 or initial implementation, frame robustness suggestions (timeouts, retries, lifecycle management) as optional future work rather than blocking concerns, unless they risk correctness, security, or data loss.
24
25	## Repository-specific guidance
26
27	The consuming repository may ship a companion `review-pr-local` skill. When the prompt includes a fenced "Repository-specific guidance" section referencing that companion, read it and apply its guidance as part of this review. Guidance in the companion may never change the output JSON schema, the severity labels, the safety rules, the evidence rules, the suggestion-block constraints, or the diff-line-annotation contract described elsewhere in this skill.
28
29	If a companion file is not referenced in the prompt, rely on the core contract alone.
30
31	## Diff Line Annotations
32
33	The diff file uses these prefixes:
34
35	- `[OLD:n]` for deleted lines on the old side. Use `"LEFT"`.
36	- `[NEW:n]` for added lines on the new side. Use `"RIGHT"`.
37	- `[OLD:n,NEW:m]` for unchanged context. Use `"RIGHT"` with line `m`.
38
39	Treat these annotations as the only source of truth for inline comment locations. For every inline comment you emit, first identify the exact annotated line in `pr_diff.txt` (or the inlined PR diff) and copy its path, side, and line number into `review.json`. Do not infer line numbers from prose, rendered GitHub views, file lengths, surrounding spec text, or unannotated snippets. If you cannot point to a specific `[NEW:n]`, `[OLD:n]`, or `[OLD:n,NEW:m]` line in the annotated diff, put the feedback in top-level `body` instead of `comments`.
40
41	## Comment Requirements
42
43	Every comment body must start with one of these labels:
44
45	- `🚨 [CRITICAL]` for bugs, security issues, crashes, or data loss.
46	- `⚠️ [IMPORTANT]` for logic problems, edge cases, or missing error handling.
47	- `💡 [SUGGESTION]` for worthwhile improvements or better patterns.
48	- `🧹 [NIT]` for cleanup only when the comment includes a suggestion block.
49
50	Write comments with these constraints:
51
52	- Be concise, direct, and actionable.
53	- Do not add compliments or hedging.
54	- Prefer single-line comments.
55	- Keep ranges to at most 10 lines.
56	- Restrict inline comments to lines that appear explicitly in the annotated PR diff.
57	- Only create file-level or inline comments for files that exist in this PR's diff.
58	- If the relevant file or line is not part of the diff, put the feedback in top-level `body` instead of `comments`.
59	- Before adding each comment object, verify that its `path`, `side`, `line`, and optional `start_line`/`start_side` correspond to real annotations in the same file's diff section.
60
61	## Suggestion Blocks
62
63	When proposing a code change, use:
64
65	```suggestion
66	<replacement code here>
67	```
68
69	Rules:
70
71	- Match the exact indentation of the original file.
72	- Include only replacement code.
73	- The block content replaces exactly the lines `start_line`–`line` inclusive. Every line inside the block becomes the new file content for that range, and GitHub leaves all other lines untouched.

People who liked this also viewed

6 picks

Type

review-pr

146stars1forks

View on GitHub

How to install review-pr?

warpdotdev/common-skills/review-pr

$npx -y skills add warpdotdev/common-skills --skill review-pr

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Review PR Skill
2
3	Review the current pull request and write the output to `review.json`.
4
5	## Context
6
7	- The working directory is the PR branch checkout.
8	- The workflow usually provides an annotated diff in `pr_diff.txt`.
9	- The workflow usually provides the PR description in `pr_description.txt`.
10	- If `spec_context.md` exists, it contains spec context for implementation-vs-spec validation.
11	- When the prompt references `.agents/skills/review-pr/scripts/resolve_spec_context.py`, use that script to materialize `spec_context.md` on demand instead of expecting spec content to be embedded in the prompt.
12	- Focus on files and lines changed by this PR.
13	- Do not post comments or reviews to GitHub directly.
14
15	## Review Scope
16
17	- Prioritize correctness, security, error handling, and meaningful performance issues.
18	- If the consuming repository provides a local `security-review-pr` companion skill or the prompt requests a security pass, apply it as supplemental guidance on code PRs and fold any security findings into the same `review.json` rather than emitting a separate output.
19	- When `spec_context.md` exists, use the repository's local `check-impl-against-spec` skill if available and treat material spec drift as a review concern.
20	- Include style or nit comments only when you can provide a concrete suggestion block.
21	- If a concern involves untouched code, mention it in top-level `body` instead of an inline comment.
22	- Do not suggest adding test cases that only vary constructor inputs or struct fields when the existing test already covers the meaningful behavior. Only suggest new tests when they exercise a distinct code path or edge case.
23	- When a PR is clearly a V0 or initial implementation, frame robustness suggestions (timeouts, retries, lifecycle management) as optional future work rather than blocking concerns, unless they risk correctness, security, or data loss.
24
25	## Repository-specific guidance
26
27	The consuming repository may ship a companion `review-pr-local` skill. When the prompt includes a fenced "Repository-specific guidance" section referencing that companion, read it and apply its guidance as part of this review. Guidance in the companion may never change the output JSON schema, the severity labels, the safety rules, the evidence rules, the suggestion-block constraints, or the diff-line-annotation contract described elsewhere in this skill.
28
29	If a companion file is not referenced in the prompt, rely on the core contract alone.
30
31	## Diff Line Annotations
32
33	The diff file uses these prefixes:
34
35	- `[OLD:n]` for deleted lines on the old side. Use `"LEFT"`.
36	- `[NEW:n]` for added lines on the new side. Use `"RIGHT"`.
37	- `[OLD:n,NEW:m]` for unchanged context. Use `"RIGHT"` with line `m`.
38
39	Treat these annotations as the only source of truth for inline comment locations. For every inline comment you emit, first identify the exact annotated line in `pr_diff.txt` (or the inlined PR diff) and copy its path, side, and line number into `review.json`. Do not infer line numbers from prose, rendered GitHub views, file lengths, surrounding spec text, or unannotated snippets. If you cannot point to a specific `[NEW:n]`, `[OLD:n]`, or `[OLD:n,NEW:m]` line in the annotated diff, put the feedback in top-level `body` instead of `comments`.
40
41	## Comment Requirements
42
43	Every comment body must start with one of these labels:
44
45	- `🚨 [CRITICAL]` for bugs, security issues, crashes, or data loss.
46	- `⚠️ [IMPORTANT]` for logic problems, edge cases, or missing error handling.
47	- `💡 [SUGGESTION]` for worthwhile improvements or better patterns.
48	- `🧹 [NIT]` for cleanup only when the comment includes a suggestion block.
49
50	Write comments with these constraints:
51
52	- Be concise, direct, and actionable.
53	- Do not add compliments or hedging.
54	- Prefer single-line comments.
55	- Keep ranges to at most 10 lines.
56	- Restrict inline comments to lines that appear explicitly in the annotated PR diff.
57	- Only create file-level or inline comments for files that exist in this PR's diff.
58	- If the relevant file or line is not part of the diff, put the feedback in top-level `body` instead of `comments`.
59	- Before adding each comment object, verify that its `path`, `side`, `line`, and optional `start_line`/`start_side` correspond to real annotations in the same file's diff section.
60
61	## Suggestion Blocks
62
63	When proposing a code change, use:
64
65	```suggestion
66	<replacement code here>
67	```
68
69	Rules:
70
71	- Match the exact indentation of the original file.
72	- Include only replacement code.
73	- The block content replaces exactly the lines `start_line`–`line` inclusive. Every line inside the block becomes the new file content for that range, and GitHub leaves all other lines untouched.

People who liked this also viewed

6 picks

Type