CtrlK
BlogDocsLog inGet started
Tessl Logo

create-fix-pr

Investigates a root cause and files a minimal fix PR for a reported bug or observability finding.

51

Quality

55%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/observability/create-fix-pr/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%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 concise, well-sequenced workflow with concrete gh commands and useful judgment checkpoints, but it defers critical execution detail (git identity, branch naming, PR body) to a non-existent pr-conventions.md and lacks a fix-verification step before filing.

Suggestions

Either ship references/pr-conventions.md with the branch-naming, git-identity, and PR-body rules, or inline those rules so the skill is self-contained.

Add an explicit verification step before filing (e.g. run the repo's tests / reproduce the fix locally) so the workflow clears the validation checkpoint required for outward-facing operations.

Keep the lean prose but cut lines that restate the overview (e.g. 'do the investigation properly first, don't jump to a fix without evidence') to push conciseness toward 5.

DimensionReasoningScore

Conciseness

The body is lean, assumes Claude's competence, and avoids explaining concepts Claude already knows; only minor phrases like 'do the investigation properly first, don't jump to a fix without evidence' could be trimmed. Not a 5 because a few sentences are mildly redundant with the overview; not a 3 because there is no real padding or over-explanation.

4 / 5

Actionability

Concrete commands are present ('gh pr list --search "<keywords>" --state open', 'gh repo clone <owner>/<repo>'), but the commit/push/PR-body and git-identity steps defer to 'pr-conventions.md', which is not present in the bundle, leaving key execution details missing. Not a 4 because core execution detail is offloaded to an absent file; not a 2 because two real executable commands are given.

3 / 5

Workflow Clarity

An 8-step sequence is clearly listed with some checkpoints (existing-PR search, PR-right-tool judgment, 'gh auth status' check), but there is no validation step confirming the fix actually works before filing an outward-facing PR, which per the rubric caps workflow clarity at 3. Not a 4 because the verification loop is absent; not a 2 because the sequence is coherent and several checkpoints exist.

3 / 5

Progressive Disclosure

Sections are well organized (Overview, Workflow, What's a good fix, Restricted tools) and references are signaled, but 'pr-conventions.md' is referenced as a bundle file and does not exist in references/scripts/assets. Not a 4 because a referenced detail file is missing; not a 2 because structure is reasonable and references are clearly signaled rather than buried.

3 / 5

Total

13

/

20

Passed

Description

53%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 clear, third-person 'what' with a distinct niche, but omits any explicit 'when to use it' trigger guidance and lacks keyword synonyms, capping completeness and trigger quality at the midpoint.

Suggestions

Add an explicit 'Use when...' clause naming concrete triggers, e.g. 'Use when the user reports a bug or observability finding and wants a minimal fix PR filed.'

Broaden trigger-term coverage with synonyms users actually say ('file a PR', 'open a pull request', 'hotfix', 'patch a bug', 'remediate an alert').

Optionally enumerate one or two more concrete actions (e.g. 'confirms no duplicate PR exists', 'pushes a minimal diff') to lift specificity above 3.

DimensionReasoningScore

Specificity

Names the domain ('fix PR for a reported bug or observability finding') and 1-2 concrete actions ('Investigates a root cause', 'files a minimal fix PR'), but coverage is not comprehensive. Not a 4 because no additional specific actions are enumerated; not a 2 because two real actions are named rather than minimal/generic.

3 / 5

Completeness

The 'what' is clear (investigate root cause, file minimal fix PR) but there is no 'Use when...' or equivalent trigger guidance, which per the rubric caps completeness at 3. Not a 4 because 'when' is only weakly implied; not a 2 because the 'what' is explicit rather than vague.

3 / 5

Trigger Term Quality

Relevant natural terms appear ('fix PR', 'reported bug', 'observability finding', 'root cause'), but common variations/synonyms are missing and there is no explicit trigger phrase. Not a 4 because keyword coverage is incomplete with no synonyms; not a 2 because the terms present are domain-relevant rather than purely generic.

3 / 5

Distinctiveness Conflict Risk

Targets a clear niche (minimal fix PR for a reported bug/observability finding) with only minor overlap risk against the closely related 'investigate' skill. Not a 5 because it explicitly builds on investigate and could overlap with general PR-creation skills; not a 3 because the trigger surface is reasonably specific.

4 / 5

Total

13

/

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
launchdarkly/ai-tooling
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.