pr

Open a pull request for the current feature

Quality

68%

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

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/pr/SKILL.md

Quality

Content

82%Weight 40%Scale 1-5

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

A lean, highly actionable instruction skill: nearly every line is a concrete project-specific command or policy, with a clearly sequenced workflow and explicit validation checkpoints. Weaknesses are minor — some redundancy around PR-body handling, no explicit recovery loop for failed checks, and a dense preview-linking section that could be factored out.

Dimension	Reasoning	Score
Conciseness	The body is dense, imperative, and teaches only project-specific facts Claude cannot know (Oxfmt usage, Vercel preview-link policy, PR-body file handling) with no concept re-explanation. Minor redundancy — "never pass the replacement body inline" and "do not pass the PR body inline through a shell command" both appear, and the Vercel paragraph is convoluted — keeps it below a 5.	4 / 5
Actionability	Fully executable, copy-paste-ready commands throughout: "bunx oxfmt <changed-file-or-package-directory>... --write", "bun run build", "bun run stylecheck", "git push -u origin HEAD", and "gh pr create --title \"<title>\" --body-file <path-to-temp-md-file>" with a worked example. Specific commands cover the common cases, including edge handling (skip Oxfmt for unsupported files, vercel inspect fallback).	5 / 5
Workflow Clarity	The sequence is clear and ordered (branch check → existing-PR check → test policy → formatting → build/stylecheck → commit → push → create → preview links) with explicit validation checkpoints ("Inspect any formatter changes before committing", "to ensure we compile and CI linting/formatting passes", report when the preview URL cannot be resolved). It falls short of a 5 because no fix-and-retry loop is specified for failed builds or style checks — recovery is only implied.	4 / 5
Progressive Disclosure	Good structure for a single-file skill: the main flow is linear and the preview-linking workflow is separated under "## Link directly changed website pages", with both file references (the Element contribution guide and the pr-name skill) clearly signaled and only one level deep. Not a 5 because the dense Vercel preview procedure (~10 lines of conditional policy) would sit more appropriately in a separate reference file, and the body has no section headers for the main flow.	4 / 5
	Total	17 / 20 Passed

Description

53%Weight 40%Scale 1-5

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 concise and accurate but undersells the skill and completely lacks a trigger ('Use when...') clause. A user asking to 'submit a PR' or 'update my pull request' may not reliably surface it. It is functional but below the quality bar of the reference good examples.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user asks to open, submit, or update a pull request for the current branch or feature."

Mention the additional concrete capabilities the skill covers: checking for and updating an existing PR for the branch, running build/stylecheck, and adding preview links to the PR body.

Include common phrasing variations such as 'PR' and 'submit a pull request' to improve trigger term coverage.

Dimension	Reasoning	Score
Specificity	"Open a pull request" names the domain and one concrete action, but the description omits the skill's other capabilities (updating existing PRs, running checks, adding preview links). It matches 'names domain and 1-2 concrete actions, but not comprehensive' — above a generic 'handles PRs' (2) but well short of the multi-action coverage of a 5.	3 / 5
Completeness	The 'what' is clear ("Open a pull request for the current feature") but there is no 'Use when...' or equivalent trigger guidance, which the guidelines explicitly cap at 3. Not a 4 because the 'when' is entirely absent rather than merely weakly implied.	3 / 5
Trigger Term Quality	"pull request" is a natural term users say, but the description misses common variations like "PR", "submit a PR", or "open a PR for my branch". This fits 'some relevant keywords but missing common variations or synonyms'.	3 / 5
Distinctiveness Conflict Risk	The description carves a fairly distinct niche (opening PRs for the current feature) with minimal conflict risk against unrelated skills; only minor overlap with adjacent git/commit-workflow skills (e.g., the referenced pr-name skill). Not a 5 because 'open a pull request' could overlap with general git-workflow skills and the thin description offers few distinguishing details.	4 / 5
	Total	13 / 20 Passed

Validation

93%

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 — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
relative_links	Relative link issues: 2 suspicious	Warning

	Total	15 / 16 Passed

Repository: remotion-dev/remotion
Path: .agents/skills/pr/SKILL.md
Commit: 6f4e0d5

Reviewed: 5 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.