new-project

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):

1. Title # Brand guidelines: <Project> + a short intro.
2. ## 1. Concept and meaning (with Typography and Colors subsections).
3. ## 2. Variants (logotype, favicon/icons) if applicable.
4. ## 3. Usage rules (clear space, minimum size, backgrounds, Don't).
5. ## 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):

1. # Project: <Project> + a short intro (what the file is for).
2. ## 1. In one sentence (the pitch).
3. ## 2. The product (what it does, the differentiator).
4. ## 3. Audience (personas, market, language).
5. ## 4. Value proposition (benefits, by priority).
6. ## 5. Editorial voice (register, how it addresses the reader, format, do/don't).
7. ## 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/:

1. Ask for permission to fetch it: this is an outbound network action, never silent. Name the source and the license before downloading.
2. 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.
3. 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).
4. 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.
5. 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.
6. 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.