| name | new-project |
| description | Initializes a new BrandArtisan visuals project by laying down its reference guidelines. Use when the user wants to create/add a new project, start a new brand or a new visual identity ("new project", "add project X", "set up brand Y"). Creates brands/<project>/brand.md (mandatory before any visual) and the templates/<project>/ folder. |
new-project: bootstrapping a visuals project
Goal: lay down the two references of a new project in brands/<project>/:
brand.md (visual identity, blocking: no visual without it) and project.md
(substance and voice, for writing the text). A CLAUDE.md rule.
1. Determine the <project> slug
Take it from the arguments. Otherwise ask. It is a kebab-case slug (e.g.
calame, my-app). Check that it does not already exist: brands/<project>/ or
templates/<project>/. If it does -> stop, say so.
2. Collect the guidelines (invent nothing)
Interview the user. Never invent colors, type or logo: that is the heart of
the project rule. Collect at least:
- Concept / meaning of the logo and the name.
- Typography: typeface, weight, source. Note: the available families and
weights are those present in
fonts/, discovered automatically by the engine.
If the guidelines require another font absent from fonts/, follow the
Missing font procedure below: offer to pre-install it now, or let
/new-template fetch it for the first visual that needs it.
- Palette: for each role, the hex (+ Tailwind landmark if known) and the
usage.
- Logo / favicon variants available and when to use them.
- Usage rules and don'ts.
Collect the substance too (for project.md): a one-sentence pitch, what the
product does, audience and language, value proposition, editorial voice
(register, how it addresses the reader), vocabulary (exact name, URL) and
forbidden claims (don't invent figures).
If the user does not have everything yet, write down what is known and mark the
gaps with _(to be defined)_ rather than filling them at random.
3. Write brands/<project>/brand.md
Mirror the structure of brands/calame/brand.md (that is the reference):
- Title
# Brand guidelines: <Project> + a short intro.
## 1. Concept and meaning (with Typography and Colors subsections).## 2. Variants (logotype, favicon/icons) if applicable.## 3. Usage rules (clear space, minimum size, backgrounds, Don't).## 4. Regeneration only if some assets are generated by a script.
The logo and favicon files live next to it, in brands/<project>/logo/ and
brands/<project>/favicon/. Don't create fake assets: if the user has files,
tell them where to drop them. If the assets are to be generated by a script
(like Calame's), that is the brand-assets skill's job.
3b. Write brands/<project>/project.md
Mirror the structure of brands/calame/project.md (that is the reference):
# Project: <Project> + a short intro (what the file is for).## 1. In one sentence (the pitch).## 2. The product (what it does, the differentiator).## 3. Audience (personas, market, language).## 4. Value proposition (benefits, by priority).## 5. Editorial voice (register, how it addresses the reader, format, do/don't).## 6. Vocabulary & claims (exact name, URL, approved lines, forbidden
claims: no invented figures).
Same rules as for brand.md: invent nothing, mark the gaps with
_(to be defined)_ or _(to be confirmed)_.
4. Create the templates tree
Create the templates/<project>/ folder (it will hold the .tsx files).
5. Wrap up
Recap what was created and what is still _(to be defined)_ in the guidelines.
Point to what comes next: /new-template <project> <name> for the first visual.
Success criterion: brands/<project>/brand.md and
brands/<project>/project.md exist, follow the reference structure, and contain
no invented color, type or claim (gaps marked _(to be defined)_).
Missing font (procedure)
If the guidelines require a font that is not in fonts/:
- Ask for permission to fetch it: this is an outbound network action, never
silent. Name the source and the license before downloading.
- Trustworthy source, ttf/otf format (Satori does not read woff2): the raw
.ttf from the official repo (github.com/google/fonts) or an
@fontsource/<font> package. Most Google Fonts are OFL/Apache -> fine. A
proprietary font or an ambiguous license -> refuse and ask the user to
provide the file themselves.
- Download to
fonts/<Family>-<weight>.ttf, using curl -L <url> -o ...
or Invoke-WebRequest -OutFile. WebFetch is not suitable (binary). The file
name is authoritative: it determines the family the templates cite, in
PascalCase (GeistMono-600.ttf -> Geist Mono, 600).
- Check the file: non-zero size and a real font header (
.ttf starts with
00 01 00 00, OpenType with OTTO), not an HTML error page in disguise.
- Document the license: drop its text into
fonts/ and add the matching
row to the table in fonts/NOTICE.md. No code declaration: the engine
discovers the file at startup, provided its name follows the
<Family>-<weight>.ttf convention from step 3.
- Confirm before committing the
.ttf (a binary) with the user.
If the user refuses -> do not pre-install; note in the guidelines that the font
is _(to be provided)_ and let /new-template ask the question again.
