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.

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.

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.

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.

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.

# 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.

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.

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.

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.

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.