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

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

Turn this into a Brand Voice document in markdown, structured as:
1. Who we are and who we're talking 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 phrases we use (including technical ones —
   variety names, roast levels) and how we write numbers and units
4. Forbidden phrases: what we never say, with the reason why
5. Examples: 3 "not like this / like this" pairs for a product
   description, a customer email, and a social media post

Base this only on the uploaded materials. Where the materials
disagree with each other, list it as an open question at the end —
don't decide for me.

Go through the Brand Voice document we created 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:
- informal vs. formal address across different channels
- humor: how much the website can carry, how much email, how much
  a sales proposal
- how we talk about competitors
- how we sound in an unpleasant situation (complaints, price
  increases, delayed deliveries)
Ask me one question at a time and work my answers straight into
the document.

Here's our Brand Voice document [paste it] and here are three
writing briefs that aren't 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 note:
which rules you weren't sure about because they can be read two
ways, and how you chose. Those are exactly the spots we'll tighten
up in the document.

Work over the folder brochure-2026. It has a photos subfolder (a
shortlist I like — deliberately more than I need), price-list.xlsx,
and a copy folder with materials. Our tone is in brand-voice.md.

Do an inventory: list what's in the folder, and propose the content
of a ten-page print brochure for the cafés that buy coffee from us.
For each page, give: its purpose, the main message, which photos are
candidates (file names), and where the text will come from. Pick
fewer photos than I'd expect — one strong shot per page beats a
collage. For the price list, suggest which items belong in the
printed 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 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
suggest a replacement — don't pick one yourself.

Work spread by spread: place 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 text
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 from
price-list.xlsx; don't retype the numbers by hand, read them from
the file.

Edits after the first proofread:
- on page 4, swap the photo for [file-name], it's sharper
- the [item] entry changed in the price list: I've uploaded a new
  price-list.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 every changed page before you save the file.

The brochure is approved. First save the native file
brochure-2026.af to 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 separately a lightweight PDF for email
(RGB, small size).
Finally, print a checklist: page dimensions, bleed, page count,
fonts used, and whether they're embedded in the PDF.

Create 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, note the usage for each color)
- README.md: what the repository is for, and the rule that
  brand-voice.md is the single source of truth — whoever 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 complete list of
files you're about to commit — I'll check that nothing sensitive is
in there.
Create the repository as private.

In the website project, use brand-voice.md from the company-brand
repository as the source of tone. Specifically:
1. Suggest the simplest way to get 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 copy and list sentences that
   conflict with the brand voice: forbidden phrases, wrong form of
   address, off-tone wording
3. Only propose fixes, don't write them in — I'll go through them
   one at a time

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

We're building an internal CRM for our roastery's wholesale
customers in Supabase. Design the database schema: tables for
customers, contacts, orders, notes. For each table, write the Row
Level Security policies right away — RLS must be on from the first
migration, not added later:
- a logged-in team member can read everything; only the admin role
  can delete
- a logged-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 the SQL migrations and add a comment to every policy
explaining exactly what it allows and for whom. Before you run
anything, explain the migrations to me as if I don't read SQL every
day — I'll approve each one separately.

Play the attacker: you have the anon key of our Supabase project
(it's public in the website code by nature) and you know the
database schema. List every query you'd try to get at customer data
without logging in, or with a regular account to get at data it
isn't allowed to see.
For each query, say whether the current RLS policies stop it and
why. Where you're not sure, propose a concrete 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 write nothing to it, and you
send nothing. Every Monday, go through the last three months of
orders and prepare for me:
- customers whose orders have dropped by more than a third compared
  to their usual average
- customers who haven't ordered in over 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 to write to, and I
send it myself.

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, I've already
uploaded photos to the Brochure folder in Canva.
Generate a first version and send me a link to the design — I'll
fine-tune the details directly in the Canva editor. Don't rewrite
the copy in your own words, stick to the materials; where text 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 publish
anything:
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 that .env files are in .gitignore and that the Supabase
   service key never ends up in code that runs in the browser
3. List the environment variables set in Vercel and flag which ones
   are public (reach the browser)
4. Confirm that the website's preview deployments have protection
   turned on
Return the findings sorted by severity, each with a suggested fix.
Don't fix anything without my approval.