CtrlK
BlogDocsLog inGet started
Tessl Logo

github-deep-review

GitHub deep review: bugs, PRs, best fix, stale-or-real, read code first.

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 ./skills/github-deep-review/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

82%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 lean, highly actionable instruction skill: exact gh/git commands with field lists, a concrete output template, and decision branches for PR and issue review. Its only real weaknesses are mild redundancy in the Provenance section and an implied (rather than explicit) end-to-end workflow order across sections.

DimensionReasoningScore

Conciseness

The body is dense and assumes Claude's competence — no concept explanations, no padding — and commands are given as bare blocks. However, the Provenance section restates the shallow/grafted-history point several times across overlapping sentences (e.g. the long boundary sentence and "A genuine root needs raw-header proof that it has no parents"), which is trimmable without losing guidance. This puts it at anchor 4 (efficient, minor over-explanation) rather than 5.

4 / 5

Actionability

Guidance is copy-paste ready throughout: exact `gh issue view`/`gh pr view` commands with full `--json` field lists, `gh pr diff`, concrete `git log -S/-G`, `git --no-replace-objects cat-file`, and `git diff --no-ext-diff` provenance commands, plus a fill-in output template. The common cases (issue review, PR review, diff inspection, provenance tracing) are each covered by an executable command, matching anchor 5.

5 / 5

Workflow Clarity

The skill is organized into a clear sequence (Start → Review Contract → Code Reading Depth → Provenance → Fix Quality Bar → PR/Issue Review Shape → Output Template), and Issue Review Shape gives numbered steps with decision branches and an explicit checkpoint ("Check whether current `main` already fixes it") plus failure handling ("If reproduction is not feasible, say exactly what blocks it"). It sits at anchor 4 rather than 5 because the overall cross-section flow is implied by section order rather than stated as one explicit sequenced workflow with validation checkpoints per stage.

4 / 5

Progressive Disclosure

No bundle files exist; all content lives in this single well-sectioned file, and the one external dependency (the author-context workflow at `~/Projects/agent-scripts/skills/github-author-context/SKILL.md`) is clearly signaled by absolute path with explicit when-to-use conditions. This matches anchor 4 (good structure, most content appropriately placed): the dense Provenance section is arguably material that could live in a separate reference file, which keeps it from anchor 5.

4 / 5

Total

17

/

20

Passed

Description

61%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 is concise and domain-distinct with several natural trigger terms, but it reads as a compressed keyword list rather than a capability statement, and it entirely lacks a "Use when" trigger clause. Adding an explicit trigger and expanding fragments into action phrases would move it into the top band.

Suggestions

Add an explicit trigger clause, e.g. "Use when reviewing a GitHub issue or PR, deciding if a bug report is stale or already fixed, or choosing the best fix for a reported bug."

Convert keyword fragments into concrete verb phrases so the "what" is unambiguous: "Reviews GitHub issues and pull requests, verifies whether reported bugs are stale or real, reads the code to find root causes, and recommends the best fix."

Include common synonyms as trigger terms: "issues", "pull requests", "triage", "regression" alongside the existing "bugs" and "PRs".

DimensionReasoningScore

Specificity

"GitHub deep review: bugs, PRs, best fix, stale-or-real, read code first" names the domain plus several review activities, but they are terse keyword fragments rather than concrete action phrases (no verbs like "review", "triage", "identify root cause" with objects). It matches anchor 3 (domain plus 1-2 concrete actions, not comprehensive) better than 4 because the actions are compressed to nouns and are not enumerated as capabilities.

3 / 5

Completeness

The "what" is present but compressed (deep review of bugs, PRs, best fix, stale-or-real); there is no "Use when..." clause or equivalent explicit trigger guidance, which caps completeness at 3 per the rubric. "read code first" is an instruction, not a trigger condition, so it does not qualify as even a weak "when".

3 / 5

Trigger Term Quality

Contains good natural keywords users would say: "GitHub", "bugs", "PRs", "best fix", "review". A few common terms are missing ("issues", "pull requests", "triage", "regression"), and "stale-or-real" is idiosyncratic jargon rather than a phrase a user would naturally type, keeping it below anchor 5.

4 / 5

Distinctiveness Conflict Risk

"GitHub deep review" combined with "bugs, PRs, best fix, stale-or-real" carves a fairly distinct review/triage niche. Minor overlap risk remains with generic code-review or PR-review skills, which keeps it at anchor 4 rather than 5.

4 / 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
steipete/agent-scripts
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.