pr-test-checker

Grade whether a Positron PR has adequate test coverage. Evaluates new tests in the PR, checks existing coverage for changed source, and suggests concrete additions when coverage is insufficient. Used by the pr-test-checker GitHub Action.

Quality

71%

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 ./.claude/skills/pr-test-checker/SKILL.md

Quality

Content

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

The skill body is highly actionable, tightly sequenced with validation checkpoints, and token-efficient for its density. Its main weakness is progressive disclosure: substantial inline reference material and three unused bundle scripts that are not surfaced from the body.

Suggestions

Move the Windows/web hotspot lists into a reference file (e.g. references/surface-hotspots.md) and link to it from the Deployment coverage section to lighten the inline body.

Reference the existing bundle scripts (scripts/context-core.mjs, gather-local-context.mjs, gather-pr-context.mjs) from the body, or explain their role, so the provided bundle is discoverable rather than orphaned.

Dimension	Reasoning	Score
Conciseness	The body is dense and mostly high-signal (taxonomy tables, decision rules, concrete file-path patterns) with little padding or explanation of concepts Claude already knows; a few sections restate the same e2e principle multiple times and could be trimmed.	4 / 5
Actionability	Fully executable guidance throughout: concrete grep patterns ('grep -r "@:posit-assistant" test/e2e/tests/'), exact sibling-file conventions ('src/.../<dir>/test/<base>.vitest.ts(x)'), specific tag lists, and a copy-paste-ready markdown output template with literal emoji and section headings.	5 / 5
Workflow Clarity	The 'Investigation steps' are a clearly numbered sequence with explicit validation checkpoints (read candidate tests to confirm they exercise the changed behavior, cap of ~10-15 tool calls with a fallback verdict), plus an explicit error-recovery loop ('If you can't determine coverage... lean toward Insufficient').	5 / 5
Progressive Disclosure	Structure is good with clear section headers, but large bodies of detail (the Windows/web hotspot lists, the full output template, the tag-mapping logic) live inline in SKILL.md while the provided bundle scripts (context-core.mjs, gather-local-context.mjs, gather-pr-context.mjs) are never referenced or linked from the body, so navigation to detail is only partially signaled.	3 / 5
	Total	17 / 20 Passed

Description

58%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 states concrete capabilities clearly and is reasonably distinct, but it omits any explicit 'when to use' trigger guidance and leans on project jargon rather than natural user phrasing. Adding a 'Use when...' clause with user-facing trigger terms would lift completeness and trigger-term quality.

Suggestions

Add an explicit 'Use when...' clause, e.g. 'Use when reviewing a Positron PR for test coverage, or when the user asks whether a PR adds adequate tests.'

Surface natural trigger phrases users actually say ('does this PR have tests', 'add tests for this change', 'check test coverage') rather than relying on 'Positron PR' jargon alone.

Dimension	Reasoning	Score
Specificity	Lists several concrete actions ('Evaluates new tests in the PR, checks existing coverage for changed source, and suggests concrete additions when coverage is insufficient') rather than vague verbs, though 'grade' is slightly generic and the audience is Positron-specific.	4 / 5
Completeness	The 'what' is clearly stated (grade test coverage, check existing coverage, suggest additions), but there is no explicit 'Use when...' clause or trigger guidance telling Claude when to invoke it, which caps completeness at 3 per the rubric.	3 / 5
Trigger Term Quality	Relevant keywords are present ('PR', 'test coverage', 'tests') but the natural phrases a user would say ('test coverage', 'add tests', 'does this PR have tests') are only weakly covered and 'Positron PR' jargon narrows discoverability.	3 / 5
Distinctiveness Conflict Risk	The Positron-specific test-coverage niche with a named GitHub Action ('Used by the pr-test-checker GitHub Action') is mostly distinct from generic skills, with only minor overlap risk against general code-review skills.	4 / 5
	Total	14 / 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: .claude/skills/pr-test-checker/SKILL.md
Commit: 061594d

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