Design Studio

Use ap-design-studio to turn a brief into several complete designs you can open, compare, and share with your team. It deliberately pushes exploration past the model’s safest visual answer, then uses the individual implementation, critique, polish, and review components to develop each direction. You can also run every step yourself.

Shoutout: The original spark for this workflow came from Anshu Chimala (@anshuc) and his article How to turn your AI into a world-class designer. Agents Pack adapts those ideas into a portable workflow for Claude Code, Codex, and Cursor.

Design Studio was introduced in Core 0.31.0. Core 0.31.1 adds the originality methods and typography safeguards described below. Upgrade to CLI 0.3.0 for category selection in setup and updates. See Upgrade the CLI.

Start with one request

Once the components are installed, ask your coding agent:

Use ap-design-studio to create three distinct designs for our project
management homepage. Keep our logo and approved copy, and make the primary
task of finding the next project obvious. Avoid the rounded-card layouts and
blue-purple palette from our previous attempts. Build static HTML pages with
mobile views and package them for team review.

The default is three completed static HTML concepts. “Create five designs” means five built prototypes. Each follows the same product brief and comparable content and page coverage, while exploring different visual ideas.

You do not need special argument syntax. Add your audience, references, brand constraints, exclusions, output location, count, and any desired checkpoints in ordinary language:

Use ap-design-studio for four concepts of our museum membership page.
Keep the current logo, use the supplied photographs, avoid gradients,
and limit the work to the homepage and its mobile layout.

If you want to choose ideas before pages are built, say so:

Use ap-design-studio to explore six directions. Show me the ideas and let
me choose two before building the HTML prototypes.

Otherwise Studio continues from exploration into building every requested concept, then pauses for your taste and preference after you can see the pages.

How Studio escapes the default design

Exploration no longer hands implementation a loose mood description. Each direction becomes a creative packet with enough constraints to recognize when the implementation has drifted back toward a generic template.

Every packet includes:

the primary product job that originality must not overpower;
a content-native generator—a relationship from the actual subject, such as evidence and conclusion or prediction and correction, that organizes the page;
the model’s probable default answer and the familiar fallbacks to reject;
binding composition, typography, color, imagery, interaction, and mobile contracts; and
visible acceptance checks for the finished prototype.

For a three-concept run, Studio prefers a different originality method for each direction when the task supports it:

Method	How it creates distance from the obvious answer
Binding art direction	Translates a coherent physical, cultural, or media world into layout and behavior without hiding the product’s main task
Reference collision	Combines structural principles from two or three distant reference worlds while rejecting their literal motifs
Anti-convergence	Names patterns overused in prior attempts and replaces them with content-specific composition, type, color, and interaction choices

Reference-collision and anti-convergence directions sketch more than one composition in words, then discard or materially revise the first safe answer. The goal is not to make every option strange or maximalist. A restrained design can pass when its proportions, typography, structure, and content relationships make it specific to the product.

Studio also isolates execution. Each concept gets its own implementation conversation with the shared product brief and only that concept’s packet and necessary assets. It does not see sibling designs, screenshots, or rationale when isolated dispatch is available. This reduces anchoring between concepts; if the runtime cannot provide that isolation, Studio reports the limitation.

Availability and setup

All seven design components are optional and target Claude Code, Codex, and Cursor. Installing Studio alone does not install the other optional components. For the complete workflow, use:

Component	Role
ap-design-studio	Coordinate the process, budgets, handoffs, and final selection
ap-explore-design-directions	Produce binding creative packets with varied originality methods
ap-implement-new-design	Build each direction and run bounded critique and refinement
ap-design-critic	Give independent visual assessments in fresh conversations
ap-design-polish	Remove clutter and refine the chosen identity
ap-frontend-design	Implement the visual design
ap-frontend-review	Verify rendered appearance and working behavior

Ask the management skill to inspect your available pack before installing:

Use ap-manage-agents-pack to check whether my available pack contains
ap-design-studio, ap-explore-design-directions, ap-implement-new-design,
ap-design-polish, ap-design-critic, ap-frontend-design, and ap-frontend-review.
Install the missing components that are available for my selected agents,
then report anything still missing.

For a new installation, choose Recommended and add Design / Creative and Design / Critique in the optional-category menu, plus ap-frontend-design and ap-frontend-review under Engineering / Frontend. For an existing installation, run agents-pack update and select those categories when offered.

The frontend design and review skills are optional. If they are missing, add them separately; the update menu only offers newly introduced components. You can also include all seven IDs with update --add in one operation.

For a manual availability check:

agents-pack list --available

The component pages show individual install commands. Update older packs to Core 0.31.1 before installing the design components. See Install and remove components and Update, pin, and roll back for pack management.

The agent also needs a way to render the pages, capture screenshots or frames, and launch a visual-capable critic with no inherited conversation. Installing the role’s instructions does not add those runtime capabilities. If something is missing, Studio reports the exact limitation and completes the stages it can. If the main implementation skill is missing, it can deliver available creative packets and explain what is needed to continue. It does not call self-review an independent critique.

What happens during a run

Create creative packets. Exploration assigns varied originality methods, content-native generators, visual contracts, and explicit fallback patterns to reject.
Build and refine each concept in isolation. Its implementer receives the common product brief and one packet, passes an originality gate before coding, builds the static HTML, and captures comparable desktop and mobile views. Fresh critiques guide a limited number of revisions.
Polish. The polish skill removes unnecessary treatments and tightens craft while preserving each concept’s character and useful controls.
Verify and assess the final result. Frontend review checks the final prototype. If polish or repairs changed its appearance, a fresh critic assesses the current visuals within the remaining budget.
Package and choose. Studio provides the concepts, comparison gallery, concise differences, verification results, and remaining gaps. You choose a direction or request combinations or further refinement.

The workflow reuses the specialists’ instructions. Its defaults and handoffs keep the work bounded; it does not start a new implementation loop after polish.

Typography is checked as a system

Design tension is allowed; accidental damage to readability is not. Before a prototype is captured, and again during critique, polish, and frontend review, the workflow checks typography after the intended fonts load and at desktop, mobile, and relevant transition widths.

It looks specifically for:

clipped glyphs and line boxes;
text blocks that overlap or almost touch by accident;
deliberate overlaps that stop being readable after responsive reflow or longer content; and
headings, labels, navigation, buttons, and metadata all using heavy weights and therefore competing at the same level.

An overlap can remain when the creative packet names it as a signature device, it is easy to read, and it adapts intentionally at every inspected width. For ordinary hierarchy, the workflow prefers scale, spacing, position, color, case, and style before adding another bold role.

Every critique starts fresh

Each concept and each assessment gets a new critic conversation with no inherited history, including retries and final assessments. Reusing a critic or asking it to forget previous work does not meet this requirement. Neither does creating a new agent ID that inherits the parent conversation.

The critic receives only its role, the fixed assessment prompt, that concept’s stable brief, current screenshots or frames, and optional fixed reference images. It does not receive previous versions, other concepts, the gallery, earlier feedback or scores, source code, implementation rationale, targets, or remaining budget. The implementing agent keeps the progress record and decides which changes fit the brief.

This lets the critic judge the current design without being led toward the previous criticism or a desired grade. A contaminated assessment must be repeated with a clean dispatch; if that is impossible, the limitation is reported and independent critique stays incomplete.

An explicitly requested side-by-side comparison is available as a separate critic task. It is not a fresh assessment inside the refinement loop.

Limit	Studio default, per concept
Initial result	One complete build and assessment
Critique-driven revisions	Up to two rounds, targeting 8.5/10
Final polish	One pass, followed by verification
Valid visual assessments	At most four, including a final assessment if the appearance changed

Standalone ap-implement-new-design instead defaults to up to three improvement rounds after its initial build and assessment. Studio passes its own budget to that skill. The defaults are not added together.

Refinement stops at the target, the cap, or when further feedback offers no meaningful improvement. An unchanged page is not rescored just to get a better number. Scores are subjective design judgments, not a guarantee of quality or a substitute for your taste. Functional verification is reported separately. The polish skill’s AI-tell score measures subjective genericness or overdesign; it is not evidence of AI authorship and is separate from the critic’s quality score.

Be explicit when a budget should cover the entire batch:

Create three concepts with at most three refinement passes in total across
the whole batch, including polish. Tell me how you will allocate them.

An explicit total is shared across concepts. It is not multiplied by the number of designs. With zero refinements, Studio completes the initial build and checks, then freezes the prototypes. Later polish and review are audit-only and report remaining defects, including functional ones, without changing the frozen output.

Studio uses a new output directory outside the application’s source, build, and public directories. Unless the project has an existing artifact convention, it uses design-prototypes/<unique-run>/. Each concept has its own index.html and any local assets. Prototype design notes stay with that concept, leaving the real application’s source, configuration, dependencies, and root design documentation unchanged.

You receive:

A gallery index.html with relative links, neutral descriptions, and previews when available.
Each concept as a standalone HTML file or self-contained folder.
A ZIP containing the gallery and required assets when the result spans files.
Opening instructions, demo-only behavior, verification results, and limitations.

The pages should open directly from the filesystem and work offline without installing dependencies, running a build, or connecting to a backend. Fonts, images, and other required assets are embedded or bundled with relative paths; remote CDNs, external fonts, and a running localhost server are not required. Studio checks direct-file opening and a copied or extracted package when tools permit, and reports any portability checks it could not perform.

Buttons, forms, and data in prototypes demonstrate the intended experience. They do not make real submissions or payments. Internal critique history and unrelated repository files are excluded from the sharing package. Studio prepares the files for you; sending them to teammates or publishing them requires your instruction.

Run the steps manually

Use the individual components whenever you want more control over the sequence.

First, request ideas and choose a direction:

Use ap-explore-design-directions to create five creative packets for our
homepage. Keep the current logo. Stop before implementation so I can choose.

Then build your selection:

Use ap-implement-new-design to build direction two as a static HTML prototype.
Use the typography from direction one and keep the motion subtle.

After reviewing the result, polish it:

Use ap-design-polish on that prototype. Keep its editorial identity and
remove competing decoration. Verify desktop and mobile behavior afterward.

You can request an audit-only polish, launch ap-design-critic for fresh visual feedback, or use ap-frontend-review for a focused rendered and functional review. Running exploration alone stops at the creative packets; it does not silently start Studio or build pages.

Bring your choice into the actual product

“I love concept two” selects a direction. To implement it in the application, give that instruction explicitly:

Implement concept two into our actual site, with the typography from concept
one. Use our existing components and real signup flow. Preserve the prototypes
as references.

Studio then uses ap-implement-new-design in application mode. The agent adapts the chosen design to the real framework, routes, components, and design system, replaces demonstration behavior with product behavior, and runs the application checks. A prototype is a visual reference for that work. Integration does not automatically deploy the site.