prs

Expertise in managing the Git and GitHub Pull Request lifecycle, including staging changes, generating PR descriptions, and branch management.

Quality

72%

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 ./tools/gemini-cli-bot/.gemini/skills/prs/SKILL.md

Quality

Content

78%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 tight, well-structured instruction-only skill: concrete tools, filenames, and commands with two clearly sequenced workflows and a built-in recovery rule for accidentally staged files. It is near the top of the scale, missing only a final verification checkpoint and an explicit title-format example.

Dimension	Reasoning	Score
Conciseness	The body is lean and assumes Claude's competence — no explanation of what git or PRs are; every line is instruction. Not a 5 because of mild padding: the emphatic repetitions ("You are STRICTLY FORBIDDEN", "MANDATORY", "CRITICAL" used twice) could be tightened without losing force.	4 / 5
Actionability	Guidance is concrete throughout: named tools (`write_file`, `git add <files>`, `git reset <file>`, `gh run view`), exact artifact filenames (`pr-description.md`, `branch-name.txt`, `pr-number.txt`, `issue-comment.md`, `pr-comment.md`), and a concrete branch-name example (`bot/task-BT-01`). Not a 5 only because a one-line example of a conventional PR title would cover the most common case explicitly.	4 / 5
Workflow Clarity	Two clearly sequenced numbered workflows (staging/patch prep and unblocking/PR updates) with an explicit recovery checkpoint ("If they are accidentally staged, you MUST unstage them using `git reset <file>`") and a CI-failure diagnosis path. Not a 5 because there is no final verification step (e.g. confirming staged state with `git status`) before finishing.	4 / 5
Progressive Disclosure	The body is ~47 lines with no bundle files and no need for external references; it is organized into a Goal section and two well-labeled scenario sections ("Staging & Patch Preparation (MANDATORY)" and "Unblocking & PR Updates (Recovery)"), which per the rubric's simple-skill guidance earns a 5 on well-organized sections alone.	5 / 5
	Total	17 / 20 Passed

Description

66%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 solid description that names a clear domain and several concrete actions, but it is missing any 'when to use' trigger guidance, which caps completeness and weakens its ability to fire reliably. Adding a 'Use when...' clause with common user phrasings (PR, pull request, staging, CI failure) would lift it substantially.

Suggestions

Add an explicit trigger clause, e.g. 'Use when the user asks to create or update a pull request, stage or unstage changes, respond to PR review comments, or fix failing CI checks on a bot PR.'

Include common synonyms and shorthand in the description — 'PR' alongside 'Pull Request', plus terms like 'commit', 'code review', and the generated artifact filenames (pr-description.md) so it matches natural user phrasing.

Broaden action coverage to match the body: mention responding to maintainer feedback, unblocking existing PRs (branch-name.txt / pr-number.txt tracking), and diagnosing CI failures with 'gh run view'.

Dimension	Reasoning	Score
Specificity	The description lists several concrete actions — "staging changes, generating PR descriptions, and branch management" — in a clearly named domain ("Git and GitHub Pull Request lifecycle"). It is not a 5 because coverage has gaps: "branch management" is generic and body capabilities like responding to PR comments, unblocking existing PRs, and CI failure diagnosis are absent.	4 / 5
Completeness	The "what" is clear (manage the Git/GitHub PR lifecycle: staging, PR descriptions, branch management), but there is no "when" clause at all — no "Use when..." or equivalent trigger guidance, which caps this dimension at 3 per the judging guidelines.	3 / 5
Trigger Term Quality	Natural terms users would say are present: "Git", "GitHub", "Pull Request", "staging changes", "branch management". Not a 5 because common variations and synonyms are missing — notably the abbreviation "PR", "commit", "code review", and file extensions like ".md" for the generated artifacts.	4 / 5
Distinctiveness Conflict Risk	The Git/GitHub PR lifecycle niche is mostly distinct with clear trigger terms like "Pull Request" and "staging". Not a 5 because of minor overlap risk with closely related skills such as commit-message generation or general git-operations skills, and the absence of a trigger clause weakens disambiguation.	4 / 5
	Total	15 / 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: google-gemini/gemini-cli
Path: tools/gemini-cli-bot/.gemini/skills/prs/SKILL.md
Commit: 361b0bb

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