Make Every AI Deliverable Feel Like Your Brand

Why this guide exists

See the change before you build anything.

What work feels like now

Your brand lives in files, habits, and one person's head.

The logo and colours are easy to find, but the real design judgment is not written down.
Decks, documents, sheets, and web pages drift because each format starts again.
AI makes production faster while making the brand less recognizable.

What good looks like

One approved foundation guides every format.

Voice, type, colour, layout, imagery, and asset rules live in one portable system.
Each format gets its own practical rules instead of a generic template.
Real deliverables are rendered, checked, and corrected before the system is trusted.

Start with one prompt

Claude asks the questions, sets it up, and proves it with you.

Copy this into a new Claude conversation

One prompt runs the whole setup.

Paste this into a new Claude conversation and provide only brand material you are allowed to use. Claude will find the gaps, build one brand foundation, adapt it to your main formats, test real examples, and improve the first deliverable with you.

Read the full prompt before copying

Guide me through building an AI-ready brand system from source review to a tested real deliverable. You own the setup sequence and keep all authority decisions in this conversation. Do not make me copy another prompt. Use five phases: Interview, Connect, Build, Test, Run. Show the current phase and one decision at the top of each reply. Inspect approved files before asking me to restate what they show. Explain any Claude feature I may not recognize in one plain sentence. INTERVIEW Ask at most seven questions, one at a time. Map: 1. My Claude surface and where the system should live: Custom Skill, Cowork folder, Project, or downloadable files. 2. The business, audience, promise, desired feeling, voice, proof, and explicit anti-goals. 3. Which assets and rules are Canonical, Approved example, Direction only, Deprecated, Unknown, or Missing. 4. Logo, colour, type, imagery, icon, accessibility, rights, and writing constraints, including conflicts between sources. 5. The few visual modes the brand genuinely needs and the conditions for choosing each one. 6. The first destinations, reusable patterns, native requirements, and exact proof deliverables. 7. Who approves changes, how versions are named, how a rule becomes canonical, and what must remain editable. Then show one compact system brief, authority hierarchy, source-conflict table, gap list, destination map, and three proposed proof builds. Ask for the single most important correction. AFTER I APPROVE THE BRIEF Continue through Connect, Build, Test, and Run in this conversation. Create a bounded source manifest. Never reconstruct a missing logo, claim rights you cannot verify, substitute an unlicensed font silently, or treat an attractive example as canonical. Build and install the package for my chosen surface. Show the authority hierarchy, token plan, and file manifest before writing. Run all three proof builds in their actual destination formats. Render and inspect the outputs, correct system rules rather than patching one artifact, and rerun failed proofs. For the first real deliverable, show the brief, visual route, authoritative sources, missing assets, and approval points. Create it in the destination-native format, inspect it there, correct major issues, and finish with a proof record plus any proposed system change for approval.

What happens next

You answer a few short questions. Claude carries the work through these five stages and pauses when it needs your review.

What finished means

You are finished when three real formats pass their checks and one new deliverable can be traced back to approved assets and rules.

Typical setup

About 35 minutes to map and set up, then three proof builds and one reviewed real deliverable.

01Interview
The approved brand sources, formats, and missing decisions.
02Connect
One trusted source set with ownership and current versions clear.
03Build
Your brand guide, format rules, reusable patterns, and change record.
04Test
Three real formats passed after corrections.
05Run
One real deliverable checked in the app where it will be used.

Want the details?

Open only the stage you need. These are explanations and recovery points, not five more tasks to complete.

Answer a short interview

Claude learns what good work looks like for you before it builds anything.

What to expect

The interview is concise and stays in one conversation. Claude reuses what you have already said, offers “Not sure” when that is a valid answer, and shows you a short blueprint before making anything.

Connect only the apps you need

Claude checks each required action safely and keeps a manual option when access is limited.

Claude should build a source manifest before connecting anything. Start with uploads or a focused folder. Add a design or destination tool only when a named proof requires it, and verify exact read, create, edit, render, and export capabilities separately.

Resume here if needed

Resume my brand-system setup at Connect using the approved brief. Create a source manifest with: item, role, authority, owner, rights, version or date, format, location, approved uses, and conflicts. Use only Canonical, Approved example, Direction only, Deprecated, Unknown, or Missing. Guide me through uploaded files or one bounded source at a time. Never ask for credentials in chat. If a connector is useful, explain the exact folder, library, file, or destination capability required. Test one named source and one disposable output. Record the observed result, not the connector promise. For unavailable capabilities, define a safe export, upload, local render, or manual inspection fallback. Do not broaden access or use computer control without asking. Finish with the manifest, capability matrix, unresolved conflicts, and one correction question before Build.

Brand source folder

Why: Provide approved identity assets, guidelines, voice sources, and reference work.
Start safely: Create a focused read-only source pack. Label each item canonical, reference, direction, deprecated, or unknown.
Proof: Claude produces an accurate asset manifest and flags conflicts instead of choosing silently.

Design source

Why: Read components, tokens, or layouts from the tool where the strongest current system lives.
Start safely: Connect a bounded library or export. Preserve the original and record the source version or date.
Proof: Named colours, type, spacing, and components match the approved source.

Production destinations

Why: Create and inspect web, slides, documents, spreadsheets, or campaign assets in their real formats.
Start safely: Use test files or copies. Do not replace published pages, shared templates, or approved assets.
Proof: Each proof opens in the named destination and preserves the required structure, editability, and brand rules.

Build the reusable setup

Claude creates the instructions, examples, templates, and review rules behind the result.

Resume here if needed

Resume my brand-system setup at Build. Use the approved brief, source manifest, and capability matrix. Build for the installation path we approved. For a Custom Skill, create an installable brand-production ZIP with the folder at its root and a valid SKILL.md. For Cowork, write only inside the approved folder. For a Project, provide project instructions and exact knowledge files. Without file access, provide downloadable files and a ZIP. Create a portable core with plain-language brand foundations, semantic design tokens, an authority-aware asset manifest, voice rules, visual modes, reusable component and composition patterns, accessibility rules, destination adapters, quality gates, proof templates, setup instructions, and a change log. Keep the core independent of one vendor. Keep destination-native rules in adapters. Show the authority hierarchy, file manifest, token naming model, install plan, and any unresolved gap first. Ask for approval before writing or packaging. After approval, create the files, validate every reference and asset path, package the installable version, guide me through enabling it, and run a trigger smoke test. Do not invent assets, rights, claims, fonts, examples, or destination capabilities.

brand-production/SKILL.md

Valid metadata, triggers, source authority, route selection, build, critique, correction, and proof.

brand-production/references/foundation.md

Audience, promise, evidence, voice, visual principles, modes, and anti-goals.

brand-production/references/tokens.json

Canonical machine-readable semantic tokens and approved modes.

brand-production/references/assets.md

Authority, rights, versions, locations, alt text, uses, conflicts, and gaps.

brand-production/patterns/

Reusable components and compositions with anatomy, variants, states, bad examples, and access notes.

brand-production/adapters/

Native rules and proof methods for the approved web, slide, document, sheet, PDF, or campaign destinations.

brand-production/tests/qa-rubric.md

Identity, hierarchy, geometry, accessibility, destination, editability, and evidence gates.

brand-production/SETUP.md

Installation, required assets, trigger test, rendering tools, fallbacks, and removal steps.

brand-production/CHANGELOG.md

Versioned system changes tied to proof failures and explicit approvals.

Test it before real work

Claude tries normal, incomplete, and difficult examples, then fixes what fails.

Resume here if needed

Resume my brand-system setup at Test. Confirm that the installed skill or instructions load, then create the three proof builds from this guide using approved sources and disposable destinations. For each proof, record: brief, destination, authoritative sources, selected mode, expected checks, rendered output, native inspection, observed failures, pass or fail, system correction, and rerun result. A valid file or successful export is not a pass. Inspect identity, hierarchy, typography, colour, imagery, voice, geometry, accessibility, editability, source fidelity, and destination fit. Compare all three proofs together so they feel related without forcing one layout across formats. Correct tokens, patterns, adapters, or source authority in the package rather than patching only the artifact. Increment the version after approved system changes and rerun affected proofs. Finish only when all three pass in their named destinations and the proof record identifies any remaining human-only checks.

Compact document

Create a two-page client brief from approved copy and one brand image.

Pass when

The hierarchy, typography, colour, image treatment, and voice are recognizable and the PDF is inspected, not merely generated.

Presentation or proposal

Turn one real business story into a short, editable presentation with at least three distinct layout needs.

Pass when

The deck feels like one authored sequence, remains editable where required, and survives native visual review.

Responsive or campaign surface

Create a web section or campaign asset family using the same source material and system.

Pass when

The result feels related to the document and presentation without copying one layout or weakening responsive behaviour.

Run it with review

You use one simple request, review the prepared work, and approve only the actions you want.

Use after setup

Use my installed brand-production system to create [deliverable] for [audience and job]. The approved sources are [files or links], the destination is [format or tool], and the reader action is [outcome]. Before building, show the brief, visual route, selected mode, authoritative sources, destination adapter, missing assets, and approval points. Stop if a required canonical asset, right, claim, or destination capability is unresolved. Create a destination-native result in a new test or draft location. Render and inspect the full output, compare it with the three proof builds, correct major issues, and verify editability and accessibility in proportion to the format. Do not replace a published page, shared template, or approved asset. Return the final artifact and a proof receipt with sources, checks, corrections, remaining human review, and any proposed system change. Add that change only after I approve it.

Do not call the first run complete until

The installed system used only approved assets, rules, rights, and claims.
The deliverable was rendered and inspected in its named destination.
Identity, hierarchy, accessibility, editability, and source fidelity passed the relevant gate.
The new work relates to the proof set without copying one layout across formats.
The proof receipt is complete and any canonical system change was approved and recorded with evidence.

Current setup references

Anthropic custom skill setup and testing Anthropic file creation capabilities Anthropic safe Cowork use

Keep control

Review the parts that matter.

Use only approved logos, fonts, photography, claims, and reference work. Label conceptual or generated material clearly.
Keep one canonical source for tokens and rules. Treat tool-specific libraries and templates as adapters, not competing authorities.
A valid file is not proof of quality. Inspect the exact web, PDF, presentation, document, or spreadsheet output in its destination.