CtrlK
BlogDocsLog inGet started
Tessl Logo

github-issues

GitHub issue comment guidelines for community interaction. Use when: "respond to this issue", "reply to this bug report", "close this issue", or any GitHub discussion.

71

Quality

87%

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

SKILL.md
Quality
Evals
Security

Quality

Content

85%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, highly actionable commenting style guide with concrete phrase banks, exact links, and full example responses organized under clear headers. Its main weakness is mild redundancy across the compression rule, fixed-issues, and core-elements sections that could be tightened.

Suggestions

Consolidate the overlapping sequence guidance: merge the "Comment Compression Rule" shape and the "Fixed Issues" order into one canonical comment structure, then reference it from the examples instead of restating it.

De-duplicate greeting guidance by keeping opening patterns only in "Opening Pattern" and having "Core Elements > Acknowledgment" point to it rather than repeating greetings.

Trim the "Good" fixed-issues example or fold it into the canonical structure so the same closing pattern is not demonstrated twice.

DimensionReasoningScore

Conciseness

The body is a focused phrase bank with no filler explaining concepts Claude already knows, so it is above level 1. But it is not level 3 because the same guidance recurs across sections: the "Comment Compression Rule" shape (acknowledge, state, next action, close) is restated in "Fixed Issues" (thank, state, version, close), and greetings appear in both "Opening Pattern" and "Core Elements > Acknowledgment". Not every token earns its place.

2 / 3

Actionability

Highly actionable for an instruction-only skill: exact wording banks, concrete URLs (https://cal.com/epicenter/whispering, https://go.epicenter.so/discord), and several full copy-paste example responses (Feature Implementation, Debugging, Quick Acknowledgment, PR Discussion). This is concrete, specific, copy-paste-ready guidance, not vague or pseudocode.

3 / 3

Workflow Clarity

The comment-construction process is given as an explicit numbered sequence ("Most comments need this shape: 1. Human acknowledgment. 2. Current state... 4. Warm closing" and the Fixed Issues order). For a single-purpose, non-destructive writing task no validation/feedback checkpoint is warranted, and the judging guideline allows simple unambiguous single-action skills to score 3.

3 / 3

Progressive Disclosure

Well-organized with clearly headed sections (Anti-Patterns, Maintainer Respect Gate, Core Elements, Response Examples, Writing Style Notes) and a single clearly-signaled, one-level-deep reference to the sibling writing-voice skill (../writing-voice/SKILL.md). No bundle files are present and none are needed; keeping the phrase banks inline is appropriate for a self-contained style guide, so it is not penalized as a monolithic wall of text.

3 / 3

Total

11

/

12

Passed

Description

90%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, third-person description with an explicit Use-when trigger list of natural phrasings and a clearly delineated GitHub-commenting niche. The only weakness is that it describes the capability as "guidelines" rather than enumerating concrete actions.

Suggestions

Replace the abstract "comment guidelines for community interaction" with a short enumeration of concrete actions (e.g. "Draft, acknowledge, triage, and close-out replies for GitHub issues and PRs") to raise specificity.

Consider adding "PR comments" or "pull request discussion" as an explicit natural trigger term alongside the issue-oriented ones for fuller coverage.

DimensionReasoningScore

Specificity

Names the domain ("GitHub issue comment guidelines for community interaction") but frames the capability as abstract "guidelines" rather than listing multiple concrete actions (e.g. acknowledge, triage, close, request repro). It is not a 1 because it identifies a concrete action domain (commenting on issues); it is not a 3 because no enumeration of specific concrete actions is given.

2 / 3

Completeness

It explicitly answers both what ("GitHub issue comment guidelines for community interaction") and when ("Use when: ... or any GitHub discussion") with explicit triggers. Clear what-and-when, so it exceeds the level-2 anchor that lacks explicit when guidance.

3 / 3

Trigger Term Quality

The "Use when" clause supplies natural phrasings a user would actually say: "respond to this issue", "reply to this bug report", "close this issue", plus "any GitHub discussion" for PR coverage. Good coverage of natural terms rather than just a few relevant keywords, so it is not a 2.

3 / 3

Distinctiveness Conflict Risk

A clear niche (GitHub issue/PR commenting) with distinctive triggers ("respond to this issue", "close this issue") that are unlikely to fire for unrelated skills. It is not a 2 because the domain and triggers are specific enough to avoid meaningful overlap.

3 / 3

Total

11

/

12

Passed

Validation

93%

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

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 2 missing, 1 suspicious

Warning

Total

15

/

16

Passed

Repository
EpicenterHQ/epicenter
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.