Use when you need to address review or issue comments on an open GitHub Pull Request using the gh CLI.
57
66%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/antigravity-address-github-comments/SKILL.mdQuality
Discovery
89%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 well-structured with a clear 'Use when' clause and good trigger terms that make it easy for Claude to identify when this skill applies. Its main weakness is a lack of specificity about what concrete actions it performs beyond the general 'address review or issue comments' — listing specific actions like replying, resolving, or updating code would strengthen it.
Suggestions
Add specific concrete actions such as 'reply to review comments, resolve conversations, update code based on feedback, dismiss reviews' to improve specificity.
Consider adding common user phrasing variations like 'PR feedback', 'code review', 'reviewer comments' to further strengthen trigger term coverage.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (GitHub Pull Request comments) and a general action (address review or issue comments), but doesn't list specific concrete actions like replying to comments, resolving conversations, requesting changes, or updating code based on feedback. | 2 / 3 |
Completeness | The description explicitly answers both 'what' (address review or issue comments on an open GitHub Pull Request using gh CLI) and 'when' (starts with 'Use when'), providing clear trigger guidance for Claude's skill selection. | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms: 'review comments', 'issue comments', 'GitHub Pull Request', 'PR', 'gh CLI'. These are terms users would naturally use when asking for help with PR review feedback. | 3 / 3 |
Distinctiveness Conflict Risk | The description is narrowly scoped to addressing comments on open GitHub PRs via gh CLI, which is a distinct niche unlikely to conflict with general GitHub skills, code review skills, or other PR-related skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a reasonable high-level framework for addressing PR comments but falls short on actionability — the core steps (categorize, apply fixes, respond) are described abstractly rather than with concrete commands or code patterns. The boilerplate 'When to Use' and 'Limitations' sections waste tokens without adding value. The workflow would benefit significantly from executable examples and validation checkpoints.
Suggestions
Replace the vague 'Apply Fixes' step with concrete guidance — e.g., how to extract file paths and line numbers from review comments using `gh api` or `gh pr diff`, and how to make targeted edits.
Add a validation checkpoint after applying fixes (e.g., run tests, lint, or at minimum `git diff` review) before responding to comment threads.
Provide a concrete example of using `gh api` to fetch and respond to individual review threads (not just general PR comments), since `gh pr comment` only posts top-level comments.
Remove the generic 'When to Use' and 'Limitations' sections — they add no actionable information and waste tokens.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes some unnecessary sections like 'When to Use' (which just restates the overview) and 'Limitations' (generic boilerplate that doesn't add value). The 'Common Mistakes' section is somewhat useful but partially obvious. The core workflow could be tighter. | 2 / 3 |
Actionability | Steps 2 and 3 are vague and abstract — 'Categorize and Plan', 'Apply Fixes' provide no concrete commands or code. The only executable commands are `gh pr view --comments` and `gh pr comment`, which are basic. There's no guidance on how to actually parse comment threads, resolve them via API, or handle review-specific comments vs general PR comments. | 1 / 3 |
Workflow Clarity | Steps are listed in a reasonable sequence, but there are no validation checkpoints (e.g., verifying fixes compile/pass tests before responding), and steps 2-3 are too vague to be actionable. There's no feedback loop for verifying that comments were actually resolved or that the commit addresses the feedback correctly. | 2 / 3 |
Progressive Disclosure | The skill is relatively short and self-contained with no bundle files. The sections are well-organized with clear headers. For a skill of this size with no external references needed, the structure is appropriate. | 3 / 3 |
Total | 8 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
95574f3
Table of Contents
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.