Name: punkt-elements-dev
Rating: 69 (1 reviews)
Author: oslokommune

punkt-elements-dev

Developing Lit web components in the Punkt design system (@oslokommune/punkt-elements). Covers creating, modifying, and testing components in /packages/elements/src/components/. Use when working on Punkt Elements source code.

1.44x

Quality

54%

Does it follow best practices?

Impact

97%

1.44x

Average score across 3 eval scenarios

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/punkt-elements-dev/SKILL.md

Quality

Content

30%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 extremely lean table of contents pointing to 14 section files, but it contains no executable guidance, no workflow, and — critically — none of the referenced files are present in the bundle. It functions as a navigational skeleton with nothing to navigate to and no standalone instruction.

Suggestions

Add concrete, executable guidance to the body — e.g., a minimal Lit component skeleton, the build/test/lint commands, and file-path conventions — so Claude can act without opening every referenced file.

Include a sequenced workflow with validation checkpoints for common tasks like adding a new element (scaffold → implement → run tests → lint → build) rather than only a topic index.

Ship the referenced section files (architecture-overview.md, testing.md, checklist-new-element.md, etc.) in the bundle — all 14 linked files are currently missing, so the overview has no detailed material to disclose.

Dimension	Reasoning	Score
Conciseness	The body is a lean index with zero padding and no over-explanation of concepts Claude already knows, fitting 'efficient; minor instances that could be trimmed'. Not 5 because it is a bare skeleton TOC with no lean substantive content, only link entries; not 3 because there is no unnecessary explanation at all.	4 / 5
Actionability	The body provides no concrete code, commands, or executable guidance — it is purely a list of section references ('Component Implementation', 'Testing', etc.), matching 'entirely vague or abstract; no concrete code or commands; only describes rather than instructs'. Not 2 because there are not even high-level executable hints, only topic labels.	1 / 5
Workflow Clarity	There is no sequenced workflow or validation in the body; the numbered list is a topic index, not an ordered process, matching 'steps missing or incoherent; no sequence; no validation'. Not 2 because no rough sequence of operations exists at all, only a section TOC.	1 / 5
Progressive Disclosure	The overview correctly signals one-level-deep references (a clean 14-item TOC), but none of the referenced files (architecture-overview.md, testing.md, checklist-new-element.md, etc.) exist in the bundle, so the overview discloses into nothing and navigation is broken. Scored against the actual (missing) bundle structure per the guideline, this lands at 'some structure but not fully realized'; not 4 because the missing files are more than a minor gap, not 2 because references are prominent and well-signaled rather than buried.	3 / 5
	Total	9 / 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 concise, well-formed description that clearly states both the capability and a specific trigger for a niche package. It uses appropriate third-person voice with no fluff; the only gap is slightly broader trigger coverage and more granular action verbs.

Dimension	Reasoning	Score
Specificity	Names the domain precisely ('Lit web components in the Punkt design system (@oslokommune/punkt-elements)') and lists several concrete actions ('creating, modifying, and testing components') plus a source path, matching the 'several specific actions; minor gaps' anchor. Not 5 because the verbs are high-level and coverage is incomplete (no styling, events, build); not 3 because it lists more than 1-2 actions.	4 / 5
Completeness	Explicitly answers both what ('Covers creating, modifying, and testing components in /packages/elements/src/components/') and when ('Use when working on Punkt Elements source code.'), matching the 'has both what and when' anchor. Not 5 because the single trigger clause is narrower than the multi-trigger 5 example; not 3 because when is present and explicit, not merely implied.	4 / 5
Trigger Term Quality	Includes natural domain terms a user would say ('Lit web components', 'Punkt design system', 'Punkt Elements', 'source code') with an explicit trigger ('Use when working on Punkt Elements source code'), fitting 'good keyword coverage; a few natural terms missing'. Not 5 because it lacks synonym/variation breadth; not 3 because coverage is clearly good rather than just 'some'.	4 / 5
Distinctiveness Conflict Risk	Targets a specific named package (@oslokommune/punkt-elements) with a distinct trigger ('working on Punkt Elements source code'), giving a clear niche with minimal conflict risk, matching the 5 anchor. A user invoking this trigger is unlikely to want a different skill.	5 / 5
	Total	17 / 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: 14 missing	Warning

	Total	15 / 16 Passed

Repository: oslokommune/punkt-skills
Path: skills/punkt-elements-dev/SKILL.md
Commit: c1de050

Reviewed: about 23 hours 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.