Implement a new design
| ID | ap-implement-new-design |
| Kind | skill |
| Selection | optional |
| Category | Design / Creative |
| Targets | claude, codex, cursor |
Build a chosen visual direction, refine it through bounded fresh-context critiques, and verify the final interface.
When to use
Section titled “When to use”Use when you have a visual direction to build and refine, either as a static prototype or in your actual application.
How it is selected
Section titled “How it is selected”Optional. Select during initialization or when offered in an update, or install separately when you need it.
Install
Section titled “Install”agents-pack install ap-implement-new-design --dry-runagents-pack install ap-implement-new-design --yesHow to invoke
Section titled “How to invoke”Use ap-implement-new-design to build the selected editorial direction as astandalone static HTML prototype. Include mobile views and local demointeractions. Use at most two improvement rounds.Choose the output
Section titled “Choose the output”| Mode | When to request it | Result |
|---|---|---|
| Static prototype | HTML mockup, concept preview, or a Studio batch | A portable page or self-contained folder with local assets and draft design notes |
| Application | Build or change the actual site, or explicitly integrate a selected prototype | Implementation using the application’s framework, routes, components, and real behavior |
Choosing a favorite prototype does not switch modes. In prototype mode, edits
stay inside the concept directory and leave application files and root
DESIGN.md unchanged. Static output is checked for direct-file and offline use.
How refinement works
Section titled “How refinement works”The skill accepts a selected direction, references, an existing design system,
or a clear brief. If the direction is unclear, it explores options and asks for
a choice before changing the application. It uses ap-frontend-design for
implementation and ap-frontend-review for final checks when available.
When exploration supplies a creative packet, the implementation records and checks its content-native generator, first-viewport silhouette, type roles, probable generic fallback, explicit rejections, and connection to the primary product task before coding. The packet is binding unless it conflicts with legibility, accessibility, or working behavior.
Before screenshots are captured, the rendered design is checked after fonts load at desktop and narrow widths. Accidental text overlaps, near-tangencies, clipped glyphs, and heavy weights applied to too many roles are corrected while preserving any deliberate, readable overlap named in the direction.
Standalone defaults are a target of 8.5/10 and up to three improvement rounds after the initial build and assessment. Studio supplies its own remaining budget instead. Refinement stops when the target is reached, the budget is exhausted, or further changes bring no meaningful improvement.
Every assessment uses a new critic conversation with only the fixed brief, current visuals, role instructions, assessment prompt, and optional fixed references. Previous designs, feedback, scores, source code, and targets stay out of that context. See fresh critiques.
What the handoff tells you
Section titled “What the handoff tells you”Expect artifact or preview locations, significant refinements, the applicable visual verdict, rounds used, stopping reason, and separate functional check results. If final edits invalidate the last visual score and no assessment budget remains, the final appearance is reported as unassessed.
If isolated visual critique is unavailable, authorized implementation and available checks can continue, with independent critique marked incomplete. An explicit freeze makes later checks audit-only, including reporting any remaining functional defects. Deployment is a separate action.