atomic-design

Use when structuring or decomposing any frontend UI into reusable components, regardless of framework. Applies Brad Frost's atomic design methodology — atoms, molecules, organisms, templates, and pages — to guide consistent component hierarchy, naming, and composition decisions.

Quality

63%

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 ./skills/atomic-design/SKILL.md

Quality

Content

48%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 skill provides a well-structured conceptual framework for atomic design decomposition with a clear workflow and useful decision heuristics. However, it is significantly over-verbose for Claude's context window, spending many tokens explaining concepts Claude already knows (what atomic design is, why consistency matters) rather than providing concrete, actionable examples like sample UI decompositions or naming convention templates. The lack of concrete examples (e.g., decomposing a login page into its atomic levels) limits its actionability.

Suggestions

Remove the 'Why atomic design' rationale section entirely — Claude doesn't need to be convinced of the methodology's value, it needs to know how to apply it.

Add a concrete worked example: take a specific UI (e.g., a login page or product listing) and show the full decomposition into atoms/molecules/organisms/templates/pages with actual component names.

Trim the five-level overview to a compact table or bullet list with one-line definitions, since the expanded guidance is already delegated to references/hierarchy.md.

Move the common pitfalls and anti-patterns into the referenced hierarchy.md file to keep the main SKILL.md focused on the actionable workflow.

Dimension	Reasoning	Score
Conciseness	The content is noticeably verbose, extensively explaining concepts Claude already understands well — what atomic design is, why consistency matters, what reuse means, the chemistry metaphor. The 'Why atomic design' section and much of the overview text explain foundational concepts that Claude would already know, consuming significant token budget without adding actionable value.	2 / 5
Actionability	The decomposition workflow provides a clear ordered procedure, and the decision heuristics give concrete boundary rules. However, there are no concrete code examples, no component naming conventions with actual examples, no sample decomposition of a real UI, and no framework-specific snippets — it remains at the level of conceptual guidance rather than executable, copy-paste-ready instructions.	3 / 5
Workflow Clarity	The six-step decomposition workflow is clearly sequenced and logically ordered (top-down from screen to atoms). The decision heuristics serve as implicit checkpoints for boundary decisions. However, there are no explicit validation steps or feedback loops — no 'verify your decomposition by checking X' step — which is a minor gap for a non-destructive conceptual workflow.	4 / 5
Progressive Disclosure	The skill references 'references/hierarchy.md' for expanded per-level guidance, which is good progressive disclosure in principle. However, no bundle files are provided, so this reference is unverifiable. Additionally, a significant amount of content that could be in the reference file (the full five-level overview, the rationale section) is inlined in the main SKILL.md, making it longer than necessary.	3 / 5
	Total	12 / 20 Passed

Description

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

This is a solid skill description that clearly communicates both when to use it and what methodology it applies. Its main strength is the explicit 'Use when' clause and the specific reference to atomic design methodology, which creates good distinctiveness. The primary weakness is that the concrete actions could be more specific — listing actual outputs or deliverables rather than abstract guidance verbs like 'guide' and 'decisions'.

Suggestions

Add more concrete action verbs describing specific outputs, e.g., 'Generates component hierarchies, produces naming conventions, creates composition diagrams' rather than just 'guide decisions'.

Include additional trigger terms users might naturally say, such as 'design system', 'component library', 'UI architecture', or 'component breakdown'.

Dimension	Reasoning	Score
Specificity	Names the domain (frontend UI component architecture) and describes the methodology (atomic design with atoms, molecules, organisms, templates, pages), but the concrete actions are limited to 'structuring or decomposing' and 'guide consistent component hierarchy, naming, and composition decisions' — these are somewhat abstract rather than listing specific deliverables or outputs.	3 / 5
Completeness	Clearly answers both 'what' (applies Brad Frost's atomic design methodology to guide component hierarchy, naming, and composition) and 'when' ('Use when structuring or decomposing any frontend UI into reusable components'). The 'Use when' clause is explicit and appears at the start with concrete trigger scenarios.	5 / 5
Trigger Term Quality	Includes good natural keywords like 'frontend UI', 'reusable components', 'atomic design', 'atoms, molecules, organisms, templates, pages', 'component hierarchy', 'naming', and 'composition'. Missing some common user phrases like 'design system', 'component library', 'UI architecture', or specific framework names that users might mention.	4 / 5
Distinctiveness Conflict Risk	The specific mention of Brad Frost's atomic design methodology and the five levels (atoms, molecules, organisms, templates, pages) creates a fairly distinct niche. However, there could be minor overlap with general frontend component architecture or design system skills.	4 / 5
	Total	16 / 20 Passed

Validation

100%

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 — 11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository: whimzyLive/nightshift-ai
Path: skills/atomic-design/SKILL.md
Commit: 7741177

Reviewed: 6 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.