CtrlK
BlogDocsLog inGet started
Tessl Logo

naming

How to think about names in the Grida repo — not conventions, but what a name commits you to, reveals about the system, and costs to change. The central discipline is that a strict, honest name refuses to grow, and that refusal drives the repo's shape (flat modules, small agnostic packages, suffix siblings). Use when planning a new package, crate, module, directory, route group, or test corpus — the name comes first.

57

Quality

66%

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/naming/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

A genuinely well-written principles document: repo-specific, opinionated, with concrete decision rules, real naming examples, and a measurable self-check (the diff test). Its two real weaknesses are the dangling cases.md reference — the promised concrete tables and grandfathered short-name list simply don't exist in the bundle — and a layer of generic-wisdom prose that could be trimmed without losing anything Claude doesn't already know.

Suggestions

Fix the dangling reference: either add the actual cases.md (with the concrete tables and grandfathered short-name list the body promises) or remove the closing link and inline the few most load-bearing examples.

Trim the generic sections — 'One module, one thing' and parts of 'Name first' restate single-responsibility and design-first principles Claude already knows; keep only the repo-specific mechanism (how the gate discipline produced the actual package layout).

Consolidate the closing 'The short version' recap — it repeats nearly every section at ~8 bullets; either cut it to the 2-3 rules that are unique to this repo or drop it, since the sections are already short.

DimensionReasoningScore

Conciseness

The body is dense with repo-specific insight and mostly free of boilerplate, but it restates concepts Claude already knows (e.g., 'One module, one thing' is the single-responsibility principle; 'Name first' echoes general design practice) and carries padded prose flourishes like 'Letting a name go stale is how codebases rot quietly' and 'Naming is the cheapest design review you get.' It could be tightened toward the efficient anchor.

3 / 5

Actionability

For an instruction-only skill the guidance is concretely actionable: explicit decision rules ('rename to match... or extract the drifted pieces — and you must pick one promptly'), copy-paste-ready tests ('would adding any peer to this parent make the terse name ambiguous?'), and real inline examples ('grida-canvas/canvas-text/ is the symptom; grida-canvas/text/ is the correction'). Falls short of fully executable coverage because the promised worked cases live in a cases.md file that is not in the bundle.

4 / 5

Workflow Clarity

The document gives a clear implicit sequence (name first, then types/tests) plus symptom-to-fix mappings in the diagnostic section, and the 'diff test' provides explicit, measurable validation signals (per-file diffs, clean deletion). Not a 5 because the sequence is distributed across principle sections rather than stated as one workflow with checkpoints — minor gaps, not absent ones.

4 / 5

Progressive Disclosure

The body is well-sectioned and the single external reference is clearly signaled at the end ('See cases.md for concrete tables and the grandfathered short-name list'), but that reference dangles — no cases.md exists anywhere in the bundle (references/, scripts/, assets/ are all absent). Per the guideline to score against the actual bundle structure, a promised one-level-deep reference pointing at nothing drops it to 'some structure but could be better organized.'

3 / 5

Total

14

/

20

Passed

Description

70%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-scoped, honest description for a judgment skill: it states its philosophy up front, anchors it to the Grida repo, and provides an explicit and fairly specific 'Use when' trigger list covering the main artifacts the skill applies to. It is slightly held back by a conceptual rather than capability-oriented 'what' and by missing a few natural trigger terms such as 'rename'.

Suggestions

Add 'rename' or 'renaming/refactoring' to the 'Use when' clause — the skill's drift/extract guidance applies directly to renaming decisions but no trigger term captures that intent.

Convert part of the conceptual 'what' into concrete capabilities, e.g. 'Decide when to rename vs. extract a drifting module, when to mint a two-letter name, and how to order name segments' — this would raise specificity without inflating length.

DimensionReasoningScore

Specificity

The description scopes the domain precisely ('How to think about names in the Grida repo... what a name commits you to, reveals about the system, and costs to change') and lists concrete artifacts ('package, crate, module, directory, route group, or test corpus'), but names no concrete actions it performs — appropriate for a thinking/decision skill yet only partially comprehensive, matching the 'names domain and 1-2 concrete actions' anchor.

3 / 5

Completeness

Both 'what' (naming philosophy: commitments, revelations, change costs) and 'when' (planning a new package/crate/module/directory/route group/test corpus) are explicitly present, and the trigger list is specific. Not a 5 because the 'what' is framed conceptually ('how to think about') rather than as concrete capabilities with trigger phrases attached to each.

4 / 5

Trigger Term Quality

'Use when planning a new package, crate, module, directory, route group, or test corpus' gives good natural-phrase coverage users would actually say when creating or naming things. A few natural terms are missing — notably 'rename', 'naming convention', and 'refactor/extraction' phrasing — so it falls just short of the comprehensive anchor.

4 / 5

Distinctiveness Conflict Risk

The Grida-repo scoping and naming-first framing carve a clear niche ('that refusal drives the repo's shape (flat modules, small agnostic packages, suffix siblings)') with minimal conflict risk. Minor overlap remains with generic code-style or architecture-planning skills triggered by terms like 'module' and 'directory', keeping it below the distinct-trigger anchor.

4 / 5

Total

15

/

20

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.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 1 missing

Warning

Total

15

/

16

Passed

Repository
gridaco/grida
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.