pr

Open a draft pull request on GitHub and drive CI review rounds until it is ready. MUST use when you want to create/open a PR.

Quality

88%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Quality

Content

92%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content is highly actionable with strong, executable workflows and well-engineered validation/feedback loops for the review-round lifecycle. Its main weakness is progressive disclosure: a long monolithic body that mixes core PR creation with the EE companion and screenshot-hosting details that could be externalized.

Suggestions

Move the EE companion PR workflow and the screenshot upload pipeline into separate reference files referenced one level deep from the body, keeping the core PR-creation flow lean.

If a skill bundle is intended, add the referenced scripts (e.g. .agents/skills/pr/review-round.sh) under scripts/ and link to them explicitly so the bundle structure matches the in-body references.

Dimension	Reasoning	Score
Conciseness	The body is dense but nearly every token is non-obvious, repo-specific knowledge (EE symlink gotchas, idempotent /review semantics, base64-via-stdin upload failure, exact marker-comment rules), with no padding of concepts Claude already knows. It is not 2 because there is little that could be cut without losing actionable detail.	3 / 3
Actionability	It provides copy-paste-ready commands (gh pr create --draft, git diff main...HEAD --name-only, the jq/base64 screenshot upload, marker-comment gh commands) with concrete flags and templates. It is not 2 because the guidance is executable rather than pseudocode and includes specific examples.	3 / 3
Workflow Clarity	Sequences are numbered with explicit validation checkpoints and feedback loops ("Review the diff before creating the PR", "Codex verdict missing -> round is void", "only flip to ready once every verdict is a go", "do not post the marker if P0/P1 unaddressed"). It is not 2 because error-recovery and pre-merge checkpoints are explicit, not implicit.	3 / 3
Progressive Disclosure	No skill bundle files exist (references/scripts/assets absent), and the body is a self-contained ~180-line file with substantial inline material (full EE companion workflow, screenshot pipeline) that could be split into one-level-deep references. It is not 3 because content that belongs in separate files is inline, and not 1 because sections are clearly organized with signaled external pointers (docs/enterprise.md, review-round.sh).	2 / 3
	Total	11 / 12 Passed

Description

85%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is concrete, action-oriented, and pairs an explicit trigger clause with a clearly defined what, giving it strong specificity and completeness. Its only weakness is thin trigger-term variation coverage.

Suggestions

Broaden trigger terms to common variations users say, e.g. "create/open/submit a PR", "request a code review", or "turn a branch into a pull request".

Consider naming the review-round dimension more explicitly in the description so the CI-review orchestration trigger is unambiguous.

Dimension	Reasoning	Score
Specificity	"Open a draft pull request on GitHub and drive CI review rounds until it is ready" lists multiple concrete actions (create draft PR, drive CI review rounds, ready it), matching the score-3 anchor. It is not score 2 because it goes beyond naming a single domain plus some actions to enumerating several specific operations.	3 / 3
Completeness	It states what it does ("Open a draft pull request...drive CI review rounds until it is ready") and gives an explicit when ("MUST use when you want to create/open a PR"), matching the score-3 anchor for both. It is not 2 because the trigger is explicit rather than implied.	3 / 3
Trigger Term Quality	"MUST use when you want to create/open a PR" surfaces natural terms (create/open a PR, pull request) but covers only a narrow variation set, lacking common phrasings like "submit a PR" or "request review". It is not 3 because coverage is incomplete, and not 1 because the keywords present are ones users actually say.	2 / 3
Distinctiveness Conflict Risk	The niche is specific (GitHub draft PR creation plus CI review-round orchestration) with a distinct trigger unlikely to fire for unrelated skills. It is not 2 because the scope is narrow and clearly scoped to PR creation/review rather than overlapping with generic code skills.	3 / 3
	Total	11 / 12 Passed

Validation

87%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning
relative_links	Relative link issues: 1 missing	Warning

	Total	14 / 16 Passed

Repository: windmill-labs/windmill
Path: .agents/skills/pr/SKILL.md
Commit: 33d2845

Reviewed: 2 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.