Skip to content
cccskills
FreePublished on GitHubEnglish overview

directions-lab

Create a design directions lab that compares shipped UI with two or three alternative designs across the feature’s surfaces. It scaffolds shared controls for themes and animation, adds the lab to the design proposals Storybook directory, and provides steps to build and verify it.

OriginalShow the original description

Scaffold a directions lab that shows shipped UI (Today) beside 2-3 design directions, with surface tabs, theme and animation toggles and the V1 MVP hover motion, registered in design-proposals Storybook. Use for a directions page or lab, or to explore design directions next to production.

paperclipai/paperclip108,541 stars(GitHub 108,541 + cccskills 0)
Works withVercel

Run score Not tested

See how to install

Good for

  • Comparing design alternatives with the shipped interface
  • Creating a page to review directions across multiple UI surfaces
  • Scaffolding a design lab for a feature
  • Registering design proposals in Storybook

Overview

What it does

This skill creates a design lab for a feature, showing the production UI alongside two or three design alternatives. The generated page includes tabs for the places where the feature appears, controls to switch themes and animation, and an overview of the alternatives. It also registers the lab in the Storybook design proposal catalog. The production UI is displayed with the actual components and serves as the comparison baseline. After generating the lab, the skill builds out its structure, data, and design alternatives in stages, then runs checks such as tests and a build. Captured images can be attached for review and are kept out of the repository.

When it helps

Use it to compare implemented UI with new proposals under the same conditions, or to share design exploration across several screens. It is also useful for teams that want a review entry point where people can inspect the look and motion of each proposal.

Example requests

  • “Create a lab for this feature that compares the production UI with three design proposals.”
  • “Make a page to compare design proposals for each screen where this feature appears.”
  • “Register the generated design lab in Storybook and proceed with the checks.”

Notes

The source instructions refer to the target repository’s UI structure and feature map, and use Vite, Storybook, and a test environment. The project’s development environment is needed for checks after generation.

This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.

Document check

AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).

SafetyAre sending data, deleting files, and running commands disclosed?
AGoodIt specifies rollback on failure and keeps captured images out of the repository.
Easy setupDoes it need few tools or API keys, and are they documented?
BPartly lackingIt depends on the repository UI, Vite, Storybook, and a test environment.

Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 27, 2026. Treat it as a guide and read the original before installing.

Disagree? Request a re-evaluation

Tell us which point is wrong and why. No login needed. We will check it against the SKILL.md, redo the evaluation, and show the result here.

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

Files included (70)

  • SKILL.md15.4 KB
  • agents/openai.yaml291 B
  • assets/motion/v1-mvp-motion.css787 B
  • assets/PRECEDENT187 B
  • assets/templates/api-routes.ts.mjs531 B
  • assets/templates/api-stub.ts.mjs1.9 KB
  • assets/templates/build-info.ts.mjs220 B
  • assets/templates/define-lab.ts.mjs3.9 KB
  • assets/templates/direction/index.tsx.mjs445 B
  • assets/templates/direction/MotionSpecimen.tsx.mjs2.3 KB
  • assets/templates/direction/SlotBody.tsx.mjs521 B
  • assets/templates/direction/tokens.css.mjs1.1 KB
  • assets/templates/entry.html.mjs752 B
  • assets/templates/fixtures.ts.mjs1.2 KB
  • assets/templates/frames/AppShell.tsx.mjs5.2 KB
  • assets/templates/frames/Board.tsx.mjs4.8 KB
  • assets/templates/frames/LabToolbar.tsx.mjs4.4 KB
  • assets/templates/frames/Slot.tsx.mjs329 B
  • assets/templates/frames/SurfaceFrame.tsx.mjs1.3 KB
  • assets/templates/frames/SurfaceView.tsx.mjs540 B
  • assets/templates/kit.ts.mjs1.9 KB
  • assets/templates/lab-state.ts.mjs1.8 KB
  • assets/templates/lab.css.mjs74 B
  • assets/templates/launch-entries.json.mjs680 B
  • assets/templates/main.tsx.mjs6.2 KB
  • assets/templates/providers.tsx.mjs920 B
  • assets/templates/registry.ts.mjs1.6 KB
  • assets/templates/shot.cjs.mjs10.0 KB
  • assets/templates/stories/compare.stories.tsx.mjs3.4 KB
  • assets/templates/tests/api-stub.test.ts.mjs1.6 KB
  • assets/templates/tests/lab-state.test.ts.mjs3.1 KB
  • assets/templates/tests/motion-contract.test.ts.mjs5.7 KB
  • assets/templates/tests/registry.test.ts.mjs2.5 KB
  • assets/templates/tests/today.test.tsx.mjs2.0 KB
  • assets/templates/today/adapters.ts.mjs748 B
  • assets/templates/today/index.tsx.mjs387 B
  • assets/templates/today/SlotBody.tsx.mjs972 B
  • assets/templates/vite.config.mjs.mjs2.9 KB
  • evals/asks-how-many-directions/case.yaml343 B
  • evals/asks-how-many-directions/graders/01-expected-output.md347 B
  • evals/asks-how-many-directions/prompt.md197 B
  • evals/multi-surface-three-directions/case.yaml674 B
  • evals/multi-surface-three-directions/graders/01-expected-output.md672 B
  • evals/multi-surface-three-directions/prompt.md510 B
  • evals/single-surface-two-directions/case.yaml398 B
  • evals/single-surface-two-directions/graders/01-expected-output.md397 B
  • evals/single-surface-two-directions/prompt.md284 B
  • references/canonical-directory.md15.5 KB
  • references/design-proposals-storybook.md29.2 KB
  • references/drawing-phases.md21.7 KB
  • references/generator.md25.7 KB
  • references/lab-anatomy.md28.7 KB
  • references/lifecycle.md18.9 KB
  • references/motion-spec.md21.1 KB
  • references/questions-and-defaults.md15.6 KB
  • references/repo-gates.md20.8 KB
  • references/today-fixtures-and-build.md34.9 KB
  • scripts/lib/args.mjs2.4 KB
  • scripts/lib/capabilities.mjs2.1 KB
  • scripts/lib/check.mjs10.6 KB
  • scripts/lib/context.mjs8.6 KB
  • scripts/lib/modes.mjs1001 B
  • scripts/lib/ports.mjs1.9 KB
  • scripts/lib/registry-edit.mjs5.2 KB
  • scripts/lib/render.mjs3.6 KB
  • scripts/lib/shared-files.mjs2.9 KB
  • scripts/lib/verify.mjs1.8 KB
  • scripts/lib/write.mjs2.3 KB
  • scripts/scaffold.mjs14.3 KB
  • scripts/scaffold.test.mjs33.7 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Directions lab

A directions lab is how design explorations are made in this repo: one page, one feature, Today plus two or three directions, every surface the feature appears on, and the same controls every time, so a shared link reads the same to everyone. The artifact directions lab (ui/src/artifact-directions) is the precedent and stays the frozen reference; this skill generates new labs in the same shape without redrawing the plumbing by hand.

What you are making

  • The page. ui/<slug>-directions.html plus ui/src/<slug>-directions/, a second Vite entry with no backend. All state lives in the URL (?d=&s=&theme=&chrome=&anim=, plus proposal=1 for the proposal palette). A registry module is the single source for the direction ids, digit keys, labels, surfaces, landing view and story id; the toolbar, keyboard, overview board and capture script read it at runtime, and add-direction keeps the story's per-direction export in step, so a direction is one registry entry plus one directory.
  • The toolbar. Row 1 is the directions row: the numbered directions then 0.Today last, as a segmented control, with Theme and Animation right-aligned. Row 2 is the surfaces row: Overview plus one tab per surface. Row 2 is written only when the lab is scaffolded with more than one surface (a surface added later to a one-surface lab needs row 2 by hand, references/lab-anatomy.md section 8); with one surface the keyboard legend joins row 1. Nothing else goes in the header.
  • Today. Always present, always 0.Today, always the shipped components mounted on the lab's fixtures through small adapters and a fetch stub. It is the control every direction is judged against, so it is never a redraw.
  • The directions. Two or three, numbered, each a self-contained kit directory with its own scoped tokens.css. Every direction carries the V1 MVP motion block verbatim and a test that proves it, so hover feels the same across labs. Read references/motion-spec.md before touching any of it.
  • The directory entry. One story file under ui/storybook/stories/design-proposals/ with a stable id, catalogued as a proposal. The design-proposals Storybook is becoming the canonical directory of the design system; a lab exists there from its first commit.

Hard rules, because the repo's gates enforce them and reviewers expect them: no code comments in anything you commit, no file of 600 lines or more in a lab (check refuses at 600), no package.json script, no lockfile change, no screenshots or generated catalog files in the repo.

Before you start

Run from the repo root on a branch of your own (claude/<slug>-directions, from origin/master). Check that ui/node_modules/.bin/vite exists; if not, pnpm install --frozen-lockfile. Then run the generator's own tests:

node --test .agents/skills/directions-lab/scripts/scaffold.test.mjs

Red here usually means a template or the motion asset has drifted from the precedent (ui/src/artifact-directions/directions/d5-v1-mvp/tokens.css); two cases also read the real feature map and the catalog script, so a changed feature-map row or catalog message shows up here too. Fix the generator before scaffolding anything; a lab built on a stale template fails later in ways that look like your drawing.

Read the brief, then ground the subject

Extract four things from what Tonio wrote: the subject (its slug and title), the places it appears (one surface per place), a stated count or names of the directions, and any flag or component names. Then look at the code before you ask anything:

rg -l "<Subject>" ui/src/components ui/src/pages
rg -n "<subject word>" maps/feature-map/*.md

The first grep gives the component files, the flag hook (use<Feature>Enabled), and, by following useQuery/queryFn into ui/src/api/*, the /api/ routes Today must answer. The second gives the capability ids the story cites. This grounding is what makes the surfaces question specific instead of generic. references/questions-and-defaults.md has the full extraction and derivation tables.

Ask, in one call

Ask at most two questions, in a single AskUserQuestion call, and skip each one the brief already answers:

  1. How many directions? Options 2 and 3. Say in the question that three unnamed directions scaffold as 1.Refine (tokens and spacing, same structure), 2.Rework (new components, same layout) and 3.Rethink (new layout), two as 1.Refine and 2.Rethink, and are renamed later. Skip when the brief states a count or names the directions.
  2. Which surfaces? Multi-select from the usage sites the grep found, plus "only one place". Two or more selections produce the surfaces row. Skip when the brief names the places.

Never ask about theme, animation, Today, ports, the slug or the landing view; those are fixed by the skill. When no question can be asked (a headless run), write this before doing anything else, then proceed: "Defaulting to three directions and one surface (<surface>) because I cannot ask; change later with scaffold.mjs add-direction."

State what you derived, then scaffold

Before running the generator, state every derived value in your reply: slug and title, each surface as id:Label:width@nav with the line the width comes from, the direction count and names, the group, the capabilities with their feature-map rows (or [] and the exception sentence), the flag hook and the /api/ paths Today will need. A wrong slug or capability is cheap to catch here and expensive after files exist. Then:

node .agents/skills/directions-lab/scripts/scaffold.mjs new \
  --slug composer --title "Composer" \
  --surfaces thread:Task-thread:960@tasks,panel:Right-panel:434@tasks \
  --directions 3 --dry-run

Read the plan (paths, ports, cells, story), drop --dry-run, and run it. new renders everything in memory, refuses existing paths, writes the lab, the html entry, the Vite config, the story file, two .claude/launch.json entries and one .gitignore line, then verifies: the Storybook catalog check, the lab's own Vitest files, and a Vite build. On any failure it deletes what it wrote and restores the two shared files, so a half-written lab never breaks pnpm test or tsc -b for the whole repo (ui/vitest.config.ts has no include filter and ui/tsconfig.json includes all of src). Quote the --json output in your reply.

--surfaces takes id:Label:width@nav per place, where nav is the sidebar item the shell highlights (tasks, artifacts or other) and the width is the product's own constant for that place (see references/questions-and-defaults.md). Flags you will use: --names a,b,c for stated names, --group Components|Pages|Layouts|Patterns (Components when the grep hits ui/src/components), --capabilities area/key,... (validated against maps/feature-map; omit for [] plus an exception sentence), --company name:PREFIX (default acmehats:ACM), --landing auto|all|today|<id>, --ports dev,preview (the generator picks free ones), --keep-on-failure to inspect a failed scaffold.

Look at it

Start the dev entry the generator added, preview_start {name: "<slug>-directions-dev"}, and open three URLs: / (the landing), /?d=today&s=<first surface> and /?d=<first direction id>&s=<first surface> (d1-refine when the directions are unnamed). Confirm document.documentElement.dataset.labAnim === "1", hover a motion specimen and watch the front rise and the two pages turn, press a, hover again and see only the fill change. Read the console for [<slug>-directions] unhandled lines: each one is a route Today will need. The overview board and the capture script never show the movement (iframes take no pointer; stills ask for reduced motion; --hover records one hovered frame, not the transition), so the transition is verified only this way.

Commit the scaffold, then draw

Commit the untouched scaffold first as feat(ui): scaffold the <title> directions lab. Reviewers then see the redraw as its own diff, not buried under plumbing. Draw in this order; references/drawing-phases.md has the done-when for each:

  1. Frames. Replace each data-lab-stub="frame-<surface>" region with the product chrome around that place: copy the product's class strings, freeze the registry width, reuse presentational primitives, let nothing scroll internally. The precedent frames show how (ThreadFrame, PanelFrame, GalleryFrame, AppShell).
  2. Fixtures and Today. Retype the per-surface data in kit.ts to the props each place receives, fill fixtures.ts, mount the shipped component in directions/today/<Pascal>Body.tsx (PascalCase of the surface id, so ThreadBody.tsx for thread) through adapters.ts, and register exactly the routes it fetches inside registerFeatureRoutes() in api-routes.ts. Today is done when it matches the product on the same data and its test passes with the real component.
  3. Directions. One at a time: replace the motion specimen with the drawing, keep the hook names (data-front on every treatment branch, data-rotate and data-spread with the inline base angle), put every raw value in that direction's tokens.css (light base, .dark override), and leave the motion block alone. Run scaffold.mjs check --slug <slug> after each phase.

Phase 2 comes before 3 because the slot props change shape in phase 2 and every kit follows the type.

Capture

node ui/src/<slug>-directions/shot.cjs --port <dev> --d all --out <scratch dir>

Captures are rest states at 1440×900, DPR 2, both themes; attach the PNGs to the PR, never to the repo. --hover adds a rest/hover pair per direction from a second browser context that allows motion; the browser pane with the Animation toggle on is still the only place to judge the motion itself.

Hand off

node .agents/skills/directions-lab/scripts/scaffold.mjs check --slug <slug> --strict --run

--strict refuses any remaining data-lab-stub marker; --run runs the lab's tests, the catalog check, the token gates, a Vite build of the lab and cd ui && pnpm typecheck, stopping at the first failure, and prints a ## Verification block whose Not run: lines name what stays manual (pnpm build-storybook, the repo-wide typecheck); --json returns the same results as data, with those items under notRun. Open the PR with every section of .github/PULL_REQUEST_TEMPLATE.md filled, the linked-issue path B with three filled feature-request labels, the story id, the launch entries and the Vercel alias if you deployed. Offer the DESIGN.md directory row as text in the PR body; never apply it from a lab PR.

If the skill itself is in your diff, force-add it: /.agents/ is git-ignored and the repo's tracked skills were added with git add -f.

Storybook and the design directory

new writes ui/storybook/stories/design-proposals/<slug>-directions.stories.tsx with meta id design-<slug>-directions, title Design proposals/<Group>/<Title> directions/Compare, a literal parameters.paperclip block (status: "proposed", home: "design-proposals", implementation: "prototype", boundary: "fixtures", capabilities, exception, notes) and stories Compare, Today, one per direction, and TodayProductionPalette (the decorator themes the whole iframe with the proposal palette; this one opts out so Today can be seen as shipped). The page itself renders the production palette by default; ?proposal=1 wraps it in the proposal theme for a side-by-side with the entry. The catalog script validates all of it at Storybook start, in cd ui && pnpm typecheck and in CI.

The lifecycle a direction moves through, and what to edit by hand at each step, is in references/lifecycle.md: proposed (what new writes), adopted (product code behind an experimental setting, with a feature-home story), current (flag removed), historical (retired with a replacement, moved out of the proposals folder keeping its id). Today the catalog forces every entry in the proposals folder to stay proposed; the governance change that would let the directory carry current entries is written up as paste-ready diffs in references/canonical-directory.md. Offer it once, as its own PR, only when Tonio says yes.

Later asks

  • Add a direction: scaffold.mjs add-direction --slug <slug> --name <Name> (next digit, registry entry, kit directory with the motion block and a specimen, the story's D<N> export, then check, rolling back on failure). The toolbar legend follows the registry at runtime. The generator refuses a fourth without --force-count, which also records allowMore in the registry; the story description's "1–N" sentence is the one thing to update by hand. Once phase 2 has retyped the slot props in kit.ts, add-direction refuses and prints the by-hand steps instead, because a generated kit would not fit the new props.
  • List labs: scaffold.mjs list.
  • Rename a direction, add a surface, or move a direction through the lifecycle: by hand, following references/lab-anatomy.md section 5 and 8 and references/lifecycle.md.
  • Publish: build with <SLUG>_DIRECTIONS_OUT_DIR=<dir>/paperclip-<slug>-directions, remove sw.js from the output, vercel deploy <that dir> --prod --yes from its parent; the basename names the project and the alias is the public URL. references/today-fixtures-and-build.md section 11 has the details.

Do not

  • Run two full ui Vitest suites at once; run the lab's files alone.
  • Land on d=all&s=board from a dev server with more than eight cells; use the static launch entry (<slug>-directions) for the full board.
  • Copy the artifact lab's html:not(.dark) token idiom; new labs put light values in the base block and dark ones under .dark [data-direction=…].
  • Edit the motion block in a lab. A different rise or fan is Tonio's decision.
  • Add comments, package.json scripts, lockfile changes, PAP ids or localhost URLs to anything that goes in the PR.

Maintaining the skill

The generator's templates were derived from the precedent at the commit recorded in assets/PRECEDENT. scripts/scaffold.test.mjs pins the generated structure and asserts the motion asset still equals the precedent's block after substitution; when the precedent changes, re-derive the template and bump the pin. references/generator.md explains the template conventions and the context object.

References

FileRead it when
references/questions-and-defaults.mdBefore asking; derivation tables, eval prompts as flag lines
references/lab-anatomy.mdDrawing frames or changing the toolbar, state or board
references/today-fixtures-and-build.mdMounting Today, the fetch stub, build, capture, deploy
references/motion-spec.mdAny hover motion; the per-direction checklist
references/drawing-phases.mdAfter the scaffold, phase by phase
references/design-proposals-storybook.mdThe story file, the catalog gate, the theme
references/lifecycle.mdAdopting, shipping or retiring a direction
references/canonical-directory.mdOnly when Tonio approves the governance PR
references/repo-gates.mdBefore the PR
references/generator.mdChanging the generator

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Add or extend Paperclip end-to-end evaluations that exercise real browser workflows across the server, database, and runner. Define expected outcomes, check independent evidence, and connect results to the existing reporting pipeline for local or Daytona execution.

  • Adding an evaluation for a complete user workflow
  • Updating test data and outcome checks
  • Including screenshots and artifacts in evaluation reports
paperclipai/paperclip108.5KUpdated Oct 29, 2026

add-runner-eval

FreeSummary

Add or extend Paperclip Runner evaluations that test real sessions against a mock control service. Define observable pass conditions, validate cases and run selections, and retain source revisions, evidence, and costs for authorized live runs.

  • Adding a focused Runner protocol evaluation
  • Testing grading rules with valid and invalid evidence
  • Updating evaluation selections and campaign membership
paperclipai/paperclip108.5KUpdated Oct 29, 2026

agent-browser

FreeSummary

Use a real browser to verify web pages and apps through short, supervised interactions. Capture screenshots, inspect errors and network requests, and document reproducible steps for UI bugs or expected behavior checks.

  • Capture screenshots to verify UI changes
  • Read content rendered by JavaScript
  • Reproduce UI bugs and record errors
paperclipai/paperclip108.5KUpdated Oct 29, 2026

agentmail

FreeSummary

Read email linked to assigned Paperclip tasks, send new messages or replies through an assigned AgentMail inbox, and check delivery outcomes. Follow task permissions and preserve retry identifiers to avoid duplicate sends.

  • Reading email context attached to an assigned task
  • Sending a new email from an assigned inbox
  • Replying to a specific message in a conversation
paperclipai/paperclip108.5KUpdated Oct 29, 2026

check-pr

FreeSummary

Inspect proposed changes in GitHub, GitLab, or Perforce for review feedback, failed automated checks, and incomplete descriptions. It separates actionable findings from informational or resolved comments, then helps fix issues and close addressed review threads when requested.

  • Inspect a change before submission
  • Identify failed checks and required fixes
  • Organize human and bot review feedback
paperclipai/paperclip108.5KUpdated Oct 29, 2026

company-creator

FreeSummary

Create an AI agent company or team package from an idea or an existing repository. Define roles, reporting lines, skills, and work handoffs, then generate structured files that follow the Agent Companies specification.

  • Build an agent company from an idea
  • Turn a repository into an agent team package
  • Define agent roles and work handoffs
paperclipai/paperclip108.5KUpdated Oct 29, 2026

See all skills by paperclipai

Report a problem with this skill