docs: restore page heroes with new illustrations (#1060)

docs/build/auth.mdx

@@ -4,6 +4,10 @@ description: "Know who's behind every tool call"
 icon: "key"
 ---
 
+import { Hero } from "/components/hero.jsx";
+
+<Hero src="/images/auth.webp" alt="Authenticate Users" />
+
 [Tool](/build/tools) calls are anonymous by default: nothing in the protocol tells you who's asking. [OAuth](https://oauth.net/2/) closes that gap, and the host does most of the work: it discovers your authorization server, signs the user in, refreshes tokens, and attaches a Bearer token to every request. Your server keeps three jobs: publish the discovery metadata, verify the tokens, and read the user in your handlers.
 
 <Tip>

docs/build/state.mdx

@@ -4,6 +4,10 @@ description: "Decide what the model sees"
 icon: "database"
 ---
 
+import { Hero } from "/components/hero.jsx";
+
+<Hero src="/images/state.webp" alt="Manage State" />
+
 Between [tool](/build/tools) calls, the model is blind: it doesn't watch the user's interactions with the UI. Yet, to answer the user's next message, the model often needs to know what's on screen. State is how the [view](/build/view) closes that gap, and the design decision is always the same: what should the model see, what shouldn't, and when.
 
 Here's a complete view, the `carousel` mounted by a tool call to `search-products`, holding shared state, hidden state, and a narration for the model:

docs/build/tools.mdx

@@ -4,6 +4,10 @@ description: "Define what humans and agents can do"
 icon: "wrench"
 ---
 
+import { Hero } from "/components/hero.jsx";
+
+<Hero src="/images/tools.webp" alt="Register Tools" />
+
 Tools are the entry point of your app: the model reads their metadata and triggers them when they fit the conversation. Think of them as an API: each tool has one job, and jobs can complement each other. Bind a view to a tool, and the host [mounts](/get-started/architecture#app-lifecycle) it inline in the conversation. The model isn't the only caller: the user can trigger tools too, via the [view](/build/view).
 
 Here's a complete tool definition:

docs/components/hero.jsx

@@ -7,9 +7,9 @@ export const Hero = ({ src, alt }) => (
     alt={alt}
     style={{
       width: "100%",
-      maxHeight: "30vh",
+      height: "auto",
+      display: "block",
       marginTop: "-0.75rem",
-      objectFit: "cover",
       borderRadius: "15px",
     }}
   />

docs/guides/files.mdx

@@ -5,6 +5,10 @@ sidebarTitle: "Files"
 icon: "paperclip"
 ---
 
+import { Hero } from "/components/hero.jsx";
+
+<Hero src="/images/files.webp" alt="Handle Files" />
+
 [Views](/build/view) run in a sandboxed iframe, cut off from the conversation and the user's disk. Each host opens its own door for files, and the two work differently: ChatGPT keeps a file store your [tools](/build/tools) and views read and write; Claude only lets a view save a file to the user's device. What you can build depends on the host.
 
 ## Files in ChatGPT

docs/guides/migrate.mdx

@@ -5,6 +5,10 @@ sidebarTitle: "Migrate"
 icon: "bird"
 ---
 
+import { Hero } from "/components/hero.jsx";
+
+<Hero src="/images/migrate.webp" alt="Migrate to Skybridge" />
+
 The Skybridge Skill migrates an existing MCP App for you, whatever framework or library it's built on. It teaches your coding agent Skybridge, then drives the rewrite.
 
 ## Install the Skill

docs/guides/ux.mdx

@@ -5,6 +5,10 @@ sidebarTitle: "UX"
 icon: "sparkles"
 ---
 
+import { Hero } from "/components/hero.jsx";
+
+<Hero src="/images/ux.webp" alt="UX Design" />
+
 An MCP App is a new kind of surface with its own UX principles. The [view](/build/view) shares the screen with an ongoing conversation, in a frame the host controls. Skybridge surfaces that environment through [hooks](/api-reference/overview#hooks), so the view can read its context and adapt.
 
 ```tsx views/carousel.tsx

docs/resources/apps-sdk-and-mcp-apps.mdx

@@ -4,6 +4,10 @@ description: "How ChatGPT and other hosts run your views, and what Skybridge uni
 icon: layers
 ---
 
+import { Hero } from "/components/hero.jsx";
+
+<Hero src="/images/mcp-apps.webp" alt="Apps SDK and MCP Apps" />
+
 MCP Apps is the open contract for rendering interactive views inside an AI client. ChatGPT also exposes the Apps SDK: an optional layer of `window.openai` APIs for its own capabilities, on top of that same contract. Skybridge targets the MCP Apps baseline and reaches the Apps SDK only where you opt into a ChatGPT feature, so one server and one set of views run on both.
 
 ## MCP Apps

docs/ship/index.mdx

@@ -4,6 +4,10 @@ description: "Deploy and version your app"
 icon: "ship"
 ---
 
+import { Hero } from "/components/hero.jsx";
+
+<Hero src="/images/deploy.webp" alt="Ship" />
+
 A deployed MCP App is a server on a public URL where hosts connect to `/mcp` and the built [views](/build/view) are served alongside it. Take it there on any [Node.js](https://nodejs.org/)-compatible platform, then run more than one version of it on the same domain.
 
 <Columns cols={2}>

docs/test/audit.mdx

@@ -4,6 +4,10 @@ description: "Catch spec and platform issues before submission"
 icon: "clipboard-check"
 ---
 
+import { Hero } from "/components/hero.jsx";
+
+<Hero src="/images/audit.webp" alt="Audit" />
+
 Before a platform accepts your app, the server must conform to the MCP specs, and each platform layers its own requirements on top, which differ between [OpenAI](https://developers.openai.com/apps-sdk/app-submission-guidelines) and [Anthropic](https://claude.com/docs/connectors/building/submission). The Audit checks your app's conformance and performs end-to-end tests in real ChatGPT and Claude conversations, triggering [tools](/build/tools) and rendering [views](/build/view).
 
 ## Run the Audit

docs/test/devtools.mdx

@@ -4,6 +4,10 @@ description: "Call tools and render views locally, without a host"
 icon: "square-dashed-mouse-pointer"
 ---
 
+import { Hero } from "/components/hero.jsx";
+
+<Hero src="/images/devtools.webp" alt="DevTools" />
+
 Testing through a real host means exposing a public URL, registering a connector, starting a conversation, and prompting the model until it calls the right [tool](/build/tools). DevTools cuts that loop down to a file save: it runs locally, emulates the host runtime, and lets you call tools directly, no model or host involved.
 
 ## Start the Emulator

docs/test/playground.mdx

@@ -4,6 +4,10 @@ description: "Chat with a real model running your app"
 icon: "message-circle"
 ---
 
+import { Hero } from "/components/hero.jsx";
+
+<Hero src="/images/playground.webp" alt="Playground" />
+
 Putting a real model in the loop normally means registering your app in a host. The Playground skips that: a chat wired to your local server, where a real LLM uses your [tools](/build/tools) and the [views](/build/view) render inline.
 
 ## Start the Playground

docs/test/tunnel.mdx

@@ -4,6 +4,10 @@ description: "Tunnel your local server to ChatGPT and Claude"
 icon: "globe"
 ---
 
+import { Hero } from "/components/hero.jsx";
+
+<Hero src="/images/tunnel.webp" alt="Connect to Hosts" />
+
 ChatGPT and Claude connect to MCP servers over the internet, and your dev server lives on localhost. The tunnel bridges the two: it exposes your local server on a public URL, so real hosts run your app while it keeps reloading on every file save.
 
 <Info>