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

user/agents/AGENTS.md

@@ -53,11 +53,24 @@ I wanted to share some of my preferences here so we can be more aligned as we wo
 
 # Visual & Design Work
 
-- Do not edit real components first unless asked to by the user. For any non-trivial UI, layout, or copy change, build serveral distinct static mocks, publish them with a simple http server, report the URL, and stop. Wait for a decision before implementing.
+- Do not edit real components first unless asked to by the user. For any non-trivial UI, layout, or copy change, build several distinct static mocks, show them to me, and stop. Wait for a decision before implementing.
+  - In T3 Code, show each mock in the thread with `html_render`, and link the mock files by absolute path so they open full size in T3's file viewer. No server.
+  - Outside T3 Code, publish them with a simple http server and report the URL.
 - Avoid continuously repainting CSS animations (pulse, shimmer, blur, spinners); they peg the GPU on high-refresh displays.
 
 ---
 
+# T3 Code
+
+I run my agents in T3 Code, and I want to stay in it rather than juggle terminals and browser windows. A thread has `T3CODE_THREAD_ID` set.
+
+- Show visuals in the thread: charts, tables, mocks, plans, to-do lists. `html_preview`, then `html_render`.
+- Link files by absolute path. HTML, PDF, images and Markdown open rendered in T3's file viewer, beside the thread. Do not start an http server just so I can look at a file.
+- Reach my other machines through T3's linked environments (`t3_environment_links`, then that environment's id), not through ssh, unless I ask for ssh.
+- Claude in Chrome is still the browser for my own signed-in sessions.
+
+---
+
 # Blast Radius
 
 - Never touch production, live databases, or daily-driver build/preview channels unless explicitly asked to. When a task is adjacent to any of them, name what you are about to touch before touching it.

user/agents/mcp/servers

@@ -42,12 +42,3 @@ sentry-gbrown   stdio  bin/sentry-gbrown  SENTRY_GBROWN_TOKEN
 # end-to-end runs. The ticket skill captures its proof screenshots this way.
 # No token, hence no variable in the last column.
 playwright      stdio  bin/playwright
-
-# T3 Code environments, one per machine. Agents read projects and threads and,
-# with more than read-only access, start and message threads there. No token:
-# each is an OAuth server that asks for a pairing code from that machine on
-# first sign-in, and the grant lasts 30 days.
-t3-desktop      http  https://t3desktop.gbrown.org/mcp
-t3-mac          http  https://t3mac.gbrown.org/mcp
-t3-sr           http  https://t3sr.gbrown.org/mcp
-t3-jr           http  https://t3jr.gbrown.org/mcp

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.