Sharing AI-Built Outputs

You made something with AI — a script, an app, a one-page report, a tool — and now someone else needs it. This wiki maps the sensible ways to hand it over, puts numbers on what each costs you and them, and says plainly who can get in.

You name the outcome; your agent does the setup. Say what should happen — "make a private repo and invite Maria" — and the agent does the fiddly steps; only an account, a login, or accepting an invite is ever on you. New here? → How to ask your agent (~2 min).
"Cost" here means your input time — the minutes you can't hand to the agent, not wall-clock or how hard the tool looks. Usually a ~10-min setup once, then near zero per share.
Two kinds of page. Option pages say what to use (short — read to decide); tutorials say how (step-by-step, for when you're ready to act).

Which one should I pick?

Three questions and you're done. Most of the choice falls out of: what you want to happen, who's on the other end, and how private it has to stay. Skim the table, then jump to the section that matches your sticking point.

What you want to happen — work on it together / just show or run a finished thing / hand over the know-how.

Who's on the other end — has their own AI agent / comfortable with tools / total beginner.

How private it must stay — public is fine / pick exactly who / just me.

Each route ends at a full option page — the numbers, caveats, and setup live there, not here. Last verified: 2026-06-07.

Find your goal on the left, glance at recipient and privacy, follow the link.

You want…	The thing is…	How private	Pick
Work on it together	Words — a guide, notes, prompts	Named people, free	Google Doc — restricted
Work on it together	Code or files, edits flow back	Named people, free	GitHub repo — private
Work on it together	Code or files	Public is fine	GitHub repo — public · GitLab, a template, or an offline bundle? → other ways
Work on it together	Structured data others read or add to	Named / public	Google Sheet — a lightweight shared database
Work on it together	The AI's context, on your AI platform	Named / org	Shared AI workspace
Just show or run it	Code they run + tweak in a tab, edit live with you (paid)	Named / public	Replit
Just show or run it	Code they open and press play	Named / public	Colab
Just show or run it	Words to read	Public is fine	Google Doc — anyone-with-the-link
Just show or run it	A live page or app	Public is fine	Deploy a website
Just show or run it	A chat-built mini-app, esp. using AI	Public is fine	Claude Artifact
Just show or run it	A shared assistant or doc, if your team lives in Google	Named / public	Gemini Gem / Canvas
Just show or run it	A bag of mixed files behind one link	Named / public	Google Drive folder
Just show or run it	A structured space, editable in place	Named / public	Notion page
Just show or run it	A polished read-only multi-page site	Public is fine	Docs site
Just show or run it	A live site	Named people / your org	Gated website
Hand over the know-how	A pattern to rebuild	You control the text	Reconstruction prompt
Give their agent a new ability	A reusable routine their Claude runs	Repo's reach	Claude skill
Give their agent a new ability	A live plug into a system you run	Named / public	MCP server
Give their agent a new ability	A one-word command they (or their agent) run	Named / public	CLI tool
Give someone a new ability	A keystroke tool on a teammate's Mac	Org / public	Raycast extension — Mac-only
Give someone a new ability	An automation that runs inside their repo	Repo's reach	GitHub Action
Collect input from people	Answers you gather, not a thing you send	Named / public	Form — responses land in a Sheet
Show it, kept tightly private	Anything	Confidential / regulated	see How private

By goal — what do you want to happen?

Work on it together

They edit, comment, refine it with you over time.

The thing is words — a guide, notes, a spec, a prompt library. → Google Doc. Several people write at once or leave margin comments while the text stays yours to accept; every keystroke saved, any version restorable. Lowest friction of all — collaborators just open a link.
The thing is code or files, and edits should flow back to you. → GitHub repo. The only option where people change one shared thing safely and you approve each change before it counts. Private for named people, public for strangers who propose fixes. Want GitLab, a ready-to-clone template, or an offline bundle instead? → other ways to ship a repo.
The thing is structured data — a list, a tracker, a set of figures others read or add to. → Google Sheet. A team appends rows to one shared sheet, every change saved — and because your agent reads and writes it by code, the same sheet doubles as a lightweight shared database or a live feed behind a small tool, no backend to build. Pick a Doc instead for flowing prose.
The thing is the AI's context itself, and the other end is on your AI platform. → Shared AI workspace (Claude or ChatGPT Projects). One space the AI keeps working inside — the same files, standing instructions, and running chats — so the group holds shared context instead of each person re-explaining. No code changes hands, just the AI's brief; everyone needs a paid seat on the same platform.
The rest are one-directional. A website and an Artifact are show-only (an Artifact's Customize spins off a private copy that never returns); a recipe hands over the blueprint, not a shared desk.
- Skip a repo if the recipient only wants to click and use the thing — handing over files defeats most beginners.

Just show or run a finished thing

They open it and use it; they never touch the files.

It's words to read — a write-up, a checklist, a set of prompts. → Google Doc. One tap, any phone, no account, no install.
It's a live page, dashboard, form, or app — wide reach. → Deploy a website. One link, opens in any browser, ~5 sec, no account. Pick the host below by its one defining trait.
It's a self-contained interactive thing, especially one that calls AI. → Claude Artifact. Same one-click open; if it uses Claude, the viewer signs in once and it runs on their bill, not yours — so you can share it across thousands at no cost. Pick a Gemini Gem or Canvas instead if your team lives in Google — same present-to-use share, grounded in your Drive.
It's a full web app — logins, saved data, several pages — built from a prompt, no code from you. → Lovable. You describe it in chat, hit Publish, and send a link; bigger than an Artifact (real backend and database, hosted for you), lighter than wiring up your own deploy. Pick the Artifact instead for a single clickable widget.
It's code a semi-technical recipient should run or tweak — without installing anything. → Replit to live-co-edit (you and they in the same running app at once, the multiplayer pick — paid), or Colab for a press-play notebook (they open a tab, hit Run all, and Copy to Drive for their own version). Both skip the install wall that stalls a repo; Replit runs a whole multi-file app, Colab a single notebook.
Handing over a whole bundle, no install, beginner-friendly — one of three, by how structured it is: a Google Drive folder for a bag of mixed files (Docs, Sheets, PDFs, images behind one link); a Notion page for a structured space — tables, boards, linked pages — others read or edit in place; a published docs site for a polished, read-only multi-page website at a URL.
Torn between a website and an Artifact? Website for a permanent link, a custom domain, or a public audience you can't pre-list. Artifact when you built it straight from a Claude chat, or want AI features billed to the viewer.

Choosing a host for a deployed site, by the one thing that sets each apart:

Netlify — the genuine no-account path: a live URL in ~30 sec, no signup either side. When you just want it seen now.
Vercel — slickest for real app frameworks (Next.js and friends). One login first; free tier is non-commercial only.
Cloudflare Pages — buy and wire a custom domain without leaving your agent, and the cleanest no-training stance.
Fly.io — a real backend: stores data, logs people in, keeps a server running. When your thing is more than static files. Pay-as-you-go, card required.
Gated website — a live site only named people can open (see How private).

Hand over the know-how

They rebuild their own version and own it from the first second.

Spread a pattern, not the exact files. → Reconstruction prompt. One block of text rebuilds a working cousin — no host, no account either side, and it crosses company lines a private repo can't.
Built on data you can't send? Same answer — describe the shape, leave the private parts as blanks.
- It's lossy on purpose (a close cousin, not a twin) and can't be recalled once sent. Want the exact thing, or changes flowing back? Use a repo instead.

Give their agent a new ability

The other end has their own agent, and you want to extend what it can do — not hand them a file or a finished thing. Higher floor (the recipient needs an agent), but the payoff is a capability that fires across all their future work. Pick by what you're handing over:

A reusable routine — a procedure their Claude runs on demand. → Claude skill. A house style, a grant-writing method, an onboarding checklist baked into a small folder their agent picks up and uses everywhere. Instructions, not a live connection. Reach = the repo's reach.
A live plug into a system you run — fresh data or a real action. → MCP server. Their agent queries your database or files a ticket against your tool in real time; you hand out the reach, not your keys or your code.
A one-word command they (or their agent) run over and over. → CLI tool. They type your-tool and it fetches itself and runs — the only one here a recipient without an agent can still use, and the only one that hides the code entirely.
A capability their code calls over the network — a score, a lookup, a forecast. → Live API. Their program sends a request and gets back an answer; your logic, data, and keys stay your side, and you update once for every caller. An MCP server is the same plumbing for an agent to call in plain language; a live API is for their code to call directly.
- Two more capabilities that don't need an agent at all: a Raycast extension puts a keystroke tool one hotkey away on a teammate's Mac (Mac-only — say so if they're on Windows or Linux), and a GitHub Action drops an automation straight into their repo that fires on every push or schedule.
- Skill vs MCP: a skill is a written recipe (no server), an MCP server is a live connection (you run something). CLI tool when they just need to run the thing, not read or extend it.

Or the reverse — collect input from people

Every goal above sends something out. The one that runs the other way: you hand people a link to give you answers — sign-ups, survey responses, intake details. → Form. Free, unlimited responses, nothing for them to install, and every submission lands as a tidy row in a Google Sheet your agent then reads and acts on.

By recipient — who's on the other end?

The real asymmetry: you have an agent; your recipient often doesn't. That's where the options separate.

Has their own AI agent. Everything works — and this is the only end that can take an agent-to-agent share. A reconstruction prompt is good only here (they paste it and their agent rebuilds), as are the agent-extension options: a Claude skill (a routine their Claude gains), an MCP server (their agent reaches a live system you run), or a CLI tool (one command their agent fires). A repo is smooth too: they point their agent at it and say "set this up and run it." Handing over a trained model or a dataset for ML/research people to load straight into their code? → Hugging Face — the place the field already looks, pulled in with one line, public / private / gated.
Comfortable with tools, no agent. A Google Doc, website, or Artifact is one click. For code they should run or tweak, this is the sweet spot for Replit (run and remix a whole app in the browser, or co-edit it live — paid) and Colab (open, press play, Copy to Drive) — both skip the install wall a repo hits, where running the files by hand is real friction. A recipe needs them to set up an agent first (~10 min once) — fine if they're game.
Total beginner. → a Google Doc to read, or a website / Artifact to use: open a link, no account, no install. Don't hand a beginner a repo (they stall at "run the code"), a recipe, a skill, or an MCP server (all need an agent on their side). A CLI tool is the one agent-extension option a beginner can still run — one command, if they're willing to install uv (or Node) first.
- Any gated website asks the viewer to sign in with Google once (free, ~1 min the first time), and an AI-powered Artifact asks for a free Claude account (~3 min once), before they're through; a plain Doc, page, or Artifact needs nothing.

How private must it stay?

Match the tool to the tightest rung it can actually hold — full ladder in Who can see it?. For who hosts your data, see Can you trust the company?. The headline change: a live website can now be private, not just a repo or a doc — so "show a finished thing" and "keep it to named people" are no longer in tension.

Public is fine. → any of them. A Google Doc (anyone-with-the-link), a website, a published Artifact, and a public repo are all open by default; a recipe is as open as the channel you paste it into.
Pick exactly who — named people, and free.
- Words? → a Google Doc set to named people (each signs in as themselves).
- Files they'll build on? → a private GitHub repo (viewers accept an email invite).
- A live site they just open? → a Gated website: a Google-login wall in front of any deploy, free to 50 people, deny-by-default. Cloudflare Pages carries the same free email gate natively; on Vercel and Netlify named-gating is a paid feature.
Everyone inside your company, behind a login.
- A Gated website keyed to emails ending in @your-org.org — a new hire is in the moment they have an org email, out the moment they don't.
- A Claude Artifact on a Team/Enterprise plan (its Share is org-only, sign-in required), or a repo granted by team.
Just me. → a Google Doc left restricted, a private repo with no one invited, or a gated website listing only yourself.
Confidential or regulated. → stay on the named / org-only rungs above — a private repo, a named Google Doc, a gated website, or an org-only Artifact. Never a public deploy, an anyone-with-the-link Doc, or a published Artifact.
- Data must stay in a region (EU/UK)? → Fly.io lets you pin the app and its database to London or Frankfurt.
- A recipe carries no privacy of its own and can't be unsent — never put PII, internal names, or keys in one.
- Revoking cuts the live thing, not the copies: whatever someone already saved is theirs, on every option here.

Still torn? Quick tie-breaks

Google Doc vs deployed website — both are one-click for the recipient. Pick the Doc when the thing is words (a guide, prompts, notes) and you might want comments; pick a website when it's a working tool they click through, not text they read.
Website vs Artifact — both run in any browser. Pick the Artifact when it uses AI (viewer's bill) or you built it inside a Claude chat; pick the website for a permanent custom domain, a reach you can't pre-list, or a named-people gate an Artifact can't hold.
Repo vs Reconstruction prompt — both leave the recipient able to change the thing. Pick the repo when they need the exact thing and changes should flow back; pick the recipe when you're spreading a pattern across people or orgs that can't share a workspace, or building on data you can't send.