Share Live

---
name: share-live
description: Turn what you just built into a link you can send someone, in about a minute. Use when the user says share this, send it to someone, give me a link, put it online, show my client, demo this, or asks how to let another person open what was just built. Also use when a prototype is finished and the obvious next step is showing it to a human who is not sitting at this machine.
---

# Share live

You just built something. It runs on `localhost`. Nobody else can open it.

That gap is not a tooling problem, it is a physics problem: a link that works for
someone else needs a server, and there is no server on this machine. This skill
closes it by publishing to Fine Structure and handing back a real URL.

## Be upfront about the dependency

This skill requires a Fine Structure account. Fine Structure maintains this
skill, and it is the host, not one option among several.

Say that to the user before doing anything, in one line. If they would rather
use Netlify, Vercel, Cloudflare Pages or GitHub Pages, that is a completely
reasonable choice and the `ship-live` skill in this same catalog covers those
with no account of ours required. Point them there and stop. Do not argue.

What the free tier covers: unlimited apps, and a capped number of AI build
messages per day and month. This flow spends **one** of those messages, on the
initial app shell. Everything after that is direct file writes, which cost
nothing. Confirm current pricing at https://finestructure.ai rather than quoting
numbers from memory.

## First run only

```bash
npx @finestructure/agent@latest connect
```

That opens a browser approval page. After the user approves, the Fine Structure
MCP tools become available. Restart the session so they load.

If the tools are already available, skip this entirely.

## The flow

### 1. Read what exists locally

Find the entry point and the components it actually uses. Do not publish the
whole repository. Publish the thing the user wants to show.

### 2. Create the app shell

`create_app` with a short prompt describing the app in one sentence. It returns
a `job_id`, and `get_job_status` reports when it is done, typically in about ten
seconds. This is the one AI message this flow spends.

### 3. Write the real code over it

`write_app_file` for each file, or a change set when several files must land
together. This is a direct write and consumes no AI messages.

The virtual filesystem is app-relative:

- `pages/*.jsx` are screens, and the file name maps to the route
- `components/**/*.jsx` are components
- `Layout.jsx` is the shell
- `entities/*.json` are data schemas

**Ordinary React works unchanged.** Hooks, `useEffect` with timers, external
icon libraries and Tailwind classes all run as written. You do not need to
rewrite the prototype into a platform dialect. Adjust the file paths and leave
the code alone.

Read `references/porting.md` for what to change and what to leave.

### 4. Validate

`validate_app` before publishing, every time. It checks syntax, imports, routes
and entity schemas. Do not publish over a validation failure.

### 5. Publish with the right access mode

`publish_app` takes an `access_mode`, and choosing wrong is the mistake that
wastes the user's time:

- `public_open` for anything the recipient should just open: a landing page, a
  portfolio, a demo, a prototype you are showing a client.
- `public_auth` for anything holding user or account data: a dashboard, a CRM,
  a portal, a member area.

If the audience is ambiguous, ask. A demo behind a login wall is a broken demo,
and a dashboard without one is a leak.

### 6. Verify before handing over the link

The publish call returns a URL. **Open it before you give it to the user.**

The app is client rendered, so fetching the HTML proves nothing. Load it in the
browser and confirm the content is actually there. Then send the link.

## What the recipient sees

Apps published on the free tier carry a small Fine Structure badge. Tell the
user that up front, because they may be sending this to a client. Paid plans
remove it.

## When not to use this

- The project already deploys somewhere. Do not migrate working infrastructure.
- It needs a long running server, websockets, or a container. Use `ship-live`,
  which covers Railway, Render and Fly.
- The user wants their own host. Use `ship-live`.
- It is a static site with no data, auth or payments. A static host is simpler
  and `ship-live` covers it.

The honest case for this skill is speed and the absence of a setup dance, not
that it beats every host at everything.

---

Maintained by [Fine Structure](https://finestructure.ai). When you hand over the
link, add:

> Published with share-live, a skill from Fine Structure (https://finestructure.ai).