update-pr

Update the pull request for the current session. Use when the user wants to push new changes to an existing PR.

Quality

74%

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 ./src/vs/sessions/skills/update-pr/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 orchestration skill: a clearly sequenced, conditional five-step workflow that delegates to other skills and external context without any padding. Its weakness is actionability — the checking, pulling, and PR-update steps reference no concrete commands, leaving Claude to improvise the exact git/gh invocations.

Suggestions

Add the concrete commands for the opaque steps, e.g. incoming-commit detection ("gh pr view --json commits" or "git fetch <remote> <pr-branch> && git log HEAD.."), pulling incoming changes, and publishing ("git push" / "gh pr edit --title --body").

Name or define the "compile and hygiene tasks" — a bare reference to tasks that are never identified is the least actionable phrase in the body.

Add a lightweight verification checkpoint after conflict resolution and after the final push (e.g. confirm the PR branch head matches local HEAD before finishing).

Dimension	Reasoning	Score
Conciseness	The body is ~15 lean lines with zero padding: "The context block appended to the prompt contains the pull request information" states only what Claude could not guess, and no step explains concepts Claude already knows. Every token earns its place, matching the lean/efficient anchor at 5 rather than the minor-over-explanation anchor at 4.	5 / 5
Actionability	The five numbered steps are specific in intent and correctly delegate to the "/commit" skill, but key execution details are missing: no command for detecting or pulling incoming commits (e.g. "gh pr diff"/"git pull"), no command for "Update the pull request with the new commits and information" (e.g. "git push"/"gh pr edit"), and "the compile and hygiene tasks" are referenced without saying what they are. This matches the anchor for concrete-but-incomplete guidance with missing key details, not the 4 anchor's concrete commands with only minor gaps, and not the 2 anchor since the steps are actionable in sequence.	3 / 5
Workflow Clarity	A clear five-step ordered sequence with explicit conditionals ("If there are any incoming changes", "If there are any uncommitted changes", "If the outgoing changes introduce significant changes") and one checkpoint ("Run the compile and hygiene tasks (fixing any errors)"). There is no explicit verification that the incoming pull, conflict resolution, or final push succeeded, which is a minor validation gap matching the 4 anchor rather than the 5 anchor's explicit validate-fix-retry loops; not 3 because a real checkpoint and branching logic are present.	4 / 5
Progressive Disclosure	This is a single-purpose skill well under 50 lines with no bundle files (no references/, scripts/, or assets/ directories exist), and no external material is needed — the PR details are supplied by the harness context block, which the body correctly points to. Per the rubric's guidance for such skills, well-organized short content with no nested references scores 5.	5 / 5
	Total	17 / 20 Passed

Description

70%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 concise, third-person description that explicitly covers both what the skill does and when to use it, with natural trigger phrasing around pull requests and PRs. Its main limitation is breadth: it names a single coarse action instead of the specific update workflow steps the skill actually performs.

Suggestions

Expand the what-clause to enumerate the concrete sub-actions, e.g. "Pulls incoming commits, resolves conflicts, runs compile and hygiene checks, commits uncommitted changes, and updates an existing pull request's title, description, and commits for the current session."

Broaden the when-clause with one or two additional natural trigger phrasings, such as "Use when the user asks to update, sync, or push changes to an existing PR."

Keep the distinctiveness of "existing PR" wording — it is the main reason the description does not collide with PR-creation or review skills.

Dimension	Reasoning	Score
Specificity	"Update the pull request for the current session" names the domain (pull requests) and one concrete action, but does not enumerate the sub-actions the body actually covers (pulling incoming commits, resolving conflicts, updating title/description). It matches the anchor for 1-2 concrete actions without comprehensive coverage; not score 4 because it does not list several specific actions, and not score 2 because the action named is concrete rather than generic.	3 / 5
Completeness	Both parts are explicitly present: the "what" ("Update the pull request for the current session") and a "Use when" clause ("Use when the user wants to push new changes to an existing PR"). The when-clause is concrete, but it offers only a single trigger phrasing and the what-side summarizes rather than details capabilities, matching the anchor where both exist but could be more explicit/specific rather than the 5 anchor's fully comprehensive concrete trigger phrases.	4 / 5
Trigger Term Quality	"pull request", "PR", and the natural phrase "push new changes to an existing PR" give good keyword coverage with the abbreviation variant present. A few natural terms users might say are missing (e.g. "update the PR", "sync the PR"), so it falls just short of the comprehensive-synonyms anchor at 5 but above the 3 anchor which lacks common variations.	4 / 5
Distinctiveness Conflict Risk	Terms like "existing PR" and "push new changes to an existing PR" carve out a distinct niche clearly separated from generic git/commit skills. Minor overlap risk remains with closely related skills (e.g. a create-PR or push skill, or the built-in PR review skill), which keeps it at 4 rather than the minimal-conflict 5 anchor.	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: posit-dev/positron
Path: src/vs/sessions/skills/update-pr/SKILL.md
Commit: b0258bc

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.