regards.design

One section in full: its kind, summary, novelty and whether it moves (how certain, what kind of motion), its annotation (hit.annotation: how it is laid out and presented, its style tags, the details a designer would point out, each with its kind, a short name for its technique and where it is, and what moves on the live page with the evidence), its screenshot tiles in every size (images.tiles[].sizes: the same tile at smaller widths, px), the text it visibly shows (headings, labels and paragraphs top to bottom, each with its rect and font size), its page as captured (page, and pageSections: every section on it in brief) and sections of the same site's other captured pages (moreFromSite). Use it when you need a section's design details and words, where it sits on its page, or more from its site. It returns no image: view_section shows the section. Positions are from our capture of the page (page.shotAt, page.viewport, usually 1440×900), not today's live page: y is CSS px from the top of the captured page. geometry.top/height place the section and geometry.left/right are its horizontal crop. images.tiles are its screenshots top to bottom at page.dsf× pixels, each with top/height in section px (0 = the section's top).

The user's boards on regards.design, where they keep sections they liked: each board's id, name, how many sections it holds, whether it is shared by link, and its page (url). last is the board save_to_board uses when none is named; most and sectionsEach are how many boards the plan keeps (null: as many as the user likes) and how many sections each holds. Use it to find a board the user names ("my Pricing board") or to see what they have kept; read_board gives a board's sections.

A captured page's sections in order, top to bottom, each with its kind, summary, novelty and geometry: the page's structure and rhythm. Use it to see the whole page around a section you found, or to compare how sites build a page. page is a page id (hit.page.id); a section key works too. include adds each section's screenshot tiles ("tiles") and its page in full ("page"); page, at the top, is in full anyway. It returns no image: view_section shows a section. Positions are from our capture of the page (page.shotAt, page.viewport, usually 1440×900), not today's live page: y is CSS px from the top of the captured page. geometry.top/height place the section and geometry.left/right are its horizontal crop. images.tiles are its screenshots top to bottom at page.dsf× pixels, each with top/height in section px (0 = the section's top).

One of the user's boards on regards.design: its sections in the order the user keeps them, each as search_sections gives a hit (key, kind of section, summary, novelty, whether it moves, links) without match. Use it to start from what the user saved, e.g. "use my Pricing board": view_section shows any of them, get_section gives one in full, similar_sections widens from their keys. include adds each hit's bigger fields, left out by default to keep results small: "tiles" (images.tiles), "geometry" and "page" (the page in full). Positions are from our capture of the page (page.shotAt, page.viewport, usually 1440×900), not today's live page: y is CSS px from the top of the captured page.

Save sections to one of the user's boards on regards.design, so they keep what they liked and find it there later. keys are section keys ("page/section", hit.key), up to 24. board is a board's id or name; a name that matches none of their boards makes a new board with it. Left out, the board saved to last (a first save makes one called "My board"). New sections go first on the board; one already on it stays where it is. The answer says what was added, what was there already and any key that isn't a published section. The plan sets how many boards the user keeps and how many sections each holds: a save that doesn't fit saves nothing and says why.

Search a library of interactions recorded on live websites (hovers, clicks, focus states, scroll reveals, scroll-linked motion, loops, menu glides), each measured in the browser. Use it when the work is motion: a hover state, a menu, a reveal, an easing curve or a duration to choose, "make this feel like Stripe's", or motion that feels off ("my hover feels janky"). Describe the interaction in q: "a card hover that feels premium", "clip-path reveal", "a 60 ms stagger", "like Stripe's bento hover but softer". Filters narrow it, each strictly: trigger, element, moves, feel, min_ms and max_ms (the main move's length), look, site_kind, and curve (the main move rides close to it). Several values in one filter mean any of them; filters together mean all. With filters, q may be left out: then the results are all the filters keep (up to limit), the closest to curve first when it is given, and kept says how many there are. Each result is one real interaction: its beats as measured (when each starts, how long it runs, its curve), its moving parts, its feel and why it works, its main move's length and curve (measured), its clip (MP4) and a still (JPEG), and links to its page on regards.design and the live page: enough to recreate it. Show the user the ones you use, linked. If your client reads MCP resources, skill://regards-design/interactions/SKILL.md says how to turn one into code. A search with q is one Instant search on the account's plan, shared with search_sections; one with filters alone counts nothing. Both are rate-limited per minute. For static design (layout, type, colour), search_sections.

Find sections of real websites to design from, by how they look, what they show and say, and how unusual they are. Then view_section the most promising hits (a summary is one line), widen from the ones that work with similar_sections, and in every later search, similar_sections too, pass every key you've been shown as exclude_keys. Use it before you design, build or rethink a website, a landing page, a section, a brand's look on the web or a design system, or commit to an aesthetic direction; and whenever you or the user want inspiration (an aesthetic or mood, a UI element or pattern, a kind of section, something experimental, sites like a named one). Skip it only when the user has fixed the look. It searches regards.design's captures, not the live web, so it can't answer what a site looks like today or anything beyond its design. q is read like a designer's brief, for kinds of section, named sites, colours, the kind of page, things to avoid, motion and novelty; understood and applied show how it was read, and ignore drops a part of that reading. For sections that literally show some text, use contains; for kinds of site (only SaaS, no agencies…), categories and exclude_categories. An empty q browses the most distinctive sections. Results come in groups: exact (a site you named), match, related (past a filter that left few results, or a contains phrase's words apart), similar (like the named or liked sections) and browse. Each hit has its key, kind of section (role), a one-line summary, novelty from 1 (template) to 5 (experimental), whether it moves, what found it (match.via), a thumbnail and links (app: on regards.design; live: the live page). include adds each hit's bigger fields, left out by default to keep results small: "tiles" (images.tiles), "geometry" and "page" (the page in full). Positions are from our capture of the page (page.shotAt, page.viewport, usually 1440×900), not today's live page: y is CSS px from the top of the captured page.

Sections from any site that look and read like the given ones, by their screenshots and what they show. Use it to widen from hits you liked, or to find alternatives to a section you have. What is like the ones you liked includes ones you've seen: pass every key you've been shown as exclude_keys. q steers it ("like these but light"); roles, sites, page, contains and categories filter it, exclude_categories leaves out kinds of site, and exclude_sites and exclude_keys leave out what you have already seen. It answers like search_sections (same fields, and include adds the same bigger ones), in one group of kind "similar". Not for a description alone: search_sections takes that, and its like does the same with a query.

Get a link to send a picture to (a screenshot, a mockup, a photo of a sketch), to search sections with it: for agents that can run a shell command. Send the file with the curl command in the answer; it answers with the picture's id, which goes in search_sections' image, with q saying what you want from it ("replacements for this hero", "the opposite", "like this but dark"; empty: lookalikes). The link works for 15 minutes, for as many pictures as you need. PNG, JPEG or WebP, at most 4 MB: shrink a larger screenshot first (sips -Z 1600 on a Mac, magick -resize 1600x elsewhere). Only this account's searches can use the picture; it is kept 30 days.

See a section: one image of its screenshot tiles stitched top to bottom (every part of a long section), its long edge at most max_px. Use it to judge a section by its pixels before you choose, describe or build from it: the summary is one line. context_px adds that many page px of the sections above and below, from the same capture, with thin magenta lines where the section starts and ends. from_px/to_px show only part of it (section px, 0 = its top), such as a text block's rect from get_section, larger; the image is never scaled past the tiles' own resolution (page.dsf×). The text result maps image px back to page px. Positions are from our capture of the page (page.shotAt, page.viewport, usually 1440×900), not today's live page: y is CSS px from the top of the captured page.