Working prompts for designing with AI.

Interrogate this codebase and map what's already available to
show in the UI but isn't surfaced today: capability metadata,
parameter and schema descriptions, categorization, connection
and execution state, health and status. For each one, tell me
where it lives and what it would take to expose. Cite the
files so I can read them myself.

Inventory every action a user can take on this object, and
where each one is exposed today. Group them by what they
actually do, and flag the duplicates and the outliers:
actions that appear twice, or that don't belong with the
rest. Don't propose a redesign; just make the overlaps easy
to see.

Crawl the full documentation tree and inventory every page:
URL, title, and what it covers. Cluster the pages by topic,
and surface the overlaps, the orphans, and anything filed
under the wrong group. Propose a few candidate groupings for
me to react to. The call on entry points and category names
stays with me.

Audit the production component library. For each primitive in this
explorer (button, input, select, table, tabs, dialog), name the
production component it maps to and the props that would carry
over. Output a table I can drop into the status board, and cite
the files so the front-end team can read them.

Crawl every component file in the repo. For each, extract path,
name, exported props, which token and framework imports it uses,
and how many other files import it. Classify by function (layout,
data-display, input, feedback, navigation, domain) and flag likely
duplicates where several components solve the same problem (multiple
table, dialog, or button architectures). Output one machine-readable
inventory file. Read-only; change nothing.

Using the inventory as reference, scan every real usage of one
component type (say, all table and data-grid variants). Treat them
as evidence, not code to port. Note repeated structures, drift, and
duplicated wrapper layers, and inconsistency in spacing, density,
empty and loading states, filters, pagination, selection, row
actions, and errors. Assign ownership by layer: base mechanics,
styling and defaults, toolbar and states, product data. Then define
one harmonized target model, with parity notes on what's real,
what's mocked, and what's unresolved.

Scan the listed channels and trackers for all feedback about the
feature. Compile it into one document, external feedback first, then
internal. For each item capture who, where, when, a verbatim quote,
and a one-line takeaway. Separate UX problems from technical bugs and
genuine feature requests. Build a recurring-patterns table mapping
each pattern to who reported it, and close with the highest-leverage
takeaways for the redesign. Flag any attribution you can't confirm
rather than asserting it.

This page is generated by an upstream tool and synced into the repo,
so per-file edits get overwritten. Read a few representative examples
and document the page anatomy section by section, in render order.
Then identify every layer a change could live in: the upstream
generator (durable, cross-team), your own theme/component layer
(uniform presentation, no source edits), and per-file edits
(throwaway). Tag each proposed improvement with its layer and flag
cross-team dependencies. Recommend prototyping in the layer you fully
control first.

Onboard me to this repo without breaking anything. The setup steps I
was given may be for a different project. Read the README and any
AGENTS/CONTRIBUTING/style files and report the real toolchain, install
command, dev-server command, and build and lint checks. Infer the
branch-naming convention from git history. Flag any mismatch between
the instructions I was given and what the repo actually uses. Confirm
with me before running anything that could affect the main build.

Audit this feature's components for structural UI colors set with
primitive palette references (like grey[500]) or raw hex, and produce
a migration map to our semantic tokens. For each instance, propose the
semantic token matching its role (body text, secondary text, border,
surface, active icon). Keep status and data-encoding colors (risk,
pass/fail, added/removed) on primitives, and say so. Output a table of
file, line, current value, proposed token, and usage, plus which files
can drop the primitive import entirely.

Evaluate the current UI foundation and answer three questions directly.
One: is the component-catalog tool actually valuable at its current
coverage, and what coverage would make it a source of truth rather than
reference. Two: if starting over, would you still choose the current
framework, naming what it gives you for free (data grids, date pickers,
accessibility, theming) against its costs. Three: locate the real
problem, the framework or the number of abstraction layers stacked on
it. Recommend consolidate-in-place versus rebuild, with the migration
cost of the existing components as the deciding factor.

I'm redesigning a page type on our site. Identify three to five leading
products with an equivalent page and do a teardown of each: the layout
pattern, how they handle metadata, examples, and calls to action, with
a public source cited for each claim. Then rank the transferable
patterns in a table by three axes: readability impact, AI-readiness
impact, and disruption to our current page. End with a recommended
direction framed as an evolution of our existing page, and name
explicitly which patterns are too disruptive to adopt now.

Read the existing system and list every component, endpoint,
and pattern I could reuse. Then, for each proposed feature,
tell me what it actually needs to ship: frontend only, or
backend, data, or another team. Tag each as MVP or later, and
flag your confidence so I know which estimates to check by
hand. Do the analysis; leave the final cut to me.

Sweep the issue trackers for everything touching the feature. Filter
to UX and interaction problems and exclude logic, ingestion, and pure
data bugs. Produce a table of interface issues (issue, who filed it,
state, the UX problem in one line). List borderline items separately
with a one-line rationale for triaging each as technical rather than
interface. Note any access limits that constrained the sweep so the
gaps are visible.

I want to move this prototype from its current environment to another.
Answer whether it's feasible before writing any code. Explain what
carries over cleanly, what would need mocking or reimplementation, and
what accuracy we'd lose by leaving the environment where it renders
with the real design system. Lay out the options in a table with pros
and cons, including a lightweight fallback like a static HTML snapshot,
and note which interactive behaviors would break in each. Recommend,
then wait for my call.

Here is the happy-path design and the data contract behind it.
Enumerate every state this mockup doesn't show: loading, empty,
error, a partial response, a check still running. Then the
content extremes: a title too long to fit, a change with a
dozen contributors, a name that overflows its column. For each
one, tell me what the interface should do.

Read the pattern doc's composition-rules section and draft a
structured rule entry for it: required components, optional
components, composition order, and allowed semantic colors. Keep
every rule traceable to a line in the pattern doc; invent no
constraints. Output the draft entry only, ready for review. Don't
write it into the canonical ruleset yet.

From the attached feedback and research, draft an epic to improve the
feature. Include a two-to-three-sentence business goal (problem, for
whom, why now), an outcome statement describing the end state (not the
solution), outcome-oriented acceptance criteria, an explicit
in-scope/out-of-scope split, and sub-issues each tied to the feedback
that motivates it. Add an open-questions section that surfaces
ambiguity and conflicting input instead of guessing, each with an
owner and a decision point.

This action menu mixes controls that operate on different objects, so
users can't tell what each acts on. Reorganize the actions into groups
by target scope: feature-level (open, create, import, manage),
current-item (edit, configure, undo), and workspace-level. For each
action, state which object it operates on and which group it belongs
to. Call out any action whose scope is ambiguous today and recommend
where it should land, so the grouping resolves the mental model rather
than just relabeling it.

This editor silently drops user input on format problems (say, an
off-by-one indentation) and shows no error or a misleading one. Design
an honest validation and error surface. Enumerate the failure cases
users actually hit, and for each specify what the input does today
versus what it should do: what gets validated, when, and the exact
message and recovery guidance. Prefer preserving the user's input and
pointing at the specific problem over discarding it silently. Make sure
no path can fail without visible, accurate feedback.

Write a frame-only (UI, no backend) spec for this page for the
front-end team. First document what the upstream generator hardcodes
(section order, available fields, component output), so we know what
can't change without upstream work. Then define v1 scope in
risk-ordered lanes: pure CSS/presentation, layout via component
override, and any net-new small front-end pieces. State plainly what
v1 can't do and why it's deferred. Close with concrete feasibility
questions for engineering and a backlog of content changes to propose
upstream.

This component file has grown to hold many sub-components, constants,
helpers, and inline types. Plan a split into feature-scoped modules
matching our naming conventions (.component, .helpers, .types) and
code style, keeping all changes inside the feature's folder and the
external import path unchanged. Propose the target file structure,
assign each piece to a file, and give a leaf-first execution order that
avoids breakage. Map shared dependencies and confirm there are no
circular imports. Don't write code yet; produce the plan first.

# Portfolio charter (excerpt)
Never publish: source code, internal screenshots, non-public
metrics, roadmaps, customer or employee names, internal docs.

Transform rule (specific becomes general):
  "Project Atlas"     ->  "an internal platform initiative"
  "cut latency 42%"   ->  "a meaningful performance gain"
  a real screenshot   ->  a recreated conceptual sketch

Public Test: would my manager, legal, a future employer, and
the original company all agree this shows my contribution
without exposing IP? If unsure: generalize, abstract, or cut.

You are a portfolio editor working under the charter above.
Input: my private notes for one project.
Draft a case study answering, in order: problem, why it
mattered, constraints, my role, options, tradeoffs, how
UX/engineering/business intersected, how AI was used, what I
learned, the outcome.

Rules:
  - Generalize every specific per the transform rule.
  - Invent no metrics. Use relative outcomes only.
  - Generate diagrams as code; never describe a real screen.
  - Raise anything you are unsure about for my review. Do not
    decide it yourself.

Design an in-canvas empty state to replace the first-run modal, which
duplicates actions already in the page header and must be dismissed on
every reload. Specify the trigger (render when nothing is loaded) and
reuse the existing centered empty-state primitive. Define its icon,
headline, a one-sentence body, and exactly two actions: a primary
"create new" and a secondary "import." Deliberately leave recents and
manage out to avoid re-bloating the state, and explain that choice.
When content loads, hide the empty state and restore the working
layout.

Take the marketing site's dark-only token file and derive a
themeable version: a light mode and a dark mode that maps back to
the current palette. Keep every value a token, derive tints with
color-mix() instead of re-picking hex, and hold the accent green
to status only so it stays meaningful. Then check every
foreground/background pair against WCAG AA in both modes and list
any that fail, with a suggested fix.

Scaffold a token system whose canonical file is meant to be read and
reasoned about by an AI agent, not just compiled to pixels. Keep a
human-editable authoring file that carries semantic intent plus
provenance (role, evidence, applies-to, notes, whether a value is
extrapolated). Generate a normalized canonical artifact that preserves
every piece of that metadata, plus a JSON Schema describing its shape,
and validate against the schema at build time (fail the build on any
violation). Emit downstream projections (say, a standard design-token
format) that strip provenance. Never hand-edit generated artifacts.

Write a small Node script that audits my design tokens for WCAG 2.1
contrast, with no dependencies: implement sRGB-to-linear luminance and
the (L1+0.05)/(L2+0.05) ratio directly. Enumerate every meaningful
foreground/background pair: body ink on each surface, muted and label
text, link and status colors on panels, on-fill text over each solid
button fill, and colored text over the deepened badge tints (reproduce
those with a color-mix helper). Require 4.5:1 for normal text and 3:1
for large or bold text and UI graphics. Run both palettes, print each
pair as PASS/FAIL with its ratio, and exit non-zero if any fail.

Build a static gallery page for this component showing it in every
state as separate, labeled instances: default, hover, focus-visible,
active, disabled, and error where it applies, plus each size and
variant. Drive every value from the design tokens (no hardcoded hex);
derive tints with color-mix rather than re-picking colors. Use
real-looking placeholder data and generic labels. The page is the
deliverable, so treat spacing (8px grid), type hierarchy, and
alignment as production quality. Add an HTML comment noting the
intended props, the states shown, and the production component this
maps to.

Add a live theme builder to this token-driven showcase. Offer a
curated set of primary and secondary hues (each with a fill, an
AA-legible ink for text, and an on-fill text color), a primary UI font
and a secondary mono font loaded on demand, and a cool/warm ground
toggle. On selection, set the matching CSS custom properties on the
document root, derive hover and pressed states with a mix helper,
persist the choice to localStorage so it restores on every page, and
add a "Copy CSS" action that emits the chosen tokens as a :root block.
If screens are embedded in iframes, broadcast the overrides so they
re-theme in sync.

Recreate this product screen as a static mock built only from our
design-system component classes and tokens, never bespoke one-off CSS.
Reproduce the layout shell (nav rail, top bar, page header, content)
and the screen's real structure: filter tabs, a search field, a table
or card list, badges, status dots. Use generic labels and realistic
placeholder data, never the real product's copy. It must inherit the
live theme (same tokens, no local colors) and stay responsive: filter
rows wrap instead of overflowing, nothing forces horizontal scroll at
mobile width. Flag any component the screen needs that the library
doesn't have yet.

Read these component-catalog story files and generate a machine-readable
manifest of each component's variant structure: pull the variant
dimensions from the argTypes options (intent x type, variant x size),
the default args, and the exact token values (colors, spacing, radius)
resolved from the token package at extract time rather than
approximated. From that manifest, drive a design-tool plugin that
creates one component set per component with named variant properties
for every combination. Prefix generated frames with a marker so a
re-run safely regenerates only those. Report which props mapped to
variants and which couldn't (pseudo-states like hover can't be variant
nodes).

Scaffold a frontend-only, navigable prototype for a new feature on a
new branch, using mock data and local fixtures only: no backend,
persistence, auth, or new APIs. Reuse the existing app shell, routing,
and shared primitives, and follow the design system's patterns for
styling, spacing, hierarchy, and interaction rather than inventing a
new visual language. Build reusable, compositional components over
one-off markup, define local mock data types and realistic seeded
fixtures, and include sensible empty and loading states. When done,
summarize what you built, which patterns you referenced, and where
it's intentionally mocked.

Read the component stories and the running app, and generate a
design-tool file that redraws each shipped component from the
system. Then scan the app for places it reached past the system:
a raw framework element where a system component exists, an
inline style override. List each gap with the system equivalent
to use instead.

Here is the team's diff that finds where a design file disagrees
with the token spec. Build the review panel around it: walk every
difference, token by token and component by component, let me
approve or reject each with a reason, and write each decision
back as a receipt in the frame name and the file.

From this one spec, generate the command-line system's building
blocks and project them into the design tool. On re-run, diff any
change a designer made and let me apply it or set it aside.
Before a new pattern is accepted, check it against the
machine-readable ruleset and report what fails.

Compare this draft composition rule against every existing rule and
pattern in the ruleset. Report four things: which draft rules are
already covered (candidates to drop), which conflict with an existing
rule, which existing rules could be generalized to cover the new
pattern, and where rules could be combined or simplified. Present the
analysis with a recommendation and stop. Write nothing to the ruleset
until a human approves; never merge, delete, or auto-edit rules on your
own.

When a proposed screen or component is rejected, never revise it
automatically. Report the rejection reason back plainly, then ask
exactly one question: "This was rejected for [reason]. Do you want me
to revise from that feedback, or would you rather share a screenshot of
what you have in mind?" Wait for the answer. If they share a screenshot,
use it as the basis for the revision; if they choose revise, work from
the stated reason. Make no edits before they respond.

Read the reviewer's comments on this PR and break them into groups:
quick cosmetic fixes, content or data accuracy issues the reviewer
knows better than us, positive feedback needing no action, and open
design decisions that need my input. For each design decision, restate
the reviewer's actual concern, lay out two or three options with
tradeoffs, and cite how comparable products handle it. Make the
decisions with me first, then implement them in one batch and produce a
changes table I can post back.

For the change you're about to make, append a verification section I
can run to confirm nothing regressed. Include the type-check and
dev-server commands, the exact route to open, and a short list of
behaviors to click through (open the view, switch tabs, exercise
sort/filter/group, resize panels, confirm compact and expanded states).
Frame each item as a pass/fail check on the rendered page, not the
source, and call out anything expected to look visually identical so I
know what "unchanged" means.