-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-@Claude where are we on launch prep? Pull together what's still open from this channel.
-On it. I'll go through this channel's open threads and the launch plan.
- -fold in the vendor quotes from last week's thread too
-Done. Full status below: eight items closed, three open. The venue contract is the oldest, waiting on legal since the 2nd.
-Tag @Claude in. Get results back in the thread.
-Anyone in a Slack channel can tag Claude into a problem and hand it work: reproduce a bug and open a pull request, turn a decision thread into a doc, assemble the state of a project. It posts a checklist in the thread as it goes, and the whole exchange stays visible to the channel.
- - -checkout has felt slow all morning — anyone else seeing it?
-same. @Claude can you investigate? Compare latency against this morning's deploy and find what's causing it.
-On it. I'll compare latency before and after the deploy, track down the cause, and report back here.
- -Security review
- Security and data handling -The security model, what admins can and can't restrict, audit trails, and network requirements.
-
+
-
+
Inline cards have these constraints:
@@ -73,7 +73,7 @@ Inline cards have these constraints:
On mobile, inline cards render full-width within the conversation. Make every tap target at least 44pt, and adapt content to narrower viewports without horizontal scrolling.
-
+
### Inline carousel
@@ -84,7 +84,7 @@ An inline carousel shows items side by side for browsing options. Users swipe or
* Media galleries
* Any set of comparable items
-
+
Inline carousels have these constraints:
@@ -96,7 +96,7 @@ Inline carousels have these constraints:
On mobile, carousel cards are optimized for horizontal swipe. Design for thumb reach by keeping primary actions in the lower portion of cards, and let the next card peek into view to signal that the row scrolls.
-
+
### Full screen
@@ -108,9 +108,9 @@ Full screen mode gives complex interactions an immersive interface. The conversa
* Content that benefits from focused attention
* Rich tasks requiring more space than inline allows
-
+
-
+
Full screen mode has these constraints:
@@ -121,7 +121,7 @@ Full screen mode has these constraints:
On mobile, your app fills the entire screen with the chat input and navigation bar overlaid on top, so keep critical UI within the safe area. Use the full viewport width, and support both portrait and landscape where it makes sense.
-
+
## Mobile guidelines
@@ -137,7 +137,7 @@ Render the interactive portion of your app inside the safe area so the mobile na
Read `hostContext.safeAreaInsets.{top, right, bottom, left}`, which are pixel values, and apply them as padding on your root container, or as `scroll-padding` on scroll-snap containers so items come to rest inside the visible region. Safe areas aren't mobile-specific: on web and desktop the composer can overlay the bottom of an inline app, so avoid placing interactive controls flush against any edge.
-
+
#### Borderless inline content
@@ -145,7 +145,7 @@ Set `_meta.ui.prefersBorder` to `true` or `false` to control whether your conten
In borderless mode your content runs edge-to-edge with no host padding, so honoring `safeAreaInsets` becomes essential. The bordered card's built-in padding otherwise absorbs most of them. Borderless works well for carousels and other horizontally scrolling content that should bleed to the screen edges while in motion: apply `safeAreaInsets.left` and `.right` as `scroll-padding-inline` on the scroll container so items at rest sit clear of the device edges but can scroll underneath them.
-
+
### Declare supported display modes
@@ -178,7 +178,7 @@ The `frameDomains` field, for embedding third-party iframes, is restricted in Cl
* Use full-width layouts, without side margins that waste mobile screen space
* Let content reflow gracefully, and avoid fixed-width layouts
-
+
### Touch targets
@@ -187,7 +187,7 @@ The `frameDomains` field, for embedding third-party iframes, is restricted in Cl
* Larger, thumb-friendly buttons rather than small text links
* Primary actions within natural thumb reach, in the lower portion of the screen
-
+
### Scrolling and gestures
@@ -203,19 +203,19 @@ If your app needs its own vertically scrollable viewport, request fullscreen pre
* Provide a clear visual affordance for expansion, such as a fullscreen button or tap-to-expand
* Closing fullscreen returns to the conversation at the same scroll position
-
+
### Dark mode
All views must support both light and dark themes. Use the host's style tokens, which adapt automatically, and never hardcode colors. Test both modes.
-
+
### Loading states
Show skeleton screens while content loads, and match the layout structure of the final content so the swap is smooth. Avoid spinners for inline content, because skeletons feel more native.
-
+
## Visual design
@@ -225,29 +225,29 @@ MCP Apps should feel native to their environment while maintaining consistent vi
Use host tokens for all structural elements: backgrounds, text, borders, and icons. You can use your own brand colors for accents and identity, but the core UI should use the provided palette.
-
+
### Typography
Stick to the three-level size scale of heading, body, and caption, and the two weights of regular and emphasized. This creates clear hierarchy without visual noise.
-
+
-
+
### Icons
Use monochromatic, outlined icons that match the host's icon color tokens. Icons should support understanding rather than be essential to it.
-