Create Your Own Brand Design System for Claude Code in One Prompt (No Packages, No Config)
Adapt any of the 57 Awesome Design MD systems to your own colors and fonts. Save as my_brand_design.md and Claude uses it instantly.
One Prompt Gives Claude Code a Design System That’s Actually Yours
Claude Code can read the Notion design system as plain markdown context and produce pixel-consistent output across every file you generate — but Notion’s colors belong to Notion. The fix is a single prompt: I love the notion design system structure, but I want my brand colors: dark navy background, gold accent, white text. Adapt this and save it as my_brand_design.md. That’s it. No npm packages, no configuration files, no dependencies to break. Claude rewrites the entire file to your spec and saves it to your project.
This is the part of the Awesome Design MD workflow that most coverage skips. Everyone talks about the 71,000-star GitHub repo and the 57 brand markdown files. Fewer people talk about what you do after you’ve borrowed Apple’s typography or Notion’s spacing logic — which is to stop borrowing and start owning.
The Repo, Briefly
Awesome Design MD is a GitHub repo containing 57 markdown files, one per brand. Apple, Notion, Airbnb, Stripe, Uber, Anthropic/Claude, and 51 others. Each file describes a complete visual system: colors, typography, spacing, the overall feel. The repo hit 71,000 stars within weeks of launch, which puts it among the fastest-growing design tooling repos of 2025.
The install prompt is deliberately minimal: Install the awesome design MD GitHub repo for me and recommend how I can use it. Claude grabs all 57 files in roughly 30 seconds. Because these are plain markdown — not npm packages, not config files — Claude reads them as context with zero installation overhead. Nothing to configure, nothing to break.
If you want the full picture of how design.md files work as AI context, the post on Google Stitch’s design.md file and how AI design systems work covers the underlying mechanics well.
Why Borrowing Directly Is a Problem
The design systems in Awesome Design MD are descriptive, not licensed. Notion’s specific color palette — that particular off-white, that exact shade of gray — is Notion’s visual identity. Stripe’s typography choices are Stripe’s. If you ship a public landing page that looks indistinguishable from a Notion page, you’re not building a brand; you’re building confusion.
The more practical problem: consistency. If you use the Notion design system for your school page, the Apple design system for your slide deck, and the Stripe design system for your pitch deck, you have three different visual identities. That’s not a brand. That’s three borrowed aesthetics that happen to live on the same domain.
The solution is to extract the structure — the quality baseline, the spacing logic, the typography approach — and replace the visual identity layer with your own. The my_brand_design.md approach does exactly that.
How the Custom Brand Prompt Works
Here’s the full prompt again, worth reading carefully:
I love the notion design system structure, but I want my brand colors: dark navy background, gold accent, white text. Adapt this and save it as my_brand_design.md
Claude takes the Notion design system file — which it already has in context from the install step — reads the structural logic, and rewrites the entire file substituting your color values. The output is a new markdown file with Notion-level spacing and hierarchy, but your visual identity.
You can be more specific. If you have exact hex values, include them. If you want a particular font stack, say so. If you want to pull Uber’s high-contrast geometric approach instead of Notion’s clean minimalism, swap the reference. The prompt structure is the same; only the source design system and your brand parameters change.
The resulting my_brand_design.md file sits in your project directory. Every subsequent prompt that references it — school pages, slide decks, landing pages, video graphics — inherits the same visual rules. You stop making design decisions per project. The system makes them for you.
The Five Design Systems Worth Knowing Before You Customize
Before you write your custom brand prompt, you need to know which source system to adapt. The structural logic differs significantly between them, and the right choice depends on what you’re building.
Notion is the default starting point for most creators. Clean, minimal, generous whitespace. Everything has breathing room. If your content is educational — school pages, course slides, tutorial visuals — Notion’s structure is the right skeleton to adapt. The welcome page prompt Using the notion design system, design the welcome page structure for my school community about [topic] gives you a sense of what the raw system produces before you customize it.
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
Apple is for premium. Landing pages for high-ticket offers, client presentations, anything where the visual impression needs to do work before anyone reads a word. The prompt Using the Apple design system, create a five slide deck explaining AI agent outputs HTML with animations and transitions — screen-shareable directly from a browser, no PowerPoint export needed. That output quality is what you’re borrowing the structural logic from when you adapt it.
Anthropic/Claude is the outlier on the list. Warm, slightly parchment-like, deliberately different from the cold corporate aesthetic most tech brands default to. If your brand needs to feel thoughtful rather than slick, this is worth exploring as a source system.
Uber is pure black and white, geometric, maximum contrast. This is the video graphics system. High contrast reads clearly at any size on any background — charts, diagrams, animated explainers you’re showing on screen during a recording. Low-contrast design on camera is genuinely hard to read; Uber’s system solves that structurally.
Stripe is business-facing credibility. Lots of white space, serious tone, appropriate for pitch decks and anything presented to an audience that needs to be convinced you’re legitimate.
Pick the one whose structural logic matches your use case, then adapt the visual layer to your brand.
What the Output Actually Looks Like
When you run Using the Apple design system, build a single page landing page for my offer, Claude outputs an HTML file. Not a mockup, not a wireframe — a working HTML page with animations and transitions you can open in a browser and screen-share directly.
This matters because the output format sidesteps the usual friction. No PowerPoint. No Figma. No exporting, converting, or reformatting. You get a browser-renderable file that looks better than most competitor pages and cost you one prompt.
The same applies to slide decks. The Apple design system slide deck prompt produces HTML with transitions. You screen-share from Chrome. That’s the entire workflow.
Once you have my_brand_design.md in your project, every one of these outputs follows your brand rules instead of Apple’s or Notion’s. The prompt structure is identical; the visual output is yours.
The Non-Obvious Detail: Markdown as Persistent Context
Most design tools require you to learn an interface. Most templates require customization inside a platform. The Awesome Design MD approach is different: the design system is just text in your project directory, and Claude reads it as context on every subsequent prompt.
This means my_brand_design.md is genuinely portable. Copy it to a new project and your brand travels with it. Reference it in any prompt and Claude applies the rules. There’s no re-installation, no re-configuration, no platform dependency.
The same principle applies to other kinds of persistent context. The post on building a self-evolving Claude Code memory system with Obsidian covers how to extend this pattern — using hooks to capture session knowledge and build context that accumulates over time. A my_brand_design.md file is a simpler version of the same idea: structured markdown that Claude reads as authoritative context.
For teams building more complex workflows on top of this kind of context, MindStudio offers a no-code path for chaining models and integrations — 200+ AI models and 1,000+ pre-built connectors — which becomes relevant when you want brand-consistent output flowing through automated pipelines rather than individual prompts.
Mixing Systems
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
Because each brand is its own separate file, you can mix structural elements across systems. Apple’s typography with Notion’s spacing. Uber’s contrast logic with Stripe’s whitespace approach. The custom brand prompt can reference multiple source systems: I want the typography approach from Apple and the spacing logic from Notion, with my brand colors: dark navy background, gold accent, white text.
Claude has all 57 files in context. It can synthesize across them. The resulting my_brand_design.md is a hybrid that doesn’t look like any single brand — it looks like yours.
This is the actual value proposition of the repo, and it’s the part that most of the 71,000-star coverage misses. The stars are for the repo. The value is in what you build from it.
Connecting This to Larger Build Workflows
The my_brand_design.md pattern is a spec for visual output. It’s worth thinking about how it fits into larger build workflows.
If you’re building content systems — school pages, slide decks, landing pages, video graphics — at any volume, the design file is one layer of a larger stack. The post on Claude Code for content marketing and skill-based content systems covers how to chain these kinds of outputs into automated workflows. The brand file is the visual consistency layer; the skill system handles the content production layer.
For full-stack applications where the brand file needs to inform a deployed product rather than a static HTML file, the abstraction level shifts. Remy takes a different approach to this problem: you write your application as an annotated markdown spec — prose carrying intent, annotations carrying precision — and it compiles into a complete TypeScript backend, SQLite database, frontend, auth, and deployment. The spec is the source of truth; the code is derived output. A my_brand_design.md file could live inside that spec as the visual layer of a larger application definition.
The Claude Code source code leak post on the three-layer memory architecture is also relevant here — it explains how Claude Code uses memory.md as a pointer index, which is structurally similar to how my_brand_design.md functions as a persistent reference file. Understanding that architecture helps you place your brand file correctly in a project structure.
The Actual Workflow, End to End
For clarity, here’s the complete sequence:
- Install:
Install the awesome design MD GitHub repo for me and recommend how I can use it— Claude grabs all 57 files in ~30 seconds. - Preview: Ask Claude to open several design systems as HTML previews so you can compare them visually before choosing.
- Customize:
I love the [source] design system structure, but I want my brand colors: [your specs]. Adapt this and save it as my_brand_design.md - Build: Reference
my_brand_design.mdin every subsequent prompt — school pages, slide decks, landing pages, video graphics. - Iterate: When your brand evolves, update
my_brand_design.mdand every future output inherits the change.
Step 3 is the one that converts a borrowed aesthetic into a brand asset. Everything before it is setup. Everything after it is production.
One Opinion
The coverage on Awesome Design MD has focused almost entirely on the 57 brands as end destinations — use Apple’s design system, use Notion’s design system. That framing treats the repo as a template library.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
It’s more useful as a quality baseline and structural reference. The brands in the repo represent decades of design thinking about spacing, hierarchy, contrast, and typography. The my_brand_design.md approach lets you inherit that thinking without inheriting the visual identity. That’s the correct way to use it.
A template library gives you something that looks like someone else’s work. A design system gives you rules that produce consistent work that looks like yours. The single prompt difference between those two outcomes is worth understanding.
