One prompt per situation. Copy the one that matches yours into
your AI and describe what you want. An agent reads the same set,
plus the rules for choosing between them, at
/build.txt.
1 · Start from nothing, non-technical
Nothing exists yet and you don't write code. The AI makes every technical decision.
You are going to build me a complete product using the Facet design
library, and I am not a developer — so you make the technical
decisions and you never hand them to me.
First, read https://facet.tanishksharma.com/build.txt and follow its
method exactly. Read https://facet.tanishksharma.com/llms.txt to learn
every component, theme and behaviour Facet ships.
Then interview me in plain language, a few questions at a time — who
the product is for, what one job it must do, what done looks like.
No jargon: never ask me about frameworks, hosting, databases or file
formats. When you know enough, show me a short plan — the screens,
what is in v1, what is not — and wait for my yes.
Build it as plain HTML pages that use Facet from its URL: one link
tag, one CSS file, one JS file, nothing to install. Keep everything
front-end and static; if some part truly cannot work without a
server, park that part, say so in one sentence, and build the rest.
Pick a Facet theme that fits the product's mood and tell me why in
one line. Keep every screen reachable by a link I can share.
When you finish, check your own work like a user would — every
screen, every button, on a phone size and in dark mode — then show
me the result and tell me: what shipped, what you left out, and the
one improvement you would make next. Then stop and wait.
2 · Start from nothing, technical
Nothing exists yet and you understand tech. The AI teaches as it builds and keeps you in the decisions.
You are going to build me a complete product using the Facet design
library. I understand technology — a PM/founder level, not a daily
coder — so teach me as you build and keep me in the real decisions.
First, read https://facet.tanishksharma.com/build.txt and follow its
method exactly. Read https://facet.tanishksharma.com/llms.txt to learn
every component, theme and behaviour Facet ships.
Interview me before building: users, the one job, success, feel.
Then propose a v1 plan — screens, features in and out, which Facet
shell and theme and why — and wait for my yes.
Build with plain semantic HTML plus Facet's classes and data
attributes, consumed from its URL with no build step. As you build,
teach in passing: when you pick a shell, a component or a pattern,
say in a sentence or two what it is and why it is right here — I
want to understand what ships. Keep state in the URL so every screen
and configuration is shareable and testable.
If the product genuinely needs a backend — accounts, shared data,
anything that must persist beyond one browser — stop and explain:
what a backend is in this context, the smallest option that works,
what it costs to run, and what stays impossible without it. Build
the front end fully either way; wire the backend only after I agree.
Follow the backend rules in build.txt's addendum.
When you finish, verify like a user — every screen, every action,
phone size, light and dark — then walk me through what shipped, how
it works, what you left out, and what you would do next. Then stop.
3 · A backend is needed
The product needs accounts, shared data or persistence. Runs alongside whichever build prompt is going.
My Facet product needs a real backend — accounts, shared data,
something that must persist beyond one browser. Follow the backend
addendum in https://facet.tanishksharma.com/build.txt before wiring
anything.
Start by telling me, in plain words: what exactly needs a server
here, what stays possible without one, and the smallest real setup
that works — usually one managed database with row-level security
and a couple of serverless functions, never a server I babysit.
Name the running cost in real money, default to a free tier, and
wait for my yes before creating anything billable.
Keep the front end complete and static-first: the product still
renders and reads without the backend wherever that is honest —
cached content, read-only views, a clear offline state. Secrets
never reach the client: keys live in the host's environment
variables, and the browser talks to your functions, never to the
database.
When it works, prove it: create, read and change real data through
the product's own screens, then show me where the data lives and
what it costs per month. Then stop.
4 · Continue a half-built product
A Facet project already exists, unfinished. The AI reads what exists before touching anything.
You are continuing a product that already uses the Facet design
library. Do not touch anything until you have read what exists.
First, read https://facet.tanishksharma.com/build.txt and follow its
method. Read https://facet.tanishksharma.com/llms.txt to learn the
library. Then read every file in this project and tell me back, in a
short list: what the product is, which screens exist, which theme
and shell it uses, and what looks unfinished or broken.
Then ask me what done means for this round — a few questions, not an
interrogation — and propose the shortest list of steps that gets
there. Wait for my yes.
Work inside the patterns the project already has: its theme, its
shell, its naming, its files. Do not restructure, rename or restyle
anything that already works unless I ask for it. When you finish,
verify like a user — every screen you touched, phone size, light and
dark — and tell me what changed and what you deliberately left
alone. Then stop.
5 · Add a feature
One new capability on a working product. Nothing else moves.
Add one feature to my existing Facet product. I will describe the
feature in my next message. Everything else stays still.
First, read https://facet.tanishksharma.com/build.txt and
https://facet.tanishksharma.com/llms.txt, then read the project so
you know its screens, theme, shell and patterns.
Before building, tell me in a few lines how the feature will work
and where it will live — which screen, which Facet components — and
wait for my yes. Use components the library already ships; never
invent one it has, never add a framework or a build step.
Build the feature complete: its empty, loading and error states,
keyboard operation, phone size, light and dark, its state in the
URL so it can be linked to. Touch only what the feature needs — no
drive-by refactors, no restyling, nothing else moves. Then verify
it like a user, show me, and stop.
6 · Fix a bug
Something worked and now does not. Reproduce first, fix second, prove it third.
Fix one bug in my Facet product. Reproduce first, fix second, prove
it third. I will describe the bug in my next message.
Before changing anything, reproduce it: open the product, follow the
steps, and tell me you can see it — or tell me exactly what you
tried if you cannot. Never fix what you have not seen.
Then find the cause, not the symptom, and make the smallest change
that removes it. Check https://facet.tanishksharma.com/llms.txt
before working around the library: the behaviour you need may
already ship, and a bug inside a Facet component itself should be
reported upstream, not patched over in my project.
Prove the fix: walk the same steps and show the bug is gone, then
check the screens around it — phone size, light and dark — to show
nothing else broke. Tell me the cause in one sentence. Then stop.
7 · Restyle or rebrand
The look changes, the behaviour does not. The markup never changes.
Restyle my Facet product. The markup does not change — in Facet a
look is tokens and attributes, never new HTML.
First, read the theming sections of
https://facet.tanishksharma.com/llms.txt so you restyle the way the
library intends: the data-theme attribute, dark mode as its own
attribute, fonts by role, and the brand recipe — base colour to
accent-3, highlight to accent-1, support hue to accent-2.
Ask me for what exists: brand colours, fonts, a logo, the feel I
want. Then show me the mapping — which theme is the base, what each
accent rank becomes, which font roles change — and wait for my yes.
Apply it as tokens and attributes only. If you find yourself editing
a component's HTML or writing new CSS for something the library
already styles, stop and tell me what you needed — that is the wrong
path. Verify every screen in the new look, light and dark, contrast
still readable, and show me before and after. Then stop.
8 · Review and cut
It works but feels big or messy. A cold audit flags the replaceable and cuts the extra.
Audit my Facet product and cut the extra. Read it cold, as if
someone else built it, and judge it.
First, read https://facet.tanishksharma.com/build.txt — the quality
bar at the end is the checklist — and
https://facet.tanishksharma.com/llms.txt so you know everything the
library ships.
Go through every file and give me three lists: what breaks the
quality bar (missing states, keyboard gaps, wrapper soup, state not
in the URL); what re-invents the library (hand-rolled CSS or JS that
a Facet component, token or behaviour already covers — name the
replacement); and what is extra (code, wrappers, screens or options
nothing uses).
Wait for my yes on the lists, then cut: swap re-inventions for the
library's own pieces, delete what nothing uses, fix the breaks.
Prefer deleting to adding. Verify every screen after, and report
what got smaller. Then stop.
9 · Add a language
A new language, through the library's own translation system.
Add a language to my Facet product using the library's own
translation system — never a rewrite, never a second copy of the
pages.
First, read the translation section of
https://facet.tanishksharma.com/llms.txt and follow it exactly: the
translation table, the attributes on translatable text, and the
language switch control.
Ask me which languages, and whether the translations come from me or
from you drafting them for my review — and for each language, formal
or casual register, once. Mark every piece of interface text
translatable, fill the table, and wire the switch where the library
says it goes.
Verify by walking every screen in each language: nothing overflows,
nothing is left untranslated, dates and numbers follow the locale
where the library handles them, and the choice survives moving
between pages. Show me each language live. Then stop.
10 · Make it installable
It should live on a home screen and work offline, using the library's PWA layer.
Make my Facet product installable: a real icon on a phone's home
screen, working offline, using Facet's PWA layer — not a rebuild.
First, read the PWA and offline sections of
https://facet.tanishksharma.com/llms.txt and follow them: the
manifest, the icon set, the one-line service worker that loads the
library's caching engine, and the iOS metas the library requires —
viewport-fit, the apple-mobile-web-app pair, safe-area insets.
Follow the library's caching law exactly: pages load network-first
and the cache answers only offline — never cache-first HTML. Ask me
for the app's name, and build the icon set from the product's own
mark.
Verify: install it in a phone-sized viewport, open it standalone,
check the status bar and the safe areas, then go offline and show
the product still opens. Tell me what works offline and what
honestly cannot. Then stop.
11 · Produce the paper pieces
It needs to exist on paper: invoice, deck, letterhead, card, one-pager.
Produce a paper piece for my product — an invoice, a pitch deck, a
letterhead, a business card, a one-pager — using Facet's print
system and templates, never a PDF tool.
First, read https://facet.tanishksharma.com/llms.txt — the print
system and the templates — and start from the closest shipped
template (deck, document, card) rather than a blank page.
Ask me which piece, what goes on it, and whose brand it carries.
Build it as a Facet page that prints exactly: interface controls off
the paper, content on it, clean ink-on-paper with no shadows, page
breaks in the right places, and exact sizes where the template
defines them — the deck's 1920×1080, the card's 3.5×2in, A4
documents.
Verify by printing to PDF at the exact size and checking every
page: nothing clipped, nothing orphaned, no dark ink leaking from a
themed mode. Give me the page and the PDF. Then stop.
12 · Hand over and ship
It is done and needs to go live: deploy, verify live, hand over honestly.
Ship my Facet product and hand it over honestly.
Before deploying, run the full quality bar at the end of
https://facet.tanishksharma.com/build.txt — every screen by URL,
keyboard everything, phone and desktop, light and dark, JavaScript
off, one clean print — and fix what fails.
Deploy it as the static site it is: any static host works. Ask me
which host I use, or pick the simplest free one and say why in one
line. Wire the deploy and give me the live link.
Then verify LIVE, not just locally: open the deployed link and walk
every screen as a user, on a phone size, clicking everything.
Hand over in plain words: the live link, what shipped, what was
left out and why, what it costs to keep running (usually nothing),
and the one next thing worth doing. Then stop.
13 · Contribute a component to the library
The piece belongs in Facet itself. Rides the library's own charter.
You are going to add a component to the Facet library itself — not
to a product built with it. This is maintainer work and it follows
the library's own charter.
First, read the repo at https://github.com/tanishksharma/Facet.
CLAUDE.md at its root is the build charter: the markup rules, the
naming rules, the compliance checklist and the keep-in-sync
contract. Read llms.txt to be sure the component does not already
exist — the library never ships the same thing twice.
Tell the maintainer what the component is and why it earns a place —
the library grows by extraction: patterns that repeat across real
products, not one-offs — and wait for a yes.
Then build it the charter's way: semantic tokens only, every state
covered, keyboard operable, print role declared, fully commented,
and one commit that updates the CSS, the JS if it has behaviour, the
library page's wall entry and llms.txt together. A new entry ships
marked in development; only the maintainer promotes it. Open the
change as a pull request. Then stop.