CtrlK
BlogDocsLog inGet started
Tessl Logo

tables-and-dynamic-specs

Parameterize and generate Ginkgo specs — DescribeTable/Entry table-driven specs, Entry descriptions (string, nil, closure, EntryDescription), PEntry/FEntry and per-Entry decorators, DescribeTableSubtree, generating specs in a construction-time loop, loading fixtures in TestXxx before RunSpecs, and shared-behavior closures. Use when you have repetitive specs differing only by inputs, want data-driven or generated specs, or are extracting reusable It blocks across Contexts.

72

Quality

90%

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

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.

A tight, example-driven reference whose executable code, wrong/right contrasts, and non-obvious construction-phase gotchas make it highly actionable. Its weaknesses are minor: some baseline Ginkgo-docs restatement, a duplicated warning, small typos, and everything inlined in one file rather than splitting deeper detail out.

Suggestions

Fix the typos on line 10 ('Perfer `DescrtibeTable`' → 'Prefer `DescribeTable`') and de-duplicate the BeforeSuite warning stated at both the start and end of the fixture-loading section.

Trim restatements of baseline Ginkgo behavior (basic DescribeTable mechanics, the EntryDescription format table) to just the non-obvious construction-time semantics.

Consider moving secondary topics (DescribeTableSubtree, shared-behavior closures) into a references/ file so SKILL.md stays a lean overview.

DimensionReasoningScore

Conciseness

The body is dense and Ginkgo-specific (the construction-time evaluation gotcha is genuinely non-obvious), but it restates some baseline Ginkgo documentation (DescribeTable mechanics, the EntryDescription table), repeats the BeforeSuite warning twice ('a loop reading a BeforeSuite-populated slice generates zero specs' and 'Don't load it in BeforeSuite — it's too late, and the loop generates no specs'), and contains typos ('Perfer `DescrtibeTable`'). Mostly efficient with minor trims available — the 4 anchor, not 5; not 3 because nearly all content is skill-specific rather than generic padding.

4 / 5

Actionability

Every section carries complete, executable Go examples covering the common cases: the WRONG/RIGHT contrast for the nil-shelf gotcha, the four Entry description mechanisms in one runnable table, DescribeTableSubtree, and the TestXxx fixture-loading pattern with a pre-RUNSpecs assertion ('g.Expect(fixtureBooks).NotTo(BeEmpty())'). Copy-paste-ready throughout; matches the 5 anchor.

5 / 5

Workflow Clarity

Although not a sequential process skill, each section states when to apply it ('When you want a whole subtree (multiple Its, their own setup) per entry, use DescribeTableSubtree'; 'Struct-per-row for many params'), the key failure mode is explicitly flagged ('THE gotcha', 'nil pointer!'), and error recovery is shown via the WRONG/RIGHT pair. Selection guidance is clear but there is no explicit decision ordering across patterns — the 4 anchor; not 3 because the guidance that exists is coherent and error paths are concretely illustrated.

4 / 5

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are all absent), so all ~150 lines are inline under well-organized section headers with external doc links (onsi.github.io/#table-specs etc.) and pointers to sibling skills (ginkgo:overview, ginkgo:decorators, ginkgo:filtering). Structure and signaling are good, but the body exceeds the under-50-lines condition for a 5 without external references, and all detail (DescribeTableSubtree, shared behaviors) is inlined rather than split out — the 4 anchor; not 3 because organization and navigation are genuinely solid.

4 / 5

Total

17

/

20

Passed

Description

92%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 dense, highly specific description that clearly states both what the skill does and when to use it, with distinct Ginkgo-specific triggers and third-person voice. Its only weakness is a jargon-heavy enumeration that omits a few natural synonyms users might actually say, costing it slightly on trigger-term quality.

Suggestions

Add one or two natural synonyms users would say, e.g. 'table tests' or 'parameterized tests', to the trigger clause.

Trim the API-name enumeration slightly so the most common entry points (DescribeTable, Entry, DescribeTableSubtree) stand out from rare ones (PEntry/FEntry, per-Entry decorators).

DimensionReasoningScore

Specificity

The description enumerates many specific concrete capabilities ('DescribeTable/Entry table-driven specs, Entry descriptions (string, nil, closure, EntryDescription), PEntry/FEntry and per-Entry decorators, DescribeTableSubtree, generating specs in a construction-time loop, loading fixtures in TestXxx before RunSpecs, and shared-behavior closures') in third person, comprehensively covering the skill's feature set. It clearly matches the 5 anchor; it is not 4 because coverage is complete rather than minorly gapped.

5 / 5

Completeness

It explicitly answers both questions: a detailed 'what' (the capability enumeration) and an explicit 'when' ('Use when you have repetitive specs differing only by inputs, want data-driven or generated specs, or are extracting reusable It blocks across Contexts'). This matches the 5 anchor with concrete trigger phrases; it is not 4 because the when-clause is explicit rather than merely present.

5 / 5

Trigger Term Quality

Natural trigger phrases are present ('repetitive specs differing only by inputs', 'data-driven or generated specs', 'table-driven specs', 'extracting reusable It blocks'), but the description leans heavily on API jargon (PEntry/FEntry, DescribeTableSubtree, TestXxx) and misses common synonyms a user might say such as 'table tests' or 'parameterized tests'. This sits noticeably above the midpoint between anchors 3 and 5 but is not comprehensive enough for 5.

4 / 5

Distinctiveness Conflict Risk

Ginkgo table-driven/dynamic spec generation is a clear niche with distinct triggers ('repetitive specs differing only by inputs') that would not naturally fire a generic testing or Ginkgo-overview skill. It matches the 5 anchor; overlap with sibling Ginkgo skills (ginkgo:overview, ginkgo:decorators) is minimal and the triggers are specific to this skill's scope.

5 / 5

Total

19

/

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
onsi/ginkgo
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.