CtrlK
BlogDocsLog inGet started
Tessl Logo

gh-setup

Configure GitHub settings, collaboration files, Actions, releases, and deployments. Use for setup or changes to those surfaces; excludes provider infrastructure and product code.

68

Quality

81%

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

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

An exceptionally lean, contract-driven routing skill: no token waste, explicit validation and failure-recovery steps for destructive/live operations, and a clean one-level-deep reference structure with conditional loading triggers. The only flaws are minor: a few sections stop at policy without showing the concrete command, and merge-queue.md is orphaned from the navigation.

Suggestions

Link merge-queue.md where the body mentions "merge queues" (the require-pull-requests clause) so the existing reference file is discoverable.

Give one concrete readback example (e.g. the `gh api` call for a changed setting or Environment) so the read-back requirement is executable, not just stated.

Anchor abstract invariants like "Make GitHub the enforceable shell around the repository's existing... contracts" to a concrete first action so the entry point is as actionable as the routes that follow.

DimensionReasoningScore

Conciseness

The body is dense operational directive with zero padding — e.g. "Pull requests execute untrusted code with read-only credentials", "Publish one immutable payload and deploy that payload instead of rebuilding it" — and never explains concepts Claude already knows (what Actions or Dependabot are). Every line states a contract or a routing rule, matching anchor 5's "every token earns its place".

5 / 5

Actionability

Routing is concrete and conditional ("Read [Actions security](references/actions-security.md) when adding workflows or changing code execution... credential, publication, signing, or deploy boundaries") and exact tooling is named ("Run repository gates plus `actionlint` and `zizmor`"). It stops short of anchor 5 because most sections give policy and decision rules rather than copy-paste commands — e.g. the readback requirement never shows the `gh api` call that would satisfy it.

4 / 5

Workflow Clarity

A clear sequence runs route selection ("Select the relevant route below before loading references") through shared contracts, route-specific work, and "Verify and Finish", with explicit validation checkpoints ("Run repository gates plus `actionlint` and `zizmor` when workflows changed") and error-recovery feedback loops for risky live operations ("On partial failure, reconcile durable state before retry; never create a new version... merely to make a workflow green", plus recording before-state and rollback path before authorized mutations). The structured Output block closes the process as a checklist.

5 / 5

Progressive Disclosure

The body is a pure overview routing to 16 one-level-deep references, every link well-signaled with a conditional trigger ("only when that tool is selected", "only after a concrete failure"), and all 15 linked paths resolve to real files in references/. It misses anchor 5 on one real navigation gap: references/merge-queue.md exists but is never linked from the body (the text mentions "merge queues" without pointing to it), leaving that content undiscoverable.

4 / 5

Total

18

/

20

Passed

Description

75%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 well-formed third-person description that clearly states what the skill configures and when to use it, with an explicit scope boundary that lowers conflict risk. Its main gap is trigger phrasing: the when-clause points back at its own noun list instead of echoing the words users actually say.

Suggestions

Rewrite the trigger clause with concrete user phrasings, e.g. "Use when setting up or changing GitHub Actions workflows, repo settings, branch rules, releases, or deployments" rather than "those surfaces".

Add natural synonyms users would say — CI, workflows, rulesets, issue templates — and drop the internal term "collaboration files" or pair it with concrete file names like CONTRIBUTING.md or SECURITY.md.

Sharpen the verb coverage beyond the single "Configure": distinguish configuring, adding, and fixing (e.g. "add or fix workflows") so the capability list reads as distinct actions.

DimensionReasoningScore

Specificity

The description lists several concrete surfaces — "Configure GitHub settings, collaboration files, Actions, releases, and deployments" — mirroring anchor 4 ("Extracts text from PDF files, fills forms, converts pages to images") where several specific targets are named with one generic verb. It is not anchor 5 because a single verb ("Configure") covers all targets and some concrete capabilities (workflows, rulesets, environments) are folded into broader nouns rather than named.

4 / 5

Completeness

Both halves are explicit: a clear "what" ("Configure GitHub settings, collaboration files, Actions, releases, and deployments") and an explicit "when" ("Use for setup or changes to those surfaces"), plus a scope exclusion. It sits at anchor 4 rather than 5 because the trigger clause is self-referential ("those surfaces") instead of concrete trigger phrases a user would actually utter.

4 / 5

Trigger Term Quality

Natural trigger words are present: "GitHub", "Actions", "releases", "deployments", "settings" — phrases a user would plausibly say. It falls short of anchor 5's comprehensive synonym/extension coverage: common user phrasings like "CI", "workflows", "repo settings", "branch protection", or file names like ".github/workflows" are absent, and "collaboration files" is skill-internal jargon users would not say.

4 / 5

Distinctiveness Conflict Risk

The GitHub-repo-configuration niche is well bounded and the exclusion ("excludes provider infrastructure and product code") actively reduces overlap. It does not reach anchor 5 because "Actions" and "deployments" are terms that could still collide with adjacent CI/CD or cloud-deployment skills.

4 / 5

Total

16

/

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
uinaf/agent-skills
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.