CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

gator-gate

Validate and monitor OpenShell GitHub issues and PRs using the gator:* state machine. Use when asked to triage issues/PRs for project validity, gate PRs, run gator, validate submissions, or monitor PRs toward merge readiness.

Quality

78%

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 ./scripts/agents/gator/skills/gator-gate/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

62%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 exceptionally rigorous, executable operating procedure with a clear state machine and pervasive validation checkpoints — its workflow clarity is near-ideal. Its two real weaknesses are token weight (massive length with substantial rule repetition) and progressive disclosure (nearly everything, including 13 full comment templates, is inlined in SKILL.md rather than split into the bundle's reference files).

Suggestions

Move the 13 comment templates (~270 lines) into a references/comment-templates.md file and keep only the marker rule plus one canonical example inline, cutting SKILL.md by roughly a fifth.

Consolidate the one-disposition-per-head-SHA rule, which is stated at least four times across Comment Marker, Human Comment Disposition, Watch Loop Rules, and Step 8, into a single authoritative section that the other sections reference by name.

Split the durable review dispositions, reviewer-quality telemetry, and review-posting card rules out of Step 8 into a references/review-loop.md file, leaving Step 8 as a short decision sequence that points to it.

DimensionReasoningScore

Conciseness

At ~1330 lines the body is noticeably verbose, and its verbosity comes from repetition rather than concept explanation: the one-disposition-per-head-SHA rule is restated at least four times (Comment Marker, Human Comment Disposition, Watch Loop Rules, Step 8), transient-failure guidance is duplicated across Prerequisites and Step 8, and nudge TTL rules are repeated in Steps 8, 11, and 12. It does not pad with knowledge Claude already has (no score 1), so this sits at the "several padded sections" anchor rather than below it.

2 / 5

Actionability

Guidance is highly concrete and mostly executable: exact `gh api` REST calls (comment POST, label add/delete, batched PR review JSON with commit_id/comments/side), a `jq -e` ledger validation snippet, per-label search loops, and a fully worked inline review-comment example. The gap from 5 is that several invoked tools are not in the bundle or fully specified (`review-feedback-ledger`, `resolve-gator-review-threads`, `validate-review-findings`, the `gh` write wrapper's guard exits 21/22), leaving those steps executable only inside un-shown infrastructure.

4 / 5

Workflow Clarity

The state machine diagram plus Steps 1–12 give an explicit, coherent sequence, and validation checkpoints are everywhere despite destructive/batch GitHub writes: ledger schema validation before every reviewer run, fail-closed write-guard behavior, "verify every requested line appears in the current diff before submission", confirmation that required workflows are queued/running before leaving watch states, and transient-failure retry loops with next_poll_seconds. Error-recovery feedback loops (fix batch and retry, re-run validation, return transient_failure) are explicit.

5 / 5

Progressive Disclosure

Structure exists (clear section headers, a state-machine map, one real referenced file `references/review-findings-schema.md`), but large content that clearly belongs in separate files is inlined: ~270 lines of comment templates and long blocks of review-posting card rules and durable-disposition detail all live in SKILL.md itself, with only one small reference file used for a document of this size. It is above the no-structure anchor 2 but well short of a genuine overview-plus-references split.

3 / 5

Total

14

/

20

Passed

Description

87%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.

A strong description: third-person-style, concrete, with an explicit "Use when..." trigger clause covering multiple natural invocations. The only weakness is that action coverage is broad rather than comprehensive, omitting the review-loop and nudge behaviors the body actually implements.

DimensionReasoningScore

Specificity

The description lists several concrete actions — "Validate and monitor OpenShell GitHub issues and PRs", "triage issues/PRs for project validity, gate PRs, run gator, validate submissions, or monitor PRs toward merge readiness" — anchored to a concrete mechanism (the "gator:* state machine"). It is not a 5 because coverage omits several real capabilities of the skill (code-review loop, comment/label posting, TTL nudging, CI watching).

4 / 5

Completeness

It explicitly answers both questions with concrete trigger phrasing: the "what" in "Validate and monitor OpenShell GitHub issues and PRs using the gator:* state machine" and the "when" in an explicit "Use when asked to..." clause enumerating five triggers. This matches the top anchor's example pattern.

5 / 5

Trigger Term Quality

Natural phrases a user would actually say are present: "triage issues/PRs", "gate PRs", "run gator", "validate submissions", "monitor PRs toward merge readiness". A few natural variants are missing (e.g., "review PRs", "gator labels", "merge readiness check"), so it falls just short of comprehensive synonym coverage.

4 / 5

Distinctiveness Conflict Risk

The niche is clear and unambiguous — scoped to the OpenShell repository and the proprietary "gator:*" label state machine — so it would not naturally trigger for any other skill. Domain-unique terms like "gator" and "OpenShell" give it minimal conflict risk.

5 / 5

Total

18

/

20

Passed

Validation

87%

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

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (1334 lines); consider splitting into references/ and linking

Warning

referenced_paths_exist

Referenced path issues: 2 missing, 2 deeper-than-1-level

Warning

Total

14

/

16

Passed

Repository

NVIDIA/OpenShell

Path

scripts/agents/gator/skills/gator-gate/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.