CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

github-repository-settings

Load to preview, render or check a repository's selected review instruction files and local review pointer.

Quality

73%

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

Fix and improve this skill with Tessl

tessl review fix ./skills/github-repository-settings/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

82%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 a tightly written, highly actionable wrapper-skill overview: real commands, exit-code contract, concrete settings semantics, and disciplined one-level-deep pointers. Weaknesses are minor — a maintainer-oriented dependency/release paragraph that wastes tokens, no remediation guidance for failed checks, and no section headers.

DimensionReasoningScore

Conciseness

The body is exceptionally dense with operational facts (commands, exit codes, env var defaults, precedence rules) and explains nothing Claude already knows, so every token nearly earns its place. It is not a 5 because maintainer-facing meta-content ("KEN-2362 removes that dependency", the catalog/engine release-check sentences) is not needed at task-execution time and could be trimmed.

4 / 5

Actionability

The bash block is copy-paste-ready and covers all four command variants (adopt --dry-run, render, check, check --staged), with fully concrete specifics: exit codes ("0 clean, 1 findings, 2 could not complete"), env vars ("GITHUB_STANDARD_CHECK_LOCATION", "GITHUB_STANDARD_BOT_REVIEW defaults to off"), and a verified `--help` entry point.

5 / 5

Workflow Clarity

A clear sequence is present — preview with `adopt --dry-run`, take ownership via the linked bot-instructions adoption operation, `render`, then `check`/`check --staged` as the validation checkpoint — with guardrails ("reports hand edits and refuses symlinked preview targets"). It falls short of 5 because no error-recovery loop is described for what to do when `check` exits 1 with findings.

4 / 5

Progressive Disclosure

The body is a short overview with well-signaled, one-level-deep references (`--help` for the option contract, the bot-instructions manifest schema and SKILL.md, the settings example, commit-gates hooks), and the referenced script exists in the bundle. It is not a 5 because there are no section headers to aid navigation and the referenced `kendex.settings.toml.example` is not present in the bundle.

4 / 5

Total

17

/

20

Passed

Description

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

The description gives a concrete, appropriately terse statement of what the skill does, but reads as internal jargon for a package catalog rather than user-facing trigger text. It completely lacks a "when to use" clause and shares its core verbs with a sibling skill, creating trigger ambiguity.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user asks to preview, apply, or verify a GitHub repository's review instruction settings or review pointer configuration."

Replace insider jargon ("local review pointer", "selected review instruction files") with natural user vocabulary and synonyms such as "review settings", "bot review instructions", or concrete file names like CODEOWNERS/review configs.

Differentiate from the sibling bot-instructions skill by naming what is unique here (adopting/rendering GitHub standard review settings), so the description does not fire for the library skill's own use cases.

DimensionReasoningScore

Specificity

The description lists several concrete actions ("preview, render or check") tied to a named domain ("a repository's selected review instruction files and local review pointer"). It falls short of a 5 because coverage has gaps — the adoption workflow, exit codes, and settings management from the body are unmentioned.

4 / 5

Completeness

It clearly answers "what" (preview, render, or check review instruction files) but contains no "Use when..." clause or equivalent trigger guidance, capping completeness at 3 per the rubric guidelines.

3 / 5

Trigger Term Quality

Terms like "preview", "render", "check", and "repository" are words users would naturally say, but insider jargon such as "local review pointer" and "selected review instruction files" are not natural user phrases, and common variations/synonyms ("review settings", "bot instructions", "CODEOWNERS") are missing. Not a 2 because more than one or two relevant, non-generic keywords are present.

3 / 5

Distinctiveness Conflict Risk

The domain is somewhat specific (repository review instruction files), but the verbs preview/render/check and the subject matter substantially overlap with the closely related sibling `bot-instructions` skill that owns those same operations, so the wrong skill could plausibly trigger.

3 / 5

Total

13

/

20

Passed

Validation

81%

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

Validation — 13 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

frontmatter_unknown_keys

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

Warning

relative_links

Relative link issues: 1 missing, 2 suspicious

Warning

Total

13

/

16

Passed

Repository

vanillagreencom/kendex

Path

skills/github-repository-settings/SKILL.md

Revision

32d7bc7

Reviewed

Table of Contents

DiscoveryImplementationValidation

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.

Claim skill