TheFocus.AI TheFocus.AI
03 making things with artifacts Lesson 12

Publish and Share

Put the tool in your team's hands — and know what belongs on a public link.

~15 min

TUTOR WITH THEFOCUS.AI

Agent Integration

Copy this prompt into Claude, ChatGPT, or any external AI assistant. It points the assistant to the course instructions and links it to your student profile to track your progress and customize observations.

Please tutor me in this lesson using the following context. First, read the instructions at: https://courses.thefocus.ai/llms.txt My Student ID is: <none> The lesson markdown source is at: https://courses.thefocus.ai/mastering-claude/03-making-things-with-artifacts/12-publish-and-share.md

You are not enrolled yet. Enroll to generate a Student ID to track lesson completions and store learning notes.

From your conversation to their hands

A tool that lives inside your chat helps exactly one person. The point of the cheat-sheet is the register iPad, the new hire’s phone, the accountant’s browser. Artifacts get there with a link.

Use the share / publish control on the artifact panel. Publishing creates a public link to that artifact — anyone with the link can open it in a browser, no Claude account required, on any device. Copy the link, send it, done. If you update the artifact later, republish and the link serves the new version.

Sarah publishes the cheat-sheet and:

  • Opens the link on the register iPad, and leaves it there as the pinned tab
  • Texts it to both stores’ group chats
  • Adds it to the onboarding email for new hires — the first Cornwall Market “system” any new employee touches is a web tool Sarah built by talking

Two judgment calls to make every time you share:

Is this data okay on a public link? A published artifact is public to anyone who has the URL — it is not indexed and the link is unguessable, but it is not access-controlled either. Vendor account codes? Fine. A page with customer names, salaries, or anything regulated? No — keep that inside the conversation, or share it only through channels your organization already trusts.

Who updates it, and how will they know it changed? The cheat-sheet is now infrastructure — when Sarah adds a vendor, updating the artifact has to be part of the process. Her rule: the rules document (Chapter 04 turns it into a skill) is the source of truth, and the artifact gets regenerated from it. The page is a view of the knowledge, not the home of it. Hold onto that idea — it is the difference between a nice page and a system, and it is where this course is heading.

Try This

Publish your artifact and send the link to one real person who would actually use it. Open it yourself on your phone to see what they will see.

Then complete the loop from Chapter 02: an hour later, away from your desk, think of an improvement — and dictate it into the same conversation from your phone. Refine at your desk. Republish. You are now running a tiny product with a tiny release process.

Pages are not always the answer

Sometimes the deliverable is not a web page — it is a spreadsheet the accountant expects, a slide deck for the bank, a Word document for the lawyer. Claude makes those too: ask for a downloadable file and you get one, in the format the recipient’s workflow demands.

The decision is about the consumer:

The Output Goes To…MakeWhy
People who will use it (look up, click, calculate)ArtifactInteractive, always the latest version at the same link, works on any device
A workflow that expects a file (accountant, bank, legal, printers)Document / spreadsheet / deckTheir tools, their formats, their filing systems
A process that edits collaborativelyFile in your existing system (Docs, Office)Comments and tracked changes live where the collaborators are

Sarah’s split: the staff cheat-sheet is an artifact (used, not filed). The end-of-quarter vendor spend summary is a spreadsheet (her accountant files it). The bank presentation for the expansion loan is a deck (bankers want decks).

In Chapter 05 you will meet Cowork, which extends this from single files to whole folders — Claude working across your actual documents, producing multi-file outputs. For now, the one-at-a-time version covers a surprising amount of ground.

What the artifact taught you

Step back from the cheat-sheet and look at what actually happened this chapter, because the pattern is the course in miniature:

  1. Knowledge was captured (Chapter 02, by voice, in the aisles)
  2. Knowledge was structured (Claude formatted it into rules)
  3. Knowledge became a tool (the artifact — this chapter)
  4. The tool met reality (the cashier who typed “chens”, the cut-off iPad row)
  5. Reality improved the knowledge (the corrections went back in)

That loop — capture, structure, deploy, observe, correct — is exactly what the rest of this course industrializes. In Chapter 04, step 2 gets a real container (Projects, then skills) so the knowledge stops living in a chat thread. In Chapters 05-07, step 3 stops meaning “a page Sarah updates by hand” and starts meaning “a system connected to live data that updates itself.” In Chapter 09, step 5 becomes automatic — corrections feed back into the system without anyone re-typing them.

You have also crossed a psychological line worth naming: you shipped software this chapter. Not “used software” — shipped it. Described it, built it through iteration, tested it on real users, published it, and set up a process for keeping it current. The fact that it took an afternoon instead of an IT project is the point. When the tools get more powerful in the coming chapters, the method stays exactly this size.

Next: the knowledge you have been carrying around in chat threads gets a permanent, structured home. Chapter 04 is the legibility chapter — the hardest and most valuable transition in the book.

Check your understanding

Answer in your own words — write it down before opening the key. Your tutor grades against the criteria and generates fresh variants on retries.

Q1. Which of these belong on a published (public-link) artifact, and why: (a) a vendor-to-account-code cheat sheet, (b) a customer contact list, (c) a margin calculator, (d) a staff schedule with names and shifts?

Q2. “The page is a view, not the home.” What does that mean operationally — when the underlying rules change, what is the sequence of updates, and what goes wrong for the team that gets it backwards?

Q3. Your accountant needs quarterly vendor spend; your register staff need to look up account codes ten times a day. Which output format does each get, and what is the general rule you applied?

Answer key — attempt every question first

Answer key

Q1

Model answer: (a) and (c) are fine — reference data and a calculator carry no sensitive information. (b) and (d) do not belong on a public link: customer PII and named staff schedules are exactly the data that should stay inside access-controlled channels. The test: a published link is open to anyone who has it.

Pass criteria: correctly sorts all four; articulates the public-to-anyone-with-the-link property as the reason

Q2

Model answer: The knowledge document (later, the skill) is the source of truth; the artifact is regenerated from it. Sequence: update the rules document first, then rebuild and republish the page. Backwards — editing the page directly — forks the truth: the tool and the rules drift apart, and the next regeneration silently destroys the page-only edits.

Pass criteria: source of truth = knowledge doc/skill; page regenerated from it; names the drift/fork failure of editing the view

Q3

Model answer: Accountant gets a spreadsheet — their workflow files documents in their formats. Staff get the artifact — interactive lookup, always-current link, any device. Rule: match the format to the consumer — people who USE it get a tool; workflows that FILE it get a file.

Pass criteria: artifact for the lookup use, file for the accountant; states the consumer-determines-format rule

Next: Create a Project

Previous Lesson 12 of 42 Next