CtrlK
BlogDocsLog inGet started
Tessl Logo

positron-qa-verify

Generates clear, actionable verification guides for QA testing of Positron bug fixes and features

61

Quality

71%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/positron-qa-verify/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

86%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 body is a strong, executable workflow: exact commands, explicit sequencing with parallel and conditional steps, and clean one-level-deep references to real bundle files. Its only weaknesses are minor — slight redundancy around the script documentation and no explicit error-recovery checkpoints for failed gh fetches.

DimensionReasoningScore

Conciseness

The body is tight and assumes competence — exact gh commands with flags, a conditional diff rule, and no concept explanations — but a few spots could be trimmed, e.g. the sample JSON output block for detect_versions.sh and 'Never prompts or shows errors - returns empty values on failure' repeating 'Fast, silent version detection'. Not score 5 due to these minor redundant tokens; well above score 3 since there is no padding or over-explanation.

4 / 5

Actionability

Every step is copy-paste executable: exact gh commands ('gh issue view <number> --repo posit-dev/positron --json title,body,comments,url,labels,author'), a concrete output path pattern, an explicit parallelization instruction, and a runnable script invocation with defined output schema. Minor details (guide format) are correctly delegated to a real reference file.

5 / 5

Workflow Clarity

The 7 steps are clearly sequenced with explicit parallelization (Steps 1-2), a conditional gate (Step 4: diff only for PRs < 500 lines), and a user-acceptance gate (Step 7), plus an explicit execution-mode contract (fail fast, non-interactive). Not score 5 because there are no explicit validation checkpoints on fetched data (e.g., what to do if the issue fetch fails mid-workflow beyond the global fail-fast rule), though the read-only nature of the workflow means the destructive/batch cap does not apply.

4 / 5

Progressive Disclosure

The SKILL.md is a lean overview with well-signaled, one-level-deep references that verifiably exist: 'See references/verification_guide.md for format and examples' and 'scripts/detect_versions.sh', both present in the bundle with substantial content. The bulk of the guide format and templates is appropriately split out, keeping the body navigable.

5 / 5

Total

18

/

20

Passed

Description

57%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 a specific, concrete capability in an appropriately niche domain, but it omits any 'when to use' trigger guidance and relies on domain nouns rather than natural user phrases. Adding an explicit 'Use when...' clause with scenarios users would voice (e.g., assigned a QA verification ticket, asked to verify a Positron fix) would lift both completeness and trigger quality.

Suggestions

Add an explicit trigger clause, e.g. 'Use when assigned a QA verification ticket for a Positron bug fix or feature, or when asked to verify, test, or write test scenarios for a merged PR.'

Include natural user phrasings as trigger terms ('verify this fix', 'test scenarios', 'QA a PR') rather than only domain nouns like 'QA testing' and 'verification guides'.

Optionally name the deliverable context (GitHub issues/PRs) in the description so the what-scoped capability is fully concrete.

DimensionReasoningScore

Specificity

The description names the domain ('QA testing of Positron bug fixes and features') and one concrete action ('Generates ... verification guides'), but 'clear, actionable' are adjectives rather than additional capabilities, leaving coverage short of the several-specific-actions bar. It is above a score-2 'names the domain but minimal actions' example because generating verification guides is a concrete, specific deliverable.

3 / 5

Completeness

The 'what' is clearly stated ('Generates clear, actionable verification guides for QA testing of Positron bug fixes and features') but the 'when' is entirely absent — there is no 'Use when...' clause or equivalent trigger guidance, which caps completeness at 3 per the judging guidelines. It is not score 2 because the 'what' half is concrete and specific, not vague.

3 / 5

Trigger Term Quality

Relevant keywords exist ('QA testing', 'verification guides', 'bug fixes', 'Positron') but common natural variations users would actually say ('verify this fix', 'test this PR', 'write test scenarios', 'QA a ticket') are missing. Not score 4 because coverage of natural trigger phrases — not just domain nouns — is thin.

3 / 5

Distinctiveness Conflict Risk

The description carves out a clear niche — Positron-specific QA verification guides — with distinct trigger terms ('Positron', 'bug fixes', 'QA testing') that are unlikely to collide with general document, code, or test-generation skills. No overlap risk apparent.

5 / 5

Total

14

/

20

Passed

Validation

100%

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
Reviewed

Table of Contents

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.