A custom website with Claude Code, git, and Vercel: from idea to domain

Scaffold a new website project in the current folder. Brief:

Purpose: [personal site about a topic / company site / how-to blog].
Sections: [hub page, article list, article detail, about, contact].
Content will be MDX files in a content/ directory, not a database.

Technically:
- Next.js latest version, TypeScript, Tailwind
- no prebuilt component library (no Bootstrap, no MUI,
  no shadcn) — we write our own components
- folder structure: app/ (pages), content/ (content in MDX),
  lib/ (loading content from files), components/ (components),
  public/ (images), scripts/ (helper scripts)

First tell me how you plan to do it, and wait for my approval.
Once I approve, scaffold the project, run the build, and show me
that it passes. Don't write content yet — just one sample page
and one sample article, so I can see how it fits together.

Build the site's design system as a set of variables in one file,
so the look can be changed from a single place.

Character: [understated and text-focused / playful / technical].
Colors: [at most three — background, text, one signal color].
Use the signal color only for interactions: links, hover, and one
primary button per page. Never as a background for large areas.
Fonts: [one sans-serif for UI, one serif for long-form text,
one monospace for code samples].

Define variables for colors, fonts, text column width, corner
radii, and animation timing. For every color, check contrast
against WCAG AA (4.5:1 for body text) and write a comment next
to the value with the measured ratio, so nobody lightens it by
accident a month from now.

Then show me one page with every state: headings, a paragraph,
a link, a button, a card, a code sample.

Add a layer that loads content from MDX files in content/.

Each article has a header with fields: title, excerpt, category,
date, updated, and [other fields specific to your site].

In lib/, build a module that:
- loads all articles from the folder and returns them as a list
- can return a single article by slug (the filename without
  the extension)
- estimates reading time (200 words per minute, excluding code
  blocks)
- sorts articles from newest to oldest

The list and article detail pages should be built statically at
build time, not on every request at runtime.

Finally, explain in five sentences what happens when I add a new
file to content/ — I want to understand it, not just have it.

Explain the state of git in this project as if I'd never used it.
Specifically:

1. What branch am I on and what does that mean
2. Which files do I have changed and not saved
3. What exactly happens if I commit right now
4. How many commits are already in the project and when was the first

Then set up .gitignore so these never end up in the repository:
files with passwords and keys (.env and its variants), downloaded
dependencies, build output, and system junk.

Finally, write down three commands I should memorize, and one
sentence for each of what it does. Nothing more.

I broke something and want to go back.

First show me the last 10 commits: the message, the date, and one
sentence each on what changed. For each one, say whether you think
the site was working at that point.

Then explain the three options I have:
1. discard only the unsaved changes and stay on the last commit
2. restore the project's contents to the state of a specific older
   commit, but leave the history untouched
3. undo one specific change in the middle of the history

For each, say what happens to my work and what's irreversible.
Don't do anything yet. Wait until I give you a number.

I'm looking for a domain for [project description, target audience,
language]. The brand should feel [understated / playful / expert].

Suggest 20 candidates. For each, note:
- how it reads out loud and where a typo is likely when dictating it
- risk of confusion with an existing brand you know of

Sort them into three groups: descriptive (say what it's about),
brandable (a made-up word), and two-word combinations. Rule out
anything over 12 characters, with a hyphen, with numbers, and
anything that's awkward to spell out in [language].

For the five best, also suggest a variant for the English version
of the project.

Don't check availability or guess it — I'll verify that myself.

I want a multilingual site on two domains, not one with prefixes:
[domain.cz] = [Czech], [domain.tips] = [English]. Both domains
should have URLs with no language prefix.

Set up the middleware so it:
- internally rewrites the address to the correct language version
  based on the domain, without changing the address shown in
  the browser
- permanently redirects a prefixed address on the wrong domain to
  the correct, prefix-free domain (so only one address is ever valid)
- on the homepage, on a first visit with no stored preference,
  offers a language based on the browser and remembers the choice
- skips images, the API, the sitemap, and files with an extension
- reads both domains from environment variables, not hardcoded

Add hreflang links and canonical URLs so search engines know these
are two language versions of the same content.

When it's done, list ten addresses and say what happens with each
one — I want to check this before we ship it.

Prepare the project for deployment to Vercel.

1. Go through the code and find every place that reads an
   environment variable. Turn it into a table for me: variable
   name, what it's for, whether it's required, and what happens
   if it's missing.
2. Check the entire git history for any file with keys, or any
   key hardcoded in the code, that ever got committed. If you find
   one, tell me and advise what to do — don't rewrite anything
   yourself.
3. Verify that .gitignore excludes every variant of key files.
4. Write me a list of steps to take in Vercel's web interface,
   including which variables to set for production and which for
   preview deployments.
5. Check that the project can build without the optional keys too,
   and that the corresponding feature just turns off instead of
   the build failing.

Don't set anything in Vercel itself — just prepare the groundwork
for me.

I want this change on the site: [describe the change by outcome,
not technically — for example, "the article card should show when
it was last updated, and anything older than a year should get a
quiet note"].

Before you do anything:
1. Find every place in the project this touches, and list them
2. Write in three to five sentences how you plan to do it
3. Say what this could break elsewhere
4. Ask about anything in the brief that isn't clear — don't guess

Wait for my approval. Once I approve, edit the files, run the
build, and give me a list of changed files with one sentence
about each.

Before I save this, walk me through it.

1. Show me the list of all changed files, and for each one, in one
   sentence, what changed and why
2. Run the project build and show me the output — I want to see
   warnings too, not just errors
3. Check whether anything among the changes wasn't something I
   asked for: a new package in the dependencies, a config change,
   a deleted file, edited content the brief didn't cover
4. Check that no key or password made it into the changes

If anything in points 3 or 4 comes up, say so first, not at the end.

Save the change and ship it.

1. Write me a proposed commit message: one sentence, specific about
   what changed — not "updates," not a file list
2. Show it to me and wait for approval
3. After approval, commit and push to GitHub on branch [branch name]
4. Tell me what happens on Vercel now and how long it should take
5. Once the deployment is done, give me the URL and five specific
   spots to check in production because of this particular change

Don't push to the production branch without my explicit go-ahead.

Create a rules file in the project that you'll read on every run.
Write into it:

- what this project is and how it's organized (briefly, so someone
  seeing it for the first time can find their way around)
- which commands you may run without asking
- what always requires my explicit approval: deleting files,
  rewriting git history, pushing to the main branch, installing
  new dependencies, changing deployment settings
- the rule that keys and passwords never get written into files
  in the repository, only into environment variables
- what a commit message should look like
- what has to run before every commit

Write it as rules, not documentation. Short sentences, imperative
mood. Then show it to me and let me edit it.