Artifacts, Skills & building things

The habit that changes everything downstream: stop asking for content and start asking for the deliverable. Claude builds it in a side panel while the conversation continues, and you download a finished file.

The artifact request names three things the content request doesn't: the format (Word doc), the audience (the board) and the shape (headline, three findings, one recommendation). That's the anatomy from guide 02 put to work.

More than most people ever ask for. The working list:

Once an artifact exists, your words act on it: Claude edits the thing in place instead of regenerating from scratch. Iterate like an editor, not a commissioner.

• Point at parts: "section two is flabby, tighten it", "swap the second chart for a table", "make the intro half as long".
• Change one dimension at a time: structure first, then content, then tone, then formatting. Asking for all four at once is how good drafts get worse.
• Fork when unsure: "keep this version, but show me a bolder layout as a second option".
• Know when to stop. Get to 90% here, finish the last 10% in your own tools. Chasing pixel-perfection through chat is slower than opening the file.

The most under-used capability in Claude: it can build you a small working app in about a minute. Not a mock-up, a working thing. The trick is noticing which of your problems are secretly tool-shaped.

Tool-shaped problems sound like: "every time X happens I do the same fiddly calculation", "I keep explaining this decision the same way", "we run this little process weekly and someone always gets a step wrong". Real examples that take one prompt each:

• A quote calculator with your actual day rates, margins and discount rules.
• A decision helper that walks a colleague through "which package does this client need?"
• A rota spinner, a stand-up order randomiser, a meeting-cost timer.
• A practice quiz built from your training document, for onboarding new starters.
• A "paste the messy export, get the clean version" formatter for that one report.

Build me a small web tool: [what it does in one
sentence]. Inputs: [the fields]. Logic: [the rules,
including edge cases]. Output: [what it shows]. Keep
it clean and simple, one screen, no login. I'll test
it and we'll refine.

State the logic precisely, especially the edge cases; that's the part Claude can't guess. Everything visual, it handles.

A Skill is packaged know-how: a folder holding instructions, and optionally scripts, templates and reference files, which Claude loads by itself when a task matches. You never invoke it; it just fires.

The economics are the point. Only a Skill's one-line description sits in Claude's context (roughly a hundred tokens); the full contents load only when a task actually triggers it. So you can accumulate dozens: house style, report format, pricing rules, review checklist, and pay nothing for the ones not in play.

Rule of thumb: context lives in projects (guide 03); methods live in Skills. "Acme's tone is formal" is project. "How we write proposals, with the template attached" is a Skill.

You don't write Skills by hand; you have Claude write them. The best first Skill is whatever you've explained to Claude more than twice.

1. Pick a repeated method. Your proposal structure, your weekly report format, your code-review checklist, your invoice rules.
2. Have Claude draft it. In a chat where you've just done the task well: "Turn what we just did into a Skill: name, a one-line description of when it applies, and the full method as instructions. Include the template we used."
3. Tune the description. The description is the trigger: Claude reads it to decide when the Skill applies. "Use when drafting client proposals or quotes" fires reliably; "helps with documents" fires never or always.
4. Install it (settings on Claude.ai; a folder in ~/.claude/skills/ for Claude Code), then test with a real task and refine, same as any draft.

The difference between a Skill that quietly improves everything and one that fights you:

• One job per Skill. "Proposals" and "invoices" are two Skills, not one "client documents" blob. Small Skills trigger precisely and stay editable.
• Show, don't describe (guide 02's rule, again): include the actual template, a filled-in example of a good one, and if you have it, a bad example with why.
• Write the edge cases. "If the client is new, include the onboarding paragraph; if renewal, lead with last year's results." Rules like these are the expertise; the formatting is just clothing.
• Include working files, not descriptions of them. A Skill can carry the spreadsheet template itself, a script that validates the output, the exact boilerplate. Claude uses what's in the folder.
• Version it like anything that matters. When your method improves, update the Skill; a stale Skill applies your old ways with perfect consistency.

Skills scale from personal habit to team infrastructure.

• Team distribution is Plugins: a shared repository the whole team installs from, so "how we write proposals" is versioned in one place instead of forwarded as zip files. Update the plugin, everyone's next proposal follows the new method.
• Anthropic ships pre-built Skills for common formats (documents, spreadsheets, decks), and an open ecosystem of community skills exists for everything else.
• Same format everywhere: a Skill built for chat works in Claude Code and Cowork, so a Dispatch fan-out (guide 06) applies your house style across every parallel child automatically. That's the compounding: standards you encoded once, enforced by default, at any scale.

The short honest list.

• Artifacts aren't collaborative documents. No comments, no tracked changes, no simultaneous editing. Draft here, collaborate in your real tools.
• Interactive tools are small apps, not products. No user accounts or databases; data lives in the page. Brilliant for calculators and helpers; wrong for anything holding customer data.
• Complex spreadsheets need checking. Formulas mostly work; formulas always need a spot-check before the file goes anywhere that matters (guide 01's calibration rule).
• Skills don't sync across surfaces. The format is portable but installation is per surface: Claude.ai, Claude Code and Cowork each need the Skill installed.
• A Skill that won't trigger has a vague description. Fix the description, not the instructions. If it triggers too often, same fix, opposite direction.
• Editing skills is harder than it should be. Skills live as files in folders, and iterating on one by hand (find it, unpack it, edit, reinstall, retest) is jarring compared to how easy using them is. The fix is pleasingly recursive: have Claude build you a skill for editing skills — one that finds the skill by name, applies your change, and reinstalls it — so "open my proposals skill and add the renewal rule" becomes one sentence. Worth making early; the native editing experience isn't there yet.

The distilled version.

1. Name the deliverable, not the content. Format, audience, shape, in the first message.
2. Iterate one dimension at a time, and stop at 90%.
3. Notice tool-shaped problems. Fiddly + repeated + rule-based = ask for a tool, today.
4. Edge cases are your job; everything visual is Claude's.
5. Methods become Skills the second time you explain them. Have Claude write the Skill from a task done well.
6. The description is the trigger. Tune it like a search query.
7. One job per Skill, real templates inside, edge cases written down.
8. Treat third-party Skills as programs, because they are.