CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

preflight

Load to run, tune, or debug preflight.

Quality

68%

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

Quality

Content

90%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 exemplary lean overview: executable commands, precise placement guidance, and cleanly signaled one-level-deep disclosure into --help and references/lanes.md. The only deductions are an implicit fix-then-re-run loop and a README.md reference that does not resolve inside the bundle.

Suggestions

State the feedback loop explicitly (e.g., 're-run until preflight exits 0; exit codes are in preflight --help') so the validate→fix→re-validate checkpoint is unambiguous.

Fix the dangling '[README.md](README.md) § Wiring' reference: either ship README.md in the bundle or point at an in-bundle path (e.g., references/wiring.md).

DimensionReasoningScore

Conciseness

The body is ~10 lines with zero padding: 'Run preflight in the validate step, before the project's own validation command', the three invocations, and one navigation sentence. No concept Claude already knows is explained; every token earns its place.

5 / 5

Actionability

Fully executable, copy-paste-ready commands covering the common cases ('.agents/skills/preflight/scripts/preflight', '--staged', '--all') with per-scope comments, plus a concrete placement directive and an unambiguous remediation rule ('Fix what a finding reports; never widen a lane's exclusions to clear it').

5 / 5

Workflow Clarity

A clear run-in-validate-step → fix-findings sequence is present, but the feedback loop is implicit: it never says to re-run until clean or how to read the exit code (deferred to '--help'). Not a destructive/batch operation, so no cap applies, but the explicit validate-again checkpoint of the top anchor is missing.

4 / 5

Progressive Disclosure

The body is a pure overview with well-labeled, one-level-deep pointers ('Lanes, scopes, settings, output and exit codes are in preflight --help' and '[references/lanes.md]'), and lanes.md exists and itself nests no further references. However the '[README.md](README.md) § Wiring' link targets a file absent from the skill bundle — a minor dangling-reference gap.

4 / 5

Total

18

/

20

Passed

Description

36%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 frontmatter is a sparse trigger line: it identifies the tool by name but delegates all capability content to a separate 'summary' field the description rubric does not score, and it omits any 'when to use' guidance. As written it reads like an invocation hint rather than a self-contained trigger description.

Suggestions

Fold the concrete capability list from 'summary' into 'description' (e.g., 'Diff-scoped fail-only checks over one change — shell safety, unwired suites, scratch directories, temp paths, dead path citations, applied migrations, data syntax.') so the 'what' is explicit.

Add a 'Use when...' clause, e.g., 'Use when validating a change before commit/PR, or when preflight findings need triaging.'

Add natural trigger synonyms (check, validate, pre-commit, lint) alongside 'run/tune/debug' to widen natural-language matching.

DimensionReasoningScore

Specificity

'Load to run, tune, or debug preflight' names the domain but 'run, tune, or debug' are generic usage verbs applicable to any tool, not concrete capability actions; the actual capabilities (shell safety, unwired suites, etc.) live in the separate 'summary' field, not the description.

2 / 5

Completeness

The 'what' is circular — running/tuning/debugging preflight says nothing about what preflight checks — and there is no 'Use when...' or equivalent trigger guidance at all, fitting the vague-what-and-no-when anchor rather than the clear-what anchor.

2 / 5

Trigger Term Quality

'run', 'tune', 'debug' and especially 'preflight' are keywords a project user would naturally say ('run preflight', 'debug preflight'), but common variations and synonyms (check, validate, pre-commit, lint) are missing.

3 / 5

Distinctiveness Conflict Risk

Distinctiveness rests entirely on the proper-noun trigger 'preflight', with no capability information to separate it from other tool skills; the generic word 'debug' also risks firing when a user means debugging their own code, not this tool.

3 / 5

Total

10

/

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

Warning

Total

13

/

16

Passed

Repository

vanillagreencom/kendex

Path

.agents/skills/preflight/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