gh-pull-request

Verify, commit, and push changes on a PR branch. Runs pre-flight checks (compile, checkstyle, license headers) before every push. Also creates the PR if one doesn't exist yet.

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/gh-pull-request/SKILL.md

Quality

Content

88%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 highly actionable, well-sequenced workflow with strong validation and feedback loops around destructive operations, including genuinely non-obvious project knowledge. Its only weaknesses are mild redundancy in the post-merge section and a body length that slightly exceeds ideal SKILL.md overview size.

Dimension	Reasoning	Score
Conciseness	The body is efficient — mostly commands plus genuinely project-specific knowledge Claude wouldn't know (squash-merge deletion semantics, the cryptic checkstyle 'Range [0, -1)' error). The squash-merge/'not fully merged' explanation is repeated in both the step-4 comment and the Notes, which could be trimmed to one location.	4 / 5
Actionability	Fully executable throughout: exact mvnw invocations, 'license-eye header check'/'fix', a concrete ripgrep parameter block, 'git push -u origin <branch-name>', and a copy-paste-ready 'gh pr create' with heredoc. Acceptable FQCN exceptions are enumerated with concrete examples.	5 / 5
Workflow Clarity	Clear sequence (pre-flight checks → commit/push → PR creation → post-merge cleanup) with explicit validation and feedback loops: fix-and-re-check for license headers, re-run checkstyle after FQCN fixes, and a mandatory 'confirm the change actually landed in master' step before the destructive force-delete ('Do NOT skip step 3').	5 / 5
Progressive Disclosure	No bundle files exist, and the single body is well-sectioned with clear headers; references to external project files (.github/PULL_REQUEST_TEMPLATE, CHANGES log) are real and clearly signaled. At ~180 lines, content like the full PR template excerpts could arguably live in a reference file, keeping this a minor organization gap rather than a flaw.	4 / 5
	Total	18 / 20 Passed

Description

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

A specific, action-rich description in proper third-person voice, but it omits any explicit 'when to use' trigger guidance, which both caps completeness and leaves invocation conditions to inference. Adding a 'Use when...' clause with natural trigger phrases would make it fully self-describing.

Suggestions

Append an explicit trigger clause, e.g. 'Use when the user asks to commit, push, or create a pull request on a feature branch in this repository.'

Include natural synonyms users would say — 'pull request' spelled out and 'GitHub' — so the description matches phrasing beyond just 'PR'.

Consider mentioning the post-merge cleanup (branch sync and delete) so the description's coverage matches the body's full scope.

Dimension	Reasoning	Score
Specificity	The description lists multiple specific concrete actions — 'Verify, commit, and push changes on a PR branch', 'Runs pre-flight checks (compile, checkstyle, license headers) before every push', 'creates the PR if one doesn't exist yet' — in third-person voice, comprehensively covering the skill's domain.	5 / 5
Completeness	The 'what' is explicit and concrete, but there is no 'Use when...' clause or equivalent trigger guidance — 'before every push' describes behavior, not when to invoke the skill. Per the rubric, a missing explicit 'when' caps completeness at 3.	3 / 5
Trigger Term Quality	Good natural keyword coverage: 'commit', 'push', 'PR branch', 'checkstyle', 'pre-flight checks' are phrases users would actually say. A few natural terms are missing, such as 'pull request' spelled out and 'GitHub'.	4 / 5
Distinctiveness Conflict Risk	The PR-branch workflow framing plus project-specific checks (checkstyle, license headers) gives it a clear niche, but it could still overlap with generic git commit/push skills a user might invoke instead.	4 / 5
	Total	16 / 20 Passed

Validation

100%

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

Validation for skill structure

No warnings or errors.

Repository: apache/skywalking
Path: .claude/skills/gh-pull-request/SKILL.md
Commit: 0a01d89

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.