noslopui 0.3.0 → 0.3.1

package/README.md

@@ -61,7 +61,7 @@ Anything else that speaks MCP over HTTP can be connected by hand — add `https:
 |---|---|
 | `npx noslopui search <query>` | Search UI blocks and Motion Lab effects (`--section ui-blocks\|motion-lab`, `--tag style:editorial`, `--limit`) |
 | `npx noslopui get <id>` | Print a component's code, or `--write src/Hero.tsx` (`--format tsx\|html\|vue`) |
-| `npx noslopui prompt <id>` | Print a component's AI-prompt version |
+| `npx noslopui prompt <id>` | Print a ready-to-paste prompt with a component's code |
 | `npx noslopui design-systems [query]` | Search design systems (`--tag theme:dark`) |
 | `npx noslopui design-system <id>` | Print a DESIGN.md, or `--write DESIGN.md` |
 | `npx noslopui collections` | Your saved collections |

package/SKILL.md

@@ -3,11 +3,11 @@ name: noslopui
 description: Build a stunning, non-generic UI using noslopUI's hand-crafted catalog over MCP — either from a collection the user curated themselves, or by choosing one Design System and applying it consistently across every component. Use when asked to build a landing page, dashboard, marketing site, or any new page/section from scratch, when the user mentions a noslopUI collection, or when a UI you're building looks like "AI slop" (gradient text, purple-on-purple, bounce easing, everything centered) and needs a real design system instead.
 ---
 
-# noslopUI
-
-You have access to the **noslopUI MCP server** — a catalog of hand-crafted (not
-AI-generated) UI components, full page examples, and portable Design Systems.
-
+# noslopUI
+
+You have access to the **noslopUI MCP server** — a catalog of hand-crafted (not
+AI-generated) UI components, full page examples, and portable Design Systems.
+
 ## The rules
 
 1. **Choose one design system before fetching any component, then restyle every component to it** — colours, type scale, spacing, radius, motion. One system applied everywhere is what stops a multi-page build reading as a collage.
@@ -17,298 +17,303 @@ AI-generated) UI components, full page examples, and portable Design Systems.
 5. **A collection existing is not the same as the user asking for it.** `list_collections` is free to call, but only build from what it returns when the user asked for their saved items by name or in substance, or confirmed it when you asked. The default "Favorites" list is just where the save button drops a single item with zero setup — a lone design system sitting in it is not a decision to build the whole thing around. One collection with content and no explicit ask → surface it as a question, don't assume either answer. Nothing confirmed → shortlist two or three design systems with `search_design_systems` and let the user pick.
 6. **If a gated tool says the trial has ended or the fair-use limit is reached, tell the user and stop** — don't retry, and don't swap in something generated from scratch.
 7. **A Motion Lab effect is a signature moment, not a section.** Reach for one (`search_components` with `section: "motion_lab"`) when the user asks for an effect, motion, 3D or a showpiece, or the brief clearly calls for one — then use one per page unless they ask for more. Recolour it through its `colorVars` to the design system's tokens, follow its `usage`, and keep its reduced-motion fallback.
-
-Setup, if the noslopUI tools aren't available: the user runs
-`npx noslopui@latest init`, or adds `https://noslopui.com/api/mcp` in their
-agent and signs in when it asks (steps for each agent: `noslopui.com/mcp`).
-Every call runs as the user's account. Search, metadata and collections are
-free on every account. Code, prompts and DESIGN.md files need a paid plan or
-the account's free 3-day trial, which the first such call starts.
-
----
-
-## Step 0 — Which path?
-
-**Call `list_collections` first.** It's free on every account. But a
-collection existing is not the same as the user asking you to build from it —
-the default "Favorites" list is just where the save button puts a single item
-with zero setup, so a design system sitting there alone is very often a saved
-reference, not a decision. Don't let its mere presence override what the user
-actually asked for.
-
-- The user already said to use their saved items ("build from my collection",
-  "use what I've saved", names a list by name) → **Path A**, no need to ask.
-- Nothing was said either way, but exactly one collection has content that
-  looks relevant → **ask**: name what's in it and let them choose Path A or
-  Path B. Don't assume silently in either direction.
-- No collection, or nothing in any of them fits → **Path B**.
-- Several collections and no obvious match → ask which one. Don't guess
-  between two curated sets.
-
----
-
-## Step 1 — Requirements, including brand
-
-Do this on both paths, before choosing a system. Two groups of things.
-
-**The build:**
-
-1. **Purpose** — what is this for? (SaaS product, local service business,
-   portfolio, storefront, internal dashboard, docs site, …)
-2. **Audience** — who is it for?
-3. **Tone** — 2-3 words ("calm and minimal", "bold and playful", "editorial and
-   serif-driven", "warm and local"). This is what Step 2 matches against.
-4. **Required sections** — the concrete list of what must exist.
-
-**Their brand** — skip this and you ship a beautiful page that isn't theirs:
-
-5. **Logo or wordmark** — do they have one, and in what format?
-6. **Brand colours** — hex values if they have them, and whether they are fixed
-   (a franchise or a rebrand-in-progress changes the answer).
-7. **Existing typeface** — anything already in use they need to stay with?
-8. **Photography or illustration** — real assets to work from, or
-   placeholder-and-replace-later?
-9. **An existing site or profile** to stay consistent with.
-
-No brand at all → say so plainly and use the design system's own palette. Don't
-invent a logo.
-
-No real photography → don't ship a grey box. Use a seeded placeholder from
-[Picsum](https://picsum.photos) — `https://picsum.photos/seed/<brand-slug>-<slot-name>/<w>/<h>`
-— so the same build gets the same photo on every regenerate instead of a new
-random one. Mark every one with `<!-- TODO: Replace with real photo, target
-size <w>x<h> -->` immediately above it, and write alt text for the *intended*
-subject ("Hand-poured ceramic mug, studio lighting"), not the placeholder
-("Picsum image"), so it's already correct once they swap it in. Skip
-photography altogether where the chosen design system's own register is
-photo-free (type-led, editorial, most SaaS) rather than forcing a stock photo
-in where the system doesn't call for one.
-
-If the user already stated all this, don't re-ask — restate it in one line and
-move on.
-
----
-
-## Path A — the user curated a collection
-
-`get_collection({ listId })` (or `name`). Every item carries a `kind` —
-`design_systems`, `ui_blocks` or `motion_lab` (an effect) — plus a top-level
-`designSystems` array and a `guidance` line. A saved effect is a pick like any
-other: use it where it fits, restyled as in Step 3.
-
-1. **The collection's design system wins.** One in it → that is the system, no
-   searching; `get_design_system_file` for its DESIGN.md. More than one → ask
-   which; they saved both deliberately. None → say so, choose one as in Path B,
-   and tell them which and why.
-2. **Cover each required section from the collection first.** If the user saved
-   something that covers a section, use it. Always. **Never substitute a
-   catalog component for one they explicitly saved**, even if you found
-   something you think is better — that was their call, not an oversight.
-3. **Fill the gaps with `search_components`, checked before you hand-build
-   anything.** Search the whole catalog on fit, and restyle what you find to
-   the collection's design system. Only build a gap section yourself if
-   nothing in the catalog fits it, and say so in step 4's report.
-4. **Report what you filled in.** "Hero, pricing and footer from your
-   collection; you had no testimonial section saved, so I pulled one from the
-   catalog and restyled it." They should never have to diff the result to find
-   out what they didn't choose.
-
-Continue to Step 3.
-
----
-
-## Path B — you choose
-
-### B1. Shortlist design systems, then ask
-
-Design systems are classified by **tag**, not by category — there is no tree to
-walk. Call `search_design_systems` with no arguments first if you don't know
-what exists: it returns every system plus `availableTags`, the full filterable
-vocabulary (`theme:`, `style:`, `industry:` and so on).
-
-Then filter with `tags` (ANDed) and/or a free-text `query` built from the tone
-words plus purpose:
-
-```
-search_design_systems({ tags: ["industry:hair-beauty"] })
-search_design_systems({ tags: ["industry:dentist", "theme:light"] })
-search_design_systems({ query: "calm minimal", tags: ["industry:saas"] })
-```
-
-`industry:` is a two-level tree, shaped like a template marketplace's: a
-**field** (`food-drink`, `medical`, `home-services`, `technology`…) and, under
-it, **niches** (`restaurant`, `dentist`, `roofing`, `saas`…). Every system
-tagged with a niche is also tagged with its field, so start with the niche if
-the brief names one and widen to the field when that returns fewer than three.
-
-**"Local business" is not an industry — name the trade.** A plumber is
-`home-services`, a barber `hair-beauty`, a café `food-drink`, a physio
-`medical`, a yoga studio `wellness`, an accountant `professional-services`.
-Each of those looks and reads differently, and filtering on the specific field
-is what keeps two local businesses from getting the same site.
-
-A system can carry several fields — a warm serif system serves a restaurant, a
-wedding planner and a spa alike — so don't treat one tag as excluding the
-others, and don't pick the same system for every brief in a field: read the
-descriptions and match the tone the user described.
-
-Every result comes back with its tags, its token summary (colours, fonts,
-radius) and a `previewUrl`. **Present the 2-3 best matches to the user with
-their names, one-line descriptions, palettes and preview URLs, and ask which
-they want.** Don't pick silently. This single choice shapes every screen, it
-costs one question, and the user has taste you cannot infer from "a roofing
-business".
-
-Then `get_design_system` on their pick for the ungated token summary, and
-`get_design_system_file` for the full DESIGN.md.
-
-If nothing matches well, say so and ask whether to go with the closest or with
-a system they describe by hand — don't quietly fall back to stock Tailwind
-defaults, which is the "AI slop" this workflow exists to avoid.
-
-**Read the whole DESIGN.md before fetching any component.** It's short by
-design — tokens plus a page or two of intent prose, meant to be held in context
-for the entire build. Its **Do's and Don'ts** section is the part doing the real
-work.
-
-### B2. Find components on fit
-
-**Never write a section's markup from scratch before checking the catalog.**
-Having the DESIGN.md in hand is not the same as being done searching — for
-*every* required section, call `search_components` first — `section` and
-`tags` filters as needed, with `tags` ANDed the same way (`["style:editorial"]`,
-`["animation:carousel"]`). Pick the best **structural** match: the thing that
-actually does what the section needs. Largely ignore how it currently looks;
-you are restyling it regardless. Only once nothing in the catalog fits a
-section is hand-building it acceptable — and say so, don't pass it off as a
-catalog pick.
-
-Every result is published as React/TSX with Tailwind classes, whatever stack
-the build target is. That's not a limitation — the markup and styling aren't
-React-specific, so converting a result to plain HTML, Vue, or anything else is
-a mechanical step (`className` to `class`, drop event-handler props, etc.),
-not a rebuild. Never skip a structurally-right component, or conclude the
-catalog has nothing for a non-React project, over its source format.
-
-**Effects are a separate kind.** `section: "motion_lab"` searches Motion Lab:
-shader backgrounds, 3D, liquid glass, text, cursor and scroll effects. An
-effect isn't a section of the page — it's the one moment people remember the
-page for. Use one where the brief asks for it (an effect, motion, 3D, "make it
-pop") or clearly calls for a showpiece, and one per page unless the user asks
-for more. `get_component` tells you how: `usage` says where it earns its
-place, `props` are its knobs, `colorVars` are the CSS custom properties its
-colours come from, and `libraries` are the exact npm packages and versions to
-install.
-
-Then `get_component_code` for the ones you'll use.
-
----
-
-## Step 3 — Apply the system, and fit the brand into it
-
-Two moves, in this order.
-
-**A. Restyle everything to the design system.** Same colour variables, same type
-scale, same radius, same spacing scale, same motion durations and easing, across
-every component. Where a fetched component's own defaults conflict with the
-system, the system wins — adapt the component, and never leave both looks in
-play at once.
-
-**B. Substitute the brand into the system's tokens.** This is what makes the
-result *theirs* rather than a nice demo:
-
-- Their primary colour replaces the system's `accent` token. A secondary, if
-  they have one, replaces a supporting token — not a second accent.
-- Their wordmark typeface replaces the `display` face if it suits headlines.
-  Body text stays the system's text face unless they insist.
-- Their photography replaces placeholder imagery at the same crops and ratios.
-
-**C. Effects take the system's colours through their variables.** A Motion
-Lab effect exposes each colour as a CSS custom property (`colorVars`, e.g.
-`--ml-accent`) and as a prop. Set those from the system's tokens — the brand
-accent, the darkest surface — and tune its `props` toward the system's motion
-rules (slower if the system is calm). Never recolour inside a shader or
-script, and never remove its reduced-motion fallback.
-
-**Substitute values, keep the rules.** The system's spacing scale, radius
-discipline, contrast requirements and "one accent moment per screen" all still
-apply after the swap — that is the point of a system: it survives a brand
-change. A roofing company's green goes where the indigo was, and the restraint
-around it is unchanged.
-
-**Check contrast after substituting.** A brand colour that fails the system's
-stated contrast pairs is a real problem: tell the user, propose a darker or
-lighter variant of their colour for text, and keep the original for large
-fills. Don't silently ship unreadable text because it was their hex.
-
-DESIGN.md files follow the open [DESIGN.md
-format](https://github.com/google-labs-code/design.md): YAML front matter with
-machine-readable tokens (`colors`, `typography`, `rounded`, `spacing`,
-`components`, with `{colors.accent}` references already resolved), then prose
-sections. Take concrete values from the front matter and the rules from the
-prose.
-
-## Step 4 — Polish pass (before calling anything done)
-
-Run this against the assembled result. These are the "AI slop" tells noslopUI
-exists to avoid — catch them here rather than shipping them:
-
-- **Typography** — one display face used sparingly (headlines only, not buttons
-  or body), one text face for everything else. Nothing outside the DESIGN.md's
-  stated scale.
-- **Color/contrast** — one accent moment per screen, not accent bleeding into
-  every icon, border and badge. Real contrast on text over any background,
-  checked against the DESIGN.md's own stated pairs.
-- **Spacing** — compose from the DESIGN.md's spacing scale; don't invent
-  in-between values. Prefer more whitespace over a denser grid.
-- **Motion** — only where it communicates a real state change; the DESIGN.md's
-  durations and easing, never a default bounce or spring. The one exception is
-  a Motion Lab effect placed where its `usage` says it earns its place — one
-  per page, recoloured to the system.
-- **Named slop-tells to actively reject**: gradient text, purple-on-purple
-  palettes, bounce/spring easing on everything, every layout centered with no
-  asymmetry, decorative-only animation.
-
-## Step 5 — Point back to the catalog for variations
-
-If the result doesn't land, don't re-prompt the same component blind. Point the
-user at `noslopui.com/explore` (every UI block in one grid, with Motion Lab and
-design-system shelves) to browse real alternatives, and at the
-Collections tab on `noslopui.com/account` to save the ones they like — which
-turns the next build into Path A. Then repeat from Step 3 with whatever they
-pick.
-
----
-
-## Quick reference — tool call shape
-
-```
-list_collections({})                                           -> { collections: [{ id, name, itemCount }] }
-get_collection({ listId?, name? })                             -> { collection, designSystems: [{id,name}], items: [{ id, name, kind, ... }], guidance }
-
-search_design_systems({ query?, tags?, tag?, limit? })          -> { results: [{ id, name, description, tags, tokens, previewUrl, url }], availableTags, industryTree }
-get_design_system({ id })                                       -> { id, name, tokens, previewUrl, detailUrl }
-get_design_system_file({ id })                                  -> { id, name, designMd }       [gated: paid or trial]
-
-search_components({ query?, section?, tags?, tag?, limit? })            -> { results: [{ id, name, kind, tags, url }] }
-get_component({ id })                                             -> { id, name, dependencies, builtWithDesignSystem, previewUrl, detailUrl }
-                                                                     motion_lab items add { usage, props, colorVars, libraries }
-get_component_code({ id })                                         -> { id, name, snippets: [{ language, code }] } [gated: paid or trial]
-get_component_prompt({ id })                                        -> { id, name, promptText }   [gated: paid or trial]
-```
-
-The account rides on the connection (a key or a sign-in, sent as the
-`Authorization` header), so no tool takes a credential argument. Every search, metadata and collection tool is free on
-every account; `get_design_system_file`, `get_component_code` and
-`get_component_prompt` need the account on a paid plan or inside its free
-3-day trial.
-
-- If a gated call's result carries a `trial` field, that call just started the
-  user's trial — tell them, with the end date it gives.
-- A trial covers up to 30 different items per 24 hours, far more than one site
-  needs. Fetch what the build uses, not the catalog speculatively; re-fetching
-  an item you already opened never counts again.
-- If a gated call says the trial has ended (or the fair-use limit is reached),
-  stop and tell the user plainly — don't retry, and don't quietly swap in
-  something generated from scratch in its place. Search and collections keep
+
+Setup, if the noslopUI tools aren't available: the user runs
+`npx noslopui@latest init`, or adds `https://noslopui.com/api/mcp` in their
+agent and signs in when it asks (steps for each agent: `noslopui.com/mcp`).
+Every call runs as the user's account. Search, metadata and collections are
+free on every account. Code, prompts and DESIGN.md files need a paid plan or
+the account's free 3-day trial, which the first such call starts.
+
+---
+
+## Step 0 — Which path?
+
+**Call `list_collections` first.** It's free on every account. But a
+collection existing is not the same as the user asking you to build from it —
+the default "Favorites" list is just where the save button puts a single item
+with zero setup, so a design system sitting there alone is very often a saved
+reference, not a decision. Don't let its mere presence override what the user
+actually asked for.
+
+- The user already said to use their saved items ("build from my collection",
+  "use what I've saved", names a list by name) → **Path A**, no need to ask.
+- Nothing was said either way, but exactly one collection has content that
+  looks relevant → **ask**: name what's in it and let them choose Path A or
+  Path B. Don't assume silently in either direction.
+- No collection, or nothing in any of them fits → **Path B**.
+- Several collections and no obvious match → ask which one. Don't guess
+  between two curated sets.
+
+---
+
+## Step 1 — Requirements, including brand
+
+Do this on both paths, before choosing a system. Two groups of things.
+
+**The build:**
+
+1. **Purpose** — what is this for? (SaaS product, local service business,
+   portfolio, storefront, internal dashboard, docs site, …)
+2. **Audience** — who is it for?
+3. **Tone** — 2-3 words ("calm and minimal", "bold and playful", "editorial and
+   serif-driven", "warm and local"). This is what Step 2 matches against.
+4. **Required sections** — the concrete list of what must exist.
+
+**Their brand** — skip this and you ship a beautiful page that isn't theirs:
+
+5. **Logo or wordmark** — do they have one, and in what format?
+6. **Brand colours** — hex values if they have them, and whether they are fixed
+   (a franchise or a rebrand-in-progress changes the answer).
+7. **Existing typeface** — anything already in use they need to stay with?
+8. **Photography or illustration** — real assets to work from, or
+   placeholder-and-replace-later?
+9. **An existing site or profile** to stay consistent with.
+
+No brand at all → say so plainly and use the design system's own palette. Don't
+invent a logo.
+
+No real photography → don't ship a grey box. Use a seeded placeholder from
+[Picsum](https://picsum.photos) — `https://picsum.photos/seed/<brand-slug>-<slot-name>/<w>/<h>`
+— so the same build gets the same photo on every regenerate instead of a new
+random one. Mark every one with `<!-- TODO: Replace with real photo, target
+size <w>x<h> -->` immediately above it, and write alt text for the *intended*
+subject ("Hand-poured ceramic mug, studio lighting"), not the placeholder
+("Picsum image"), so it's already correct once they swap it in. Skip
+photography altogether where the chosen design system's own register is
+photo-free (type-led, editorial, most SaaS) rather than forcing a stock photo
+in where the system doesn't call for one.
+
+If the user already stated all this, don't re-ask — restate it in one line and
+move on.
+
+---
+
+## Path A — the user curated a collection
+
+`get_collection({ listId })` (or `name`). Every item carries a `kind` —
+`design_systems`, `ui_blocks` or `motion_lab` (an effect) — plus a top-level
+`designSystems` array and a `guidance` line. A saved effect is a pick like any
+other: use it where it fits, restyled as in Step 3.
+
+1. **The collection's design system wins.** One in it → that is the system, no
+   searching; `get_design_system_file` for its DESIGN.md. More than one → ask
+   which; they saved both deliberately. None → say so, choose one as in Path B,
+   and tell them which and why.
+2. **Cover each required section from the collection first.** If the user saved
+   something that covers a section, use it. Always. **Never substitute a
+   catalog component for one they explicitly saved**, even if you found
+   something you think is better — that was their call, not an oversight.
+3. **Fill the gaps with `search_components`, checked before you hand-build
+   anything.** Search the whole catalog on fit, and restyle what you find to
+   the collection's design system. Only build a gap section yourself if
+   nothing in the catalog fits it, and say so in step 4's report.
+4. **Report what you filled in.** "Hero, pricing and footer from your
+   collection; you had no testimonial section saved, so I pulled one from the
+   catalog and restyled it." They should never have to diff the result to find
+   out what they didn't choose.
+
+Continue to Step 3.
+
+---
+
+## Path B — you choose
+
+### B1. Shortlist design systems, then ask
+
+Design systems are classified by **tag**, not by category — there is no tree to
+walk. Call `search_design_systems` with no arguments first if you don't know
+what exists: it returns every system plus `availableTags`, the full filterable
+vocabulary (`theme:`, `style:`, `industry:` and so on).
+
+Then filter with `tags` (ANDed) and/or a free-text `query` built from the tone
+words plus purpose:
+
+```
+search_design_systems({ tags: ["industry:hair-beauty"] })
+search_design_systems({ tags: ["industry:dentist", "theme:light"] })
+search_design_systems({ query: "calm minimal", tags: ["industry:saas"] })
+```
+
+`industry:` is a two-level tree, shaped like a template marketplace's: a
+**field** (`food-drink`, `medical`, `home-services`, `technology`…) and, under
+it, **niches** (`restaurant`, `dentist`, `roofing`, `saas`…). Every system
+tagged with a niche is also tagged with its field, so start with the niche if
+the brief names one and widen to the field when that returns fewer than three.
+
+**"Local business" is not an industry — name the trade.** A plumber is
+`home-services`, a barber `hair-beauty`, a café `food-drink`, a physio
+`medical`, a yoga studio `wellness`, an accountant `professional-services`.
+Each of those looks and reads differently, and filtering on the specific field
+is what keeps two local businesses from getting the same site.
+
+A system can carry several fields — a warm serif system serves a restaurant, a
+wedding planner and a spa alike — so don't treat one tag as excluding the
+others, and don't pick the same system for every brief in a field: read the
+descriptions and match the tone the user described.
+
+Every result comes back with its tags, its token summary (colours, fonts,
+radius) and a `previewUrl`. **Present the 2-3 best matches to the user with
+their names, one-line descriptions, palettes and preview URLs, and ask which
+they want.** Don't pick silently. This single choice shapes every screen, it
+costs one question, and the user has taste you cannot infer from "a roofing
+business".
+
+Then `get_design_system` on their pick for the ungated token summary, and
+`get_design_system_file` for the full DESIGN.md.
+
+If nothing matches well, say so and ask whether to go with the closest or with
+a system they describe by hand — don't quietly fall back to stock Tailwind
+defaults, which is the "AI slop" this workflow exists to avoid.
+
+**Read the whole DESIGN.md before fetching any component.** It's short by
+design — tokens plus a page or two of intent prose, meant to be held in context
+for the entire build. Its **Do's and Don'ts** section is the part doing the real
+work.
+
+### B2. Find components on fit
+
+**Never write a section's markup from scratch before checking the catalog.**
+Having the DESIGN.md in hand is not the same as being done searching — for
+*every* required section, call `search_components` first — `section` and
+`tags` filters as needed, with `tags` ANDed the same way (`["style:editorial"]`,
+`["animation:carousel"]`). Pick the best **structural** match: the thing that
+actually does what the section needs. Largely ignore how it currently looks;
+you are restyling it regardless. Only once nothing in the catalog fits a
+section is hand-building it acceptable — and say so, don't pass it off as a
+catalog pick.
+
+Every result is published as React/TSX with Tailwind classes, whatever stack
+the build target is. That's not a limitation — the markup and styling aren't
+React-specific, so converting a result to plain HTML, Vue, or anything else is
+a mechanical step (`className` to `class`, drop event-handler props, etc.),
+not a rebuild. Never skip a structurally-right component, or conclude the
+catalog has nothing for a non-React project, over its source format.
+
+**Effects are a separate kind.** `section: "motion_lab"` searches Motion Lab:
+shader backgrounds, 3D, liquid glass, text, cursor and scroll effects. An
+effect isn't a section of the page — it's the one moment people remember the
+page for. Use one where the brief asks for it (an effect, motion, 3D, "make it
+pop") or clearly calls for a showpiece, and one per page unless the user asks
+for more. `get_component` tells you how: `usage` says where it earns its
+place, `props` are its knobs, `colorVars` are the CSS custom properties its
+colours come from, and `libraries` are the exact npm packages and versions to
+install.
+
+Then `get_component_code` for the ones you'll use.
+
+---
+
+## Step 3 — Apply the system, and fit the brand into it
+
+Two moves, in this order.
+
+**A. Restyle everything to the design system.** Same colour variables, same type
+scale, same radius, same spacing scale, same motion durations and easing, across
+every component. Where a fetched component's own defaults conflict with the
+system, the system wins — adapt the component, and never leave both looks in
+play at once.
+
+**B. Substitute the brand into the system's tokens.** This is what makes the
+result *theirs* rather than a nice demo:
+
+- Their primary colour replaces the system's `accent` token. A secondary, if
+  they have one, replaces a supporting token — not a second accent.
+- Their wordmark typeface replaces the `display` face if it suits headlines.
+  Body text stays the system's text face unless they insist.
+- Their photography replaces placeholder imagery at the same crops and ratios.
+
+**C. Effects take the system's colours through their variables.** A Motion
+Lab effect exposes each colour as a CSS custom property (`colorVars`, e.g.
+`--ml-accent`) and as a prop. Set those from the system's tokens — the brand
+accent, the darkest surface — and tune its `props` toward the system's motion
+rules (slower if the system is calm). Never recolour inside a shader or
+script, and never remove its reduced-motion fallback.
+
+**Substitute values, keep the rules.** The system's spacing scale, radius
+discipline, contrast requirements and "one accent moment per screen" all still
+apply after the swap — that is the point of a system: it survives a brand
+change. A roofing company's green goes where the indigo was, and the restraint
+around it is unchanged.
+
+**Check contrast after substituting.** A brand colour that fails the system's
+stated contrast pairs is a real problem: tell the user, propose a darker or
+lighter variant of their colour for text, and keep the original for large
+fills. Don't silently ship unreadable text because it was their hex.
+
+DESIGN.md files follow the open [DESIGN.md
+format](https://github.com/google-labs-code/design.md): YAML front matter with
+machine-readable tokens (`colors`, `typography`, `rounded`, `spacing`,
+`components`, with `{colors.accent}` references already resolved), then prose
+sections. Take concrete values from the front matter and the rules from the
+prose.
+
+## Step 4 — Polish pass (before calling anything done)
+
+Run this against the assembled result. These are the "AI slop" tells noslopUI
+exists to avoid — catch them here rather than shipping them:
+
+- **Typography** — one display face used sparingly (headlines only, not buttons
+  or body), one text face for everything else. Nothing outside the DESIGN.md's
+  stated scale.
+- **Color/contrast** — one accent moment per screen, not accent bleeding into
+  every icon, border and badge. Real contrast on text over any background,
+  checked against the DESIGN.md's own stated pairs.
+- **Spacing** — compose from the DESIGN.md's spacing scale; don't invent
+  in-between values. Prefer more whitespace over a denser grid.
+- **Motion** — only where it communicates a real state change; the DESIGN.md's
+  durations and easing, never a default bounce or spring. The one exception is
+  a Motion Lab effect placed where its `usage` says it earns its place — one
+  per page, recoloured to the system.
+- **Named slop-tells to actively reject**: gradient text, purple-on-purple
+  palettes, bounce/spring easing on everything, every layout centered with no
+  asymmetry, decorative-only animation.
+
+## Step 5 — Point back to the catalog for variations
+
+If the result doesn't land, don't re-prompt the same component blind. Point the
+user at `noslopui.com/explore` (every UI block in one grid, with Motion Lab and
+design-system shelves) to browse real alternatives, and at the
+Collections tab on `noslopui.com/account` to save the ones they like — which
+turns the next build into Path A. Then repeat from Step 3 with whatever they
+pick.
+
+---
+
+## Quick reference — tool call shape
+
+```
+list_collections({})                                           -> { collections: [{ id, name, itemCount }] }
+get_collection({ listId?, name? })                             -> { collection, designSystems: [{id,name}], items: [{ id, name, kind, ... }], guidance }
+
+search_design_systems({ query?, tags?, tag?, limit? })          -> { results: [{ id, name, description, tags, tokens, previewUrl, url }], availableTags, industryTree }
+get_design_system({ id })                                       -> { id, name, tokens, previewUrl, detailUrl }
+get_design_system_file({ id })                                  -> { id, name, designMd }       [gated: paid or trial]
+
+search_components({ query?, section?, tags?, tag?, limit? })            -> { results: [{ id, name, kind, tags, url }] }
+get_component({ id })                                             -> { id, name, dependencies, builtWithDesignSystem, previewUrl, detailUrl }
+                                                                     motion_lab items add { usage, props, colorVars, libraries }
+get_component_code({ id })                                         -> { id, name, snippets: [{ language, code }] } [gated: paid or trial]
+get_component_prompt({ id })                                        -> { id, name, promptText }   [gated: paid or trial]
+```
+
+`promptText` is the component's full code wrapped in integration
+instructions (stack, file path, pinned dependencies, fonts, the design system it
+was built with). You don't need it to build — `get_component_code` is enough.
+It's for handing one component to a different agent or tool.
+
+The account rides on the connection (a key or a sign-in, sent as the
+`Authorization` header), so no tool takes a credential argument. Every search, metadata and collection tool is free on
+every account; `get_design_system_file`, `get_component_code` and
+`get_component_prompt` need the account on a paid plan or inside its free
+3-day trial.
+
+- If a gated call's result carries a `trial` field, that call just started the
+  user's trial — tell them, with the end date it gives.
+- A trial covers up to 30 different items per 24 hours, far more than one site
+  needs. Fetch what the build uses, not the catalog speculatively; re-fetching
+  an item you already opened never counts again.
+- If a gated call says the trial has ended (or the fair-use limit is reached),
+  stop and tell the user plainly — don't retry, and don't quietly swap in
+  something generated from scratch in its place. Search and collections keep
   working, so the plan itself can still be finished.

package/dist/index.js

@@ -39,7 +39,7 @@ ${color.bold('Account')}
 ${color.bold('Catalog')}
   search <query>         Search blocks and effects          --section ui-blocks|motion-lab, --tag <facet:value>, --limit
   get <id>               Print a component's code            --format tsx|html|vue, --write <file>
-  prompt <id>            Print a component's AI-prompt version
+  prompt <id>            Print a ready-to-paste prompt with a component's code
   design-systems [query] Search design systems               --tag theme:dark …
   design-system <id>     Print a design system's DESIGN.md   --write DESIGN.md
   collections            List your saved collections

package/dist/lib/version.js

@@ -1,3 +1,3 @@
 // One place for the version, so package.json, --version and the User-Agent
 // can't disagree. Checked against package.json by a test.
-export const CLI_VERSION = '0.3.0';
+export const CLI_VERSION = '0.3.1';

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "noslopui",
-  "version": "0.3.0",
-  "description": "Connect your coding agent to noslopUI \u2014 hand-crafted UI components and portable design systems, over MCP.",
+  "version": "0.3.1",
+  "description": "Connect your coding agent to noslopUI — hand-crafted UI components and portable design systems, over MCP.",
   "keywords": [
     "mcp",
     "claude-code",