Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →asgeirtj/handoff-to-claude-code
Developer handoff package
Passed 12 of 17 test cases with the skill, and 7 of 17 without it.
and 7 more in the full report
8 fixed8 passed either way5 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
When preparing a developer handoff package for a confirmation modal design, should PNG screenshots of the rendered prototype be generated and bundled into the handoff folder upfront?
| Checked | Without skill | With skill |
|---|---|---|
| States that screenshots should not be included by default. | Passed | Passed |
| Inquires whether the user wants screenshots included after creating the initial handoff bundle. | Missed | Passed |
The instructions your model reads when the skill loads.
Create a comprehensive handoff package so a developer using Claude Code can implement this design in a real codebase.
Create a handoff folder in the project directory:
mkdir -p <project-folder>/design_handoff_<feature-name>/
Use a descriptive feature name derived from the design (e.g., design_handoff_onboarding_flow, design_handoff_settings_redesign).
Create a README.md in the handoff folder with the following sections:
# Handoff: <Feature Name>
## Overview
Brief description of what this design is for and what it accomplishes.
## About the Design Files
State clearly that the files in this bundle are **design references created in HTML** — prototypes showing intended look and behavior, not production code to copy directly. Explain that the task is to **recreate these HTML designs in the target codebase's existing environment** (React, Vue, SwiftUI, native, etc.) using its established patterns and libraries — or, if no environment exists yet, to choose the most appropriate framework for the project and implement the designs there.
## Fidelity
State clearly whether the mocks/prototypes created in this conversation are:
- **High-fidelity (hifi)**: Pixel-perfect mockups with final colors, typography, spacing, and interactions. The developer should recreate the UI pixel-perfectly using the codebase's existing libraries and patterns.
- **Low-fidelity (lofi)**: Wireframes or rough layouts showing structure and flow. The developer should use these as a guide for layout and functionality but apply the codebase's existing design system for styling.
## Screens / Views
For each screen or view in the design:
- **Name**: What this screen is called
- **Purpose**: What the user does here
- **Layout**: Detailed description of the layout (grid structure, flex directions, widths, heights, margins, padding)
- **Components**: List each UI component with:
- Position and size
- Colors (exact hex values if hifi)
- Typography (font family, size, weight, line-height, letter-spacing)
- Border radius, shadows, borders
test cases passed, vs 7 / 17 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.