design-handoff

Generate developer handoff specs from a design. Use when a design is ready for engineering and needs a spec sheet covering layout, design tokens, component props, interaction states, responsive breakpoints, edge cases, and animation details.

Quality

73%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./design/skills/design-handoff/SKILL.md

Quality

Content

61%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 well-organized and actionable for an instruction-only skill, anchored by a concrete output template. Its weaknesses are duplication between the "What to Include" checklist and the output template, and an implicit rather than explicitly sequenced workflow.

Suggestions

Collapse the overlap between "What to Include" and the "Output" template — e.g., keep the template as the single source of truth and reduce the checklist to only what the template does not already show (such as gesture support and international text).

Make the workflow sequence explicit at the top (1. resolve the design source from the Figma URL or description, 2. extract measurements/tokens/components, 3. fill the output template, 4. review for unspecified states and flag assumptions), so steps are stated rather than implied by section order.

Add one concrete instruction for the Figma branch (what to pull and how to map it to template fields), since the current "Pull the design from Figma" leaves the retrieval step to guesswork.

Dimension	Reasoning	Score
Conciseness	The "What to Include" checklist and the "Output" template substantially duplicate each other (states, edge cases, accessibility, and breakpoints each appear in both), so the body could be meaningfully tightened. Otherwise it is lean with no over-explanation of known concepts, fitting the 3-anchor better than the minor-trimming 4-anchor.	3 / 5
Actionability	For an instruction-only skill the guidance is concrete: a complete output template with table schemas, token examples ("color-primary \| #[hex] \| CTA buttons"), and worked principles ("Reference `spacing-md` not `16px`"). Minor gaps — e.g., no concrete steps for pulling data from Figma — keep it below fully executable.	4 / 5
Workflow Clarity	The sequence (usage → Figma-or-description source → generate sections → output template) is implicit in section order rather than explicitly stated, and there are no checkpoints. The operation is non-destructive so the destructive/batch cap is not triggered, but it fits the 3-anchor (steps present, checkpoints missing or implicit).	3 / 5
Progressive Disclosure	A self-contained, well-sectioned single file with one clearly signaled one-level-deep reference ([CONNECTORS.md](../../CONNECTORS.md)) — appropriate for a skill this size. Minor gap: the ~50-line output template could be moved to a reference file, keeping it at 4 rather than 5.	4 / 5
	Total	14 / 20 Passed

Description

75%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 description with a concrete action, explicit use-when guidance, and a well-defined niche. Its main gaps are missing user-voice trigger synonyms (Figma, mockups, redlines) and a condition-based rather than utterance-based when-clause.

Dimension	Reasoning	Score
Specificity	"Generate developer handoff specs from a design" names a concrete action, and the enumerated deliverable coverage ("layout, design tokens, component props, interaction states, responsive breakpoints, edge cases, and animation details") is specific. It describes one main action with detailed scope rather than the multiple distinct actions of the 5-anchor, placing it at 4.	4 / 5
Completeness	Both parts are present: a clear what ("Generate developer handoff specs from a design") and an explicit when ("Use when a design is ready for engineering and needs a spec sheet covering..."). It falls short of the 5-anchor because the when-clause states a condition rather than concrete user-utterance trigger phrases ("or when the user mentions X").	4 / 5
Trigger Term Quality	Good natural keyword coverage: "design", "developer handoff", "spec sheet", "engineering", "design tokens", "responsive breakpoints". A few natural terms users would say are missing ("Figma", "mockups", "redlines", "UI"), so it matches the 4-anchor (good coverage, a few missing) rather than the comprehensive 5-anchor.	4 / 5
Distinctiveness Conflict Risk	"Developer handoff specs from a design" is a clear niche with distinct triggers (design ready for engineering, spec sheet), giving minimal conflict risk with unrelated skills. Only minor overlap risk with general design-generation or documentation skills keeps it at 4 rather than 5.	4 / 5
	Total	16 / 20 Passed

Validation

87%

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 — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning
relative_links	Relative link issues: 1 suspicious	Warning

	Total	14 / 16 Passed

Repository: anthropics/knowledge-work-plugins
Path: design/skills/design-handoff/SKILL.md
Commit: 8444efc

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.