How to write a good prompt: what worked for us building a website with AI

We build Outcomo with the help of Claude, the AI from Anthropic. We work with it in Claude Code, a tool that writes and edits code right on the computer. Of the 229 commits (saved changes) in the site's repository, 224 were made with Claude, the first on September 28, 2026 (as of October 31, 2026). All 21 calculators and tools, the articles in 9 languages and the tests that check them: it all starts with an instruction, a prompt. Here is what has worked for us in writing them. With each tip we also say what the official guides from Anthropic, OpenAI and Google say about it.

1. Say what it is for and who it is for

The AI knows only what you tell it about your task. Anthropic suggests treating Claude as a brilliant but new colleague who doesn't know how you do things: the more precisely you explain what you want, the better the result. It also offers a simple test: show your prompt to someone who knows nothing about the task. If they'd be lost, so will the AI.

So for every article, the AI is told who it is for: readers in which country and how to address them. In German we use the formal Sie, in Spanish and Polish the informal form, in Hungarian the formal Ön.

It also helps to say why. Anthropic gives an example: instead of "never use ellipses", say that the text will be read by a text-to-speech voice that can't pronounce them. From the reason, the AI works out things you never wrote down. When we didn't want the FAQ answers to cite laws, we added why: laws change and we'd have to keep checking the text. So the rule is to write in general terms and point to the contract or the bank for details.

2. Be specific

The Claude Code documentation advises writing instructions specific enough to check whether the AI followed them: "use 2-space indentation" instead of "format code properly". OpenAI says the same: be clear and specific, give enough context and avoid ambiguity. A few instructions from our work:

General	Specific
Add explanations.	Add an explanation to every calculator field a layperson may not understand. For returns and volatility, with examples from our data. In every language of the site.
Check the numbers.	Take the numbers in an article only from the data files, where every number has a source and a date.
Don’t write anything uncertain.	What you don’t know for sure, write as an open question, not as a fact.

The first rule came about when some calculators were missing their explanations. Written this way, it can be checked field by field in every new calculator.

3. Show an example

An example often says more than a long description. Anthropic calls examples one of the most reliable ways to set the format, tone and structure of a response, and recommends 3 to 5 of them. They should resemble your real task and vary enough that the AI doesn't pick up something they share only by chance. Google advises always including examples.

So a new article doesn't start from scratch: the AI first reads a similar finished article and follows its structure, tone and the way it cites sources. This one followed the AI voice-over guide.

4. Say what to do, not what not to do

A ban says what you don't want, but not what you do. Anthropic suggests replacing "don't use markdown" with "answer in flowing paragraphs". Instead of "don't make up prices" we have "prices only from the official price list, with the date we checked it". The AI then knows where to find a price and what to add to it.

5. Let the AI say "I don't know" and ask for sources

AI sometimes makes up an answer that sounds plausible. Anthropic advises explicitly allowing "I don't know" as an answer, asking for a source for every claim and striking out claims without one. It also warns that even this doesn't remove errors entirely, so important information needs checking.

Our rules: sources only from official pages, and an estimate never presented as a fact. Two examples from the past few days:

• Hungarian and the AI voice. Before translating the AI voice-over guide into Hungarian, we checked in the ElevenLabs documentation which languages the model speaks. Hungarian isn't one of them, so the Hungarian article says so right at the start instead of claiming the steps are the same.
• Buttons we haven't seen. The Trezor guide doesn't name buttons we haven't checked. It says "choose to receive", not a label the app may show differently.

6. Check the result against something you can verify

Anthropic recommends knowing, before you tune a prompt, how you'll recognise a good result and having a way to test it. For us, that's tests: the site has 1,338 of them and the AI runs them after every change. They check the calculators' maths and the articles too, for example that words after numbers take the right form in Polish or Ukrainian.

The AI writes the tests as well, and they catch its own mistakes. In the English Trezor guide we first wrote that the passphrase generator's English word list contains only letters. A test that went through the whole list found words with hyphens too, such as drop-down. We fixed the text before it went live.

7. Break a big task into steps

A first prompt rarely works first time. OpenAI and Google both describe prompting as iteration: write it, look at the result, adjust the wording, add context or simplify the task. Google also suggests splitting a complex task into smaller steps, where the output of one is the input of the next.

So bigger changes to the site don't start with code. First we write a design with the AI: what it should be, who it's for and what's out of scope. From that, the AI makes a step-by-step plan, and only then writes the code, step by step, with tests. The repository has 23 such designs and 11 plans.

8. Write down once what keeps repeating

Rules that always apply don't need to go into every prompt. ChatGPT has custom instructions for this, which apply to all chats; Claude has project instructions. Claude Code loads the project's instruction file (CLAUDE.md) at the start of every session, along with notes it keeps itself. Its documentation advises keeping instructions short and specific, under 200 lines per file: a longer file takes up more room and the AI follows it less reliably.

Ours include that the AI talks to us in Czech, where to take numbers from and how to address readers in each language. New rules mostly appear after mistakes, like the one about explanations.

9. Skills: instructions the AI picks up when it needs them

Project instructions are loaded every time. A skill, by contrast, is a folder with instructions (a SKILL.md file), sometimes with scripts and reference files, that the AI loads only when it's relevant. Until then it knows only the skill's short description, so even long instructions cost almost nothing until they're needed. You can also run a skill by hand, with a slash and its name, such as /brainstorming.

Claude has built-in skills for Word, Excel, PowerPoint and PDF documents, and according to its help centre, skills are available on every plan, including the free one. The format is an open standard, Agent Skills, so the same skill works in other tools too. The skills.sh directory lists Cursor, GitHub Copilot, Codex and Gemini CLI, for example.

The set we use most is Superpowers. Its brainstorming skill asks about the task before any work starts, one question at a time, and writes a design from the answers. The writing-plans skill turns the design into a plan. That's where the designs and plans from step 7 come from.

The SkillsBench study showed that skills really help: with carefully prepared skills, models solved 50.5% of the tasks on average instead of 33.9%. Focused skills of at most 3 parts did better than large bundles of instructions. And a smaller model with skills matched a larger model without them.

Which skills people actually use

Nobody publishes how many people use each skill, so we compared what can be counted (as of October 31, 2026):

• Projects on GitHub. In grep.app, a search engine over a large sample of public GitHub repositories, we counted the projects that keep the skill in a folder the AI loads it from (.claude/skills or .agents/skills). This is the closest to actual use.
• Installs in the skills.sh directory from Vercel, which counts installs made with its npx skills tool.
• Mentions in discussions. Comments on Hacker News since October 1, 2025 that name the skill.

The most common in public projects are frontend-design, skill-creator, and vercel-react-best-practices. On the other hand, for some skills with a large number of installs we didn't find a single project (installs in brackets): reddit-automation (1.2M), design-mobile-apps (1.1M), and ai-video-generation (916K). So an install count alone says little about use. The most mentioned on Hacker News are Superpowers, frontend-design, grill-me, and caveman.

Skill	Projects	Installs
Planning and workflow
skill-creator (anthropics)	162	420K
grill-me (mattpocock)	114	1.5M
Design and UI
frontend-design (anthropics)	214	1.1M
web-design-guidelines (vercel-labs)	111	808K
React websites
vercel-react-best-practices (vercel-labs)	138	858K
shadcn (shadcn)	85	131K
Testing and debugging
playwright-cli (microsoft)	54	203K
diagnosing-bugs (mattpocock)	41	872K
Databases
convex-quickstart (get-convex)	25	133K
supabase-postgres-best-practices (supabase)	24	468K
Mobile apps
vercel-react-native-skills (vercel-labs)	9	262K
building-native-ui (expo)	6	58K
Marketing and SEO
seo-audit (coreyhaines31)	29	243K
copywriting (coreyhaines31)	15	242K
Documents
pdf (anthropics)	24	220K
docx (anthropics)	14	211K
Video
remotion-best-practices (remotion-dev)	25	720K
hyperframes (heygen-com)	9	1.3M

Claude's built-in document skills are used without installing anything, so they need not appear in projects at all. A skill can also contain scripts that run on your computer, so install skills only from authors you trust. The skills.sh directory also shows the results of security checks for them.

Summary

1. Say what the result is for, who it's for and why you want it that way.
2. Make instructions specific enough to check whether the AI followed them.
3. Add an example or a finished model to follow.
4. Say what to do, not what not to do.
5. Allow "I don't know" as an answer and ask for sources.
6. Check the result against something verifiable, such as a test.
7. Break a big task down: design, plan, steps.
8. Write down once what keeps repeating, and put longer instructions into short, focused skills.

You can try how precise instructions need to be even without AI. In our coding for beginners tool, the robot does exactly what you put together, not a step more.