CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

build-from-issue

Plan and implement work described in a GitHub issue, including verification, documentation, and a PR that closes the issue.

Quality

76%

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 ./.agents/skills/build-from-issue/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 an exemplary lean, instruction-only skill: a clear three-phase workflow with concrete commands, explicit stop conditions, and well-signaled one-level-deep references. The only meaningful gap is that verification and error-recovery specifics live in external documents rather than inline, which slightly limits standalone actionability.

DimensionReasoningScore

Conciseness

The ~28-line body is lean and dense: every sentence is operative instruction or policy, with no explanation of concepts Claude already knows and no padded sections. It consistently assumes the model's competence.

5 / 5

Actionability

Provides a copy-paste-ready command ('gh issue view <id> --json number,title,body,state,labels,comments,assignees'), exact comment markers ('> **🏗️ build-plan**'), 'Closes #<id>' convention, and signed-off Conventional Commit guidance. Not 5 because several steps defer concrete specifics to external docs (CONTRIBUTING.md sections, sibling skills) rather than stating them inline.

4 / 5

Workflow Clarity

Clear Inspect → Plan → Implement sequence with explicit checkpoints and stop conditions ('ask the operator before proceeding', 'If blocked, preserve local work and report the reason', 'stop after the plan is available for review'). Below 5 because error-recovery loops when verification or checks fail are deferred to CONTRIBUTING.md rather than stated inline.

4 / 5

Progressive Disclosure

Under 50 lines with well-organized sections and no bundle files to split; external references (CONTRIBUTING.md sections, sibling skills, CRYPTO.md) are clearly signaled by name and only one level deep. Meets the simple-skill exception for a full score.

5 / 5

Total

18

/

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 communicates a concrete, well-scoped workflow with several specific actions, but entirely lacks a 'when to use' trigger clause, which both caps completeness and limits natural trigger-term coverage. Adding an explicit 'Use when...' sentence with user-natural phrasing would lift the two weakest dimensions.

Suggestions

Add an explicit trigger clause, e.g., 'Use when the user asks to implement, build, or fix work described in a specific GitHub issue, or wants an issue turned into a PR.'

Include natural synonyms and variations users actually say — 'GitHub issue', 'ticket', 'feature request', 'close the issue' — to broaden trigger-term coverage beyond the current two core terms.

Briefly scope the 'what' (e.g., code changes, tests, and docs driven by the issue's acceptance criteria) so 'work' is less generic and the skill is harder to mistake for general coding assistance.

DimensionReasoningScore

Specificity

Lists several concrete actions — 'Plan and implement work described in a GitHub issue', 'verification, documentation, and a PR that closes the issue' — covering the full workflow. Not 5 because 'work' is left unspecified with no hint of change scope or planning artifacts.

4 / 5

Completeness

The 'what' is clear (plan, implement, verify, document, open a closing PR), but there is no 'Use when...' clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines.

3 / 5

Trigger Term Quality

Contains relevant natural keywords ('GitHub issue', 'PR', 'implement', 'plan') a user would plausibly say, but misses common variations and synonyms such as 'ticket', 'feature request', or 'close the issue'. Anchor 3 (some relevant keywords, missing variations) is the closest fit.

3 / 5

Distinctiveness Conflict Risk

Occupies a clear niche — issue-driven implementation through a closing PR — that is mostly distinct from generic coding skills. Minor overlap risk with closely related PR-creation skills (e.g., the referenced 'create-github-pr'), keeping it below 5.

4 / 5

Total

14

/

20

Passed

Validation

81%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 13 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

metadata_field

'metadata' should map string keys to string values

Warning

relative_links

Relative link issues: 1 suspicious

Warning

Total

13

/

16

Passed

Repository

NVIDIA/OpenShell

Path

.agents/skills/build-from-issue/SKILL.md

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.