CtrlK
BlogDocsLog inGet started
Tessl Logo

row-pinning

Pin stable row IDs into top, center, and bottom collections with rowPinningFeature and keepPinnedRows. Load for filtering/pagination visibility, explicit region rendering, or renderer-owned sticky CSS.

59

Quality

70%

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 ./packages/table-core/skills/row-pinning/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

81%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 an efficient, actionable reference that assumes competence and avoids padding, with concrete code and wrong/correct pitfalls. Its main weakness is the vague 'inspect node_modules' API Discovery pointer, which would be stronger as concrete inline API names or a clearly signaled reference file.

Suggestions

Replace the 'Inspect node_modules/.../row-pinning/' line with the concrete region getter and row API names (e.g. getTopRows/getCenterRows/getBottomRows, row.pin/isPinned) so the guidance is fully executable without filesystem exploration.

Add a one-line validation checkpoint after the Common Mistakes (e.g. verify pinned rows remain visible under filtering/pagination) to give the workflow an explicit feedback loop.

Consider promoting the visibility-policy section above API Discovery since it is the higher-value runtime decision.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence: setup, region rendering, two pitfalls, and a visibility policy, each delivered with minimal prose and no padding explaining what pinning or a row model is. Every token earns its place.

5 / 5

Actionability

Provides copy-paste-ready setup and region-iteration code plus concrete wrong/correct pairs for the high-severity mistakes; the only gap is the API Discovery section, which points at a directory to inspect rather than giving the specific getter/API names inline.

4 / 5

Workflow Clarity

There is a clear conceptual sequence (setup → render regions → avoid mistakes → pick visibility policy), and the Common Mistakes act as corrective checkpoints; it is not a multi-step destructive operation, so the simple-skill guidance applies, but no explicit validate/retry step is present, keeping it just below 5.

4 / 5

Progressive Disclosure

Content is well-organized into focused sections (Setup, Core Patterns, Common Mistakes, visibility policy, API Discovery) under 50 lines with no external bundle files; it is appropriately self-contained, though the API Discovery pointer is a relative path hint rather than a clearly signaled one-level reference, leaving minor organization gaps.

4 / 5

Total

17

/

20

Passed

Description

58%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 is specific and well-targeted to a distinct TanStack Table feature, but it omits an explicit 'Use when...' trigger and relies on library API names rather than natural user phrasing. Adding a trigger clause and more colloquial keywords would lift the completeness and trigger-term dimensions.

Suggestions

Add an explicit 'Use when...' clause naming user-facing situations, e.g. 'Use when the user wants to pin or freeze table rows to top/bottom regions, or needs sticky header/footer row behavior in a TanStack Table grid.'

Replace or augment API jargon (rowPinningFeature, keepPinnedRows) with natural terms users say, such as 'freeze rows', 'sticky rows', 'pinned header/footer rows'.

Tighten the motive list into concrete triggering scenarios rather than internal reasons like 'renderer-owned sticky CSS'.

DimensionReasoningScore

Specificity

Names several concrete actions — 'Pin stable row IDs into top, center, and bottom collections', 'keepPinnedRows', and 'renderer-owned sticky CSS' — giving specific capability detail with only minor coverage gaps around region getters.

4 / 5

Completeness

The 'what' is clear (pin rows into regions, configure visibility), but there is no 'Use when...' clause; the 'when' is only weakly implied by 'Load for filtering/pagination visibility, explicit region rendering, or renderer-owned sticky CSS', which lists motives rather than triggering situations — capping completeness at 3 per the missing-trigger guideline.

3 / 5

Trigger Term Quality

Includes relevant domain terms ('row pinning', 'filtering/pagination visibility', 'sticky CSS') but leans on library-specific jargon (rowPinningFeature, keepPinnedRows) rather than the natural phrasings a user would say; missing common variations like 'freeze rows'.

3 / 5

Distinctiveness Conflict Risk

The row-pinning niche is specific and clearly tied to a single TanStack Table feature, so it is mostly distinct with only minor overlap risk against sibling table-features skills.

4 / 5

Total

14

/

20

Passed

Validation

87%

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

Validation14 / 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

Total

14

/

16

Passed

Repository
TanStack/table
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.