fixtures

Guides authoring, organizing, and referencing test fixtures in this repo. Use when creating new fixtures, writing tests that depend on fixtures, or deciding what should be checked into git. Engine fixtures (rendering corpora) live in the engine repo.

Quality

75%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/fixtures/SKILL.md

Quality

Content

72%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 tight, well-organized convention doc with concrete naming and placement rules and a clear engine/product boundary. Its main gap is the lack of an explicit, validated workflow for the destructive re-snapshot operation and for adding a new fixture end-to-end.

Suggestions

Add a short numbered workflow for adding a new fixture (check for duplicates → pick grida-owned vs engine directory → name per pattern → confirm LFS/git tracking) with a verification step.

Spell out the re-snapshot step concretely — the copy/sync command and a check that staying tests still pass afterward — since 're-snapshot deliberately' leaves the destructive operation underspecified.

Consider trimming the 'What fixtures are' / 'Why we keep them' framing, which restates general fixture knowledge Claude already has.

Dimension	Reasoning	Score
Conciseness	The body is lean and well-sectioned with little padding, but the 'What fixtures are' and 'Why we keep them' sections lightly explain the general concept of test fixtures — which Claude already knows — so a few tokens could be trimmed.	4 / 5
Actionability	Gives concrete, executable rules — a naming pattern '<domain>-<property>[-<descriptor>].<ext>', a labeled directory tree with ownership, an explicit engine-repo URL, and a hard rule against referencing gitignored paths — with only a minor gap: the re-snapshot step is described as 're-snapshot deliberately from the engine repo' without the actual commands.	4 / 5
Workflow Clarity	Guidance is presented as bulleted conventions rather than a sequenced workflow, and the destructive re-snapshot operation (overwriting frozen dirs) has no validation or checkpoint steps; per the destructive-operations cap this cannot exceed 3.	3 / 5
Progressive Disclosure	A clean single-file overview with clearly signaled, one-level-deep references (a single link to fixtures/README.md and the engine repo URL), well-organized sections, and no nested or buried references; no bundle files exist to verify, but the structure as written is exemplary.	5 / 5
	Total	16 / 20 Passed

Description

78%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, well-structured description that clearly states both capability and trigger conditions with a useful boundary note. The main weakness is that the named actions sit at a fairly abstract level compared to the concrete fixture conventions the skill actually teaches.

Suggestions

Tighten the 'what' toward concrete operations — e.g. 'names, places, and git-tracks test fixtures' — instead of the generic 'authoring, organizing, and referencing'.

Consider adding one or two fixture file extensions or formats (e.g. '.fig', '.grida') to broaden natural keyword coverage in the description.

Dimension	Reasoning	Score
Specificity	Names the domain ('test fixtures in this repo') and lists three actions ('authoring, organizing, and referencing'), but the verbs are abstract categories rather than the concrete fixture operations (naming, LFS, frozen snapshots, dedup) that form the skill's real substance, so coverage is not comprehensive.	3 / 5
Completeness	Explicitly answers both: what ('Guides authoring, organizing, and referencing test fixtures in this repo') and when ('Use when creating new fixtures, writing tests that depend on fixtures, or deciding what should be checked into git'), with multiple concrete trigger phrases.	5 / 5
Trigger Term Quality	Includes natural phrases a user would actually say — 'creating new fixtures', 'writing tests that depend on fixtures', 'deciding what should be checked into git' — with good coverage, though file extensions and synonyms (.fig, .grida) that appear in the body are absent from the description.	4 / 5
Distinctiveness Conflict Risk	The 'test fixtures in this repo' niche plus the engine-boundary clause ('Engine fixtures... live in the engine repo') make it mostly distinct, with only minor overlap risk against a generic testing skill.	4 / 5
	Total	16 / 20 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
relative_links	Relative link issues: 1 suspicious	Warning

	Total	15 / 16 Passed

Repository: gridaco/grida
Path: .agents/skills/fixtures/SKILL.md
Commit: 03fb751

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

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.