Show mocks in T3 Code threads, and drop the t3 MCP servers that T3 already provides

user/agents/skills/frontend-design/SKILL.md

@@ -64,7 +64,11 @@ This is the rule from my preferences, spelled out:
    way in one sentence, they are the same mock.
 2. Build them as static pages. Real content, not grey boxes labelled "image here", because
    the content is where most of the design decisions turn out to matter.
-3. Publish them with a simple http server, report the URL, and stop.
+3. Show them, and stop. In T3 Code, render each direction in the thread with `html_preview`
+   then `html_render`, one direction per render so each expands full screen on its own, and
+   link the files by absolute path for the file viewer. `html_render` overrides a page
+   background, so a direction that paints its own goes inside an `<iframe srcdoc>`. Outside
+   T3, publish them with a simple http server and report the URL.
 4. Wait for a decision before implementing anything in real components.
 
 Do not edit real components first. Do not keep polishing past the point where a choice

user/agents/skills/grilling/SKILL.md

@@ -121,8 +121,8 @@ Announce the path, then create a todo per item and work them in order.
   immediately rather than spending a round on the details of something that needs splitting first.
   Each sub-project earns its own design cycle.
 - **Visual questions get mocks, not prose.** Where the open question is what something should look
-  like, stop describing it: build several distinct static mocks, serve them, report the URL, and wait
-  for a pick. Never edit a real component to answer a layout question.
+  like, stop describing it: build several distinct static mocks, show them in the thread (or serve
+  them and report the URL outside T3 Code), and wait for a pick. Never edit a real component to answer a layout question.
 
 ## The written spec (architectural only)
 

user/agents/skills/prototype/UI.md

@@ -13,9 +13,10 @@ Where the question is about logic or state rather than appearance, this is the w
 | **Static mocks** (default) | The question is layout, hierarchy, or visual direction. Standalone HTML, no app involved. | Minutes. Zero risk to the app. |
 | **In-app variants** | The question is how it behaves against **real** data, density, and chrome. A layout that looks fine on lorem ipsum falls apart on a real row count. | Higher. Touches the repo. |
 
-**Start with static mocks.** They are the house default: several distinct standalone pages, served by
-a simple static server, URL handed over. Escalate to in-app variants only where real data is
-genuinely load-bearing to the judgement, and say why when you do.
+**Start with static mocks.** They are the house default: several distinct standalone pages, shown in
+the T3 Code thread (or, outside T3, served by a simple static server with the URL handed over).
+Escalate to in-app variants only where real data is genuinely load-bearing to the judgement, and
+say why when you do.
 
 ## Static mocks (default)
 
@@ -23,8 +24,13 @@ Write each variant as a standalone HTML file in a scratch directory outside the
 the project's design language closely enough to judge (Tailwind via CDN is fine here, since nothing
 ships).
 
-Serve the directory with something already installed, such as `python3 -m http.server`, and hand over
-the URL plus the filenames. Then stop.
+In T3 Code, render each variant in the thread with `html_preview` then `html_render`, one variant per
+render, and link each file by absolute path so it opens full size in T3's file viewer. Keep each
+variant one file: the viewer gives a file outside the workspace no neighbouring styles, scripts or
+images. `html_render` overrides a page background, so pass a variant that paints its own inside an
+`<iframe srcdoc>` (the ticket skill's `ticket-page view` does this). Outside T3, serve the directory
+with something already installed, such as `python3 -m http.server`, and hand over the URL plus the
+filenames. Then stop.
 
 Never edit a real component to answer a layout question.