CtrlK
BlogDocsLog inGet started
Tessl Logo

identify-security-vuln-discussion

Screen GitHub issues and comments for inadvertent security vulnerability disclosure. Use when: (1) A new issue is created, (2) An issue body is edited, (3) A comment is added or edited, (4) Part of issue intake pipeline. Prevents bypass by editing clean issues to add vulnerabilities later. If a vulnerability is detected in title/body, closes the issue and tags @netwrix/security. If detected in a comment, deletes the comment and posts a security notice.

89

2.00x
Quality

Does it follow best practices?

Impact

96%

2.00x

Average score across 3 eval scenarios

SecuritybySnyk

Advisory

Suggest reviewing before use

SKILL.md
Quality
Evals
Security

Quality

Content

72%

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

The body is highly actionable with concrete, executable gh commands and clear SAFE/Title-Body/Comment branching, and it is well-organized as a single self-contained skill. Its weaknesses are minor redundancy of the bypass-prevention rationale across sections and the absence of verification checkpoints for the destructive close/delete actions.

Suggestions

Add verification steps after destructive actions — e.g., confirm the issue is closed with 'gh issue view $1 --repo $0 --json state' and confirm comment deletion succeeded — to introduce a validation feedback loop.

Remove the repeated bypass-prevention rationale: state it once (e.g., in Process or Principles) and reference it rather than restating it in Task, Notes, and Workflow Configuration.

Consolidate the 'check all comments' guidance so it appears once in Process rather than being repeated across Principles and Notes.

DimensionReasoningScore

Conciseness

The body is mostly efficient with concrete commands and no 'what is a vulnerability' filler, but the bypass-prevention rationale is repeated three times (Task, Notes, Workflow Configuration) and Notes reiterates 'Check ALL comments every time' already covered in Process/Principles. This matches the level-2 anchor of mostly efficient but could be tightened, rather than the level-3 'every token earns its place'.

2 / 3

Actionability

Provides fully executable, copy-paste-ready commands — 'gh issue view $1 --repo $0 --comments --json comments', 'gh issue comment', 'gh issue close $1 --repo $0 --reason "not planned"', and 'gh api --method DELETE repos/$0/issues/comments/{comment-id}' — with verbatim comment text. This matches the level-3 anchor of fully executable code/commands, not the level-2 pseudocode anchor.

3 / 3

Workflow Clarity

Process is sequenced (steps 1-4) with explicit SAFE / Title-Body / Comment branching, but destructive operations (closing the issue, deleting a comment) have no validation or verification checkpoint confirming the action succeeded. Per the judging guidelines, missing validation in destructive operations caps workflow clarity at 2 rather than the level-3 explicit-checkpoint anchor.

2 / 3

Progressive Disclosure

No bundle files exist and the skill is a single self-contained SKILL.md organized into clearly labeled sections (Input Variables, Process, Security Indicators, Actions, Principles, Notes, Workflow Configuration). Per the scoring notes, a skill under 50 lines with no external references and well-organized sections can score 3, and this organization supports easy navigation.

3 / 3

Total

10

/

12

Passed

Description

100%

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 specific, complete, and distinctive: it states concrete protective actions and gives an explicit four-item 'Use when' trigger clause covering issue creation, edits, and comments. It is well-scoped to a clear niche and unlikely to conflict with other skills.

DimensionReasoningScore

Specificity

Lists multiple concrete actions: 'Screen GitHub issues and comments', 'closes the issue and tags @netwrix/security', 'deletes the comment and posts a security notice'. This matches the level-3 anchor of listing multiple specific concrete actions, and exceeds level 2 which only names a domain and some actions.

3 / 3

Completeness

Explicitly answers both 'what' (screen for disclosure, close/delete and tag) and 'when' via a numbered 'Use when:' clause with four triggers. This matches the level-3 anchor with explicit triggers for both what and when; level 2 would have 'when' missing or only implied.

3 / 3

Trigger Term Quality

Uses natural user-facing terms such as 'GitHub issues and comments', 'security vulnerability disclosure', 'new issue is created', 'issue body is edited', and 'comment is added or edited', giving good coverage of phrases a user would naturally say. Not level 2 because the trigger phrasing is comprehensive rather than just 'some relevant keywords'.

3 / 3

Distinctiveness Conflict Risk

The niche is sharply defined — screening GitHub issues/comments for inadvertent security disclosure — with distinct triggers unlikely to fire for unrelated skills. This matches the level-3 'clear niche with distinct triggers' anchor rather than the somewhat-overlapping level 2.

3 / 3

Total

12

/

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

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
netwrix/docs
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.