Your brand as a system: from brand voice through brochure and website to CRM

I've never worked with a terminal and I'm about to install Claude
Code on [Windows / Mac] following a guide. Walk me through it in
advance, without installing anything: exactly what will I see after
opening the terminal, what does the line I type into look like, what
does it mean when “nothing happens” after a command, and how do I
tell an error message apart from normal output?
Then explain what the Claude Code install command will do and how
I'll know the installation succeeded. Write for a complete beginner,
step by step, without jargon — and when you need jargon, explain it
right away.

I'm uploading our roastery's brand manual, website copy, three
newsletters, and a product spec sheet [add your own materials].
We are [a small coffee roastery, 6 people, we sell to cafés and
retail customers].

Build a Brand Voice document from this in markdown, structured as:
1. Who we are and who we talk to (2–3 sentences, no marketing fluff)
2. Tone: 4–6 traits, each with an explanation of what it means in
   practice and a sample sentence that demonstrates it
3. Vocabulary: words and phrasing we use (including technical ones —
   variety names, roast levels), and how we write numbers and units
4. Forbidden phrases: what never gets said here, and why
5. Examples: 3 “not like this / like this” pairs for a product
   description, a customer email, and a social media post

Work only from the uploaded materials. Where the materials
contradict each other, write it up as an open question at the end —
don't decide for me.

Go through the Brand Voice document we built and act like an editor
who has to write from it tomorrow: ask me every question the
document doesn't answer. I'm especially interested in:
- formal/informal address across different channels
- humor: how much fits on the website, how much in an email, how
  much in a sales proposal
- how we talk about competitors
- how we sound in an unpleasant situation (a complaint, a price
  increase, a delayed delivery)
Ask one question at a time, and fold my answers straight into the
document as I give them.

Here's our Brand Voice document [paste it] and here are three
writing tasks not covered in the materials: [a complaint email to
a café, a description of a new coffee, an invitation to a tasting
for wholesale customers].

Write each piece according to the document. Then add a short
reflection: which rules you weren't sure about because they could be
read two ways, and how you chose. Those exact spots are what we'll
sharpen in the document.

Work over the folder brochure-2026. It contains a subfolder photos
(a selection I like — there are deliberately a lot of them),
pricelist.xlsx, and a folder copy with source materials. Our tone
lives in brand-voice.md.

Do an inventory: list what's in the folder, and propose the content
of a ten-page print brochure for cafés that buy coffee from us. For
each page, state: purpose, key message, which photos are candidates
(file names), and where the copy comes from. Pick fewer photos than
I'd expect — one strong shot per page beats a collage.
For the price list, propose which items belong in the print brochure
and which don't, because they change too often.
Don't produce anything yet, I'm waiting to approve the proposal.

I approve the structure proposal with these changes: [notes]. Build
the brochure in Affinity as a new document: A5 portrait, 10 pages,
3 mm bleed, 12 mm margins. Take colors and fonts from brand-voice.md;
if a font from the manual isn't installed on the system, tell me and
propose a replacement — don't pick one yourself.

Go spread by spread: always lay out text and photos, show me a
preview, and wait for approval before continuing. Take copy from the
materials and adapt it per brand-voice.md; don't invent anything —
where copy is missing, leave a placeholder box marked MISSING and
give me a list of them at the end.
Set the price list as a table sourced from pricelist.xlsx; don't
retype the numbers by hand, pull them from the file.

Corrections after the first proofread:
- on page 4, swap the photo for [filename], it's sharper
- the price list item [name] changed: I've uploaded a new
  pricelist.xlsx, reload it and regenerate the table
- the headline on page 7 is off-tone; propose three variants per
  brand-voice.md and wait for me to pick one
Show me a preview of each changed page before you save the file.

The brochure is approved. First, save the native file
brochure-2026.af into the project folder — that's the source file
we'll be editing in six months, it must not get lost.
Then export a print PDF per the printer's requirements [paste
verbatim from the printer's email — usually PDF/X, CMYK, 3 mm bleed,
crop marks, 300 DPI] and a separate light PDF for email (RGB, small
file size).
Finally, print a checklist: page size, bleed, page count, fonts
used, and whether they're embedded in the PDF.

I'm a complete beginner — this is my first time working with a
terminal and with git. Before you run any command in this session,
explain in one sentence what it does and what will change on disk or
on GitHub. For commands that delete or overwrite something, flag it
to me explicitly. When something goes wrong, explain the error
message in plain language and propose next steps.

Set up a new git repository company-brand with this structure:
- brand-voice.md (insert the attached file)
- logos/ (attached SVG and PNG files)
- colors-fonts.md (pull color values and font names from the
  attached brand manual, and note where each color is used)
- README.md: what the repository is for, and the rule that
  brand-voice.md is the single source of truth — anyone who wants a
  tone change proposes it here
Add a .gitignore that excludes .env files, keys, and working
exports. Before the first commit, print me the full list of files
you're about to commit — I'll check that nothing sensitive is in
there.
Set up the repository as private.

I'm connecting a domain [roastery-marta.cz] to my Vercel project.
Vercel shows me these DNS records to set up: [paste the values from
Vercel]. My domain is with the registrar [name], and in its admin
panel, DNS section, I see this: [describe or paste what you see].
Walk me through it step by step: which fields to fill in with what,
what to delete or leave alone, and how I'll know it's working. Flag
it if anything you see looks like it could break email on the
domain.

In the website project, use brand-voice.md from the company-brand
repository as the source of tone. Specifically:
1. Propose the simplest way to bring it into the website project and
   keep it current [a copy with an update script, a git submodule…]
   — explain the difference and recommend the option for a small
   team
2. Then go through all the website's copy and list sentences that
   conflict with brand voice: forbidden phrases, wrong form of
   address, off-tone language
3. Only propose fixes, don't write them — I'll go through them one
   at a time

Before we deploy a new version of the website: compare all the copy
in the content directory against brand-voice.md and return a table:
file, sentence, rule broken, suggested fix. Flag separately any spot
where a rule works against clarity or the page's SEO needs — I'll
decide those.
Don't report “all clear” until you've printed how many files you
actually went through.

We're building an internal CRM for our roastery's wholesale
customers on Supabase. Propose a database schema: tables customers,
contacts, orders, notes. For each table, write Row Level Security
policies right away — RLS must be on from the first migration, not
added later:
- a signed-in team member can read everything; only the admin role
  can delete
- a signed-out user sees nothing
- the service key is used exclusively in server-side code; only the
  anon key, restricted by RLS policies, goes to the browser
Generate SQL migrations, and add a comment to every policy stating
exactly what it allows and for whom. Before you run anything, explain
the migrations to me as someone who doesn't read SQL daily — I'll
approve each one separately.

Play the attacker: you have our Supabase project's anon key (by its
nature, it's public in the website's code) and you know the database
schema. List every query you'd try to reach customer data without
signing in, or, with an ordinary account, to reach data you're not
entitled to.
For each query, state whether the current RLS policies stop it and
why. Where you're not sure, propose a specific test — we'll run it
against the test project with made-up data, not against live data.

Rules: you may read from the CRM, you never write to it, and you
never send anything.
Every Monday, go through the last three months of orders and prepare
for me:
- wholesale customers whose orders dropped more than a third against
  their usual average
- customers who haven't ordered in more than 6 weeks
- for each one, a draft of a short follow-up email in our tone per
  brand-voice.md, with a specific reason for reaching out
The output is a table of drafts. I decide who gets written to, and I
send it myself.

Here's the list of subscriptions the company pays for around AI and
the website: [Claude, Vercel, Supabase, Brevo, domain — fill in
tiers and prices from recent invoices]. Check current pricing for
these services online and compare: are we paying for a tier we
don't use anywhere (limits, features)? Is there an annual billing
option for any of them that would pay off? Has any service raised
its price against what I have noted?
Return a table: service, what we pay, what we could pay, what to do
about it. Don't cancel anything and don't sign into anything —
decisions and clicks are mine.

Using the Canva connector, create a design for an eight-page brochure
for cafés: colors and fonts per the attached brand-voice.md, copy
from the attached materials, photos I've already uploaded to the
Brochure folder in Canva.
Generate a first version and send me a link to the design — I'll
finish the details right in the Canva editor. Don't rewrite the
copy in your own words, stick to the materials; where copy is
missing, leave a placeholder box with a note.
Once I approve the design, export a print PDF with bleed.

Do a security review of the whole project before we make anything
public:
1. Go through the git history of the repositories (brand, website,
   crm) and look for anything that looks like a key, password, or
   token — including in old commits
2. Confirm .env files are in .gitignore, and that the Supabase
   service key never makes it into code that runs in the browser
3. List the environment variables set in Vercel and flag which of
   them are public (reach the browser)
4. Confirm preview deploys of the website have protection turned on
Return findings ranked by severity, each with a suggested fix.
Don't fix anything without my approval.