building-brand-guidelines
Skill1 starsChanged 3 months agoMITView on GitHub
Use when an approved brand identity needs durable rules, assets, examples, accessibility constraints, and governance so multiple people can reproduce it consistently across channels.
In this repository65 other files it gives its agents.
- analyzing-change-blast-radiusSkill
- analyzing-developer-career-opportunitiesSkill
- art-directing-web-interfacesSkill
- assessing-developer-proficiencySkill
- auditing-dependency-riskSkill
- auditing-pixel-perfect-frontendSkill
- bootstrapping-modern-web-appsSkill
- brag-slimSkill
- building-conversion-product-pagesSkill
- building-developer-career-roadmapsSkill
- building-hybrid-game-assetsSkill
- building-premium-nextjs-interfacesSkill
- building-project-showcasesSkill
- building-regression-testsSkill
- building-reliable-node-api-boundariesSkill
- choosing-application-architectureSkill
- craft-premium-motionSkill
- creating-character-sprite-pipelinesSkill
- defining-brand-strategySkill
- designing-action-combatSkill
- designing-developer-portfolio-evidenceSkill
- designing-relational-data-modelsSkill
- designing-software-boundariesSkill
- designing-test-strategiesSkill
- designing-ui-systemsSkill
- designing-visual-identitiesSkill
- documenting-architecture-decisionsSkill
- editing-for-clarity-and-toneSkill
- engineering-gsap-animationsSkill
- evaluating-developer-proficiencySkill
- evolving-postgres-schemas-safelySkill
- humanizing-generated-proseSkill
- implementing-reference-faithful-uiSkill
- investigating-codebase-semanticallySkill
- managing-implementation-slicesSkill
- mapping-existing-codebase-structureSkill
- naming-brands-and-productsSkill
- optimizing-frontend-motion-performanceSkill
- orchestrating-cinematic-web-motionSkill
- planning-codebase-changes-with-evidenceSkill
- planning-engineering-workSkill
- planning-launch-distributionSkill
- planning-safe-refactorsSkill
- planning-written-communicationSkill
- preparing-project-launchSkill
- profiling-postgres-query-performanceSkill
- reconstructing-images-as-threejsSkill
- reviewing-api-securitySkill
- reviewing-apple-platform-interfacesSkill
- reviewing-pull-requestsSkill
- reviewing-web-securitySkill
- selecting-working-methodsSkill
- shipping-github-vercel-changesSkill
- teaching-developer-conceptsSkill
- testing-integration-boundariesSkill
- testing-playable-gamesSkill
- testing-web-applications-end-to-endSkill
- threat-modeling-applicationsSkill
- tracing-code-execution-pathsSkill
- translating-figma-to-nextjsSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
Start with the brand principles that explain the system.
- Distinctive: line 14
Document identity assets and hierarchy: primary/secondary marks, wordmarks, clear space, minimum sizes, background behavior, and approved …
- Distinctive: line 17
Document composition and supporting language: grids, spacing, graphic devices, imagery/illustration treatment, iconography, motion …
- Distinctive: line 20
Add operational guidance: file naming, source-of-truth locations, ownership, version/date, exception process, and how changes are approved.
- Distinctive: line 21
Test the guide by giving it to someone who did not create the identity and asking them to produce a representative artifact.
- Distinctive: line 40
Run a guideline usability test: ask a new collaborator to create one routine and one edge-case artifact using only the guide and canonical …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Building Brand Guidelines
Core principle
Brand guidelines are an operating manual for consistent decisions, not an archive of presentation slides. Document the minimum rules and examples needed for another person to reproduce the identity without guessing.
Guideline workflow
- Define the audience and use cases for the guide. A small internal team, distributed marketing organization, partners, and vendors need different levels of detail.
- Start with the brand principles that explain the system. Rules are easier to apply when users understand the strategic intent behind them.
- Document identity assets and hierarchy: primary/secondary marks, wordmarks, clear space, minimum sizes, background behavior, and approved asset sources.
- Define typography as a working system. Include families, roles, hierarchy, weights, fallback behavior, licensing or availability constraints, and representative layouts.
- Define color by role, not just swatch. Record values for relevant media, accessible text/interface combinations, and cases where color must not be the only carrier of meaning.
- Document composition and supporting language: grids, spacing, graphic devices, imagery/illustration treatment, iconography, motion principles, and any recurring production patterns.
- Connect verbal guidance. Summarize or link the approved voice, messaging hierarchy, terminology, and tone rules rather than duplicating conflicting copy standards.
- Show both correct and incorrect applications using realistic examples. Prioritize mistakes people are actually likely to make.
- Add operational guidance: file naming, source-of-truth locations, ownership, version/date, exception process, and how changes are approved.
- Test the guide by giving it to someone who did not create the identity and asking them to produce a representative artifact.
Guideline quality checks
The guide should let a collaborator answer:
- Which asset should I use here?
- How should this hierarchy behave at this size?
- Which color combinations are permitted for meaningful text or interface states?
- What is flexible versus invariant?
- Where is the canonical asset?
- Who decides when a new pattern becomes part of the system?
Avoid
- hundreds of decorative pages with little production guidance;
- undocumented “designer judgment” for recurring decisions;
- logo misuse examples without rules for the rest of the system;
- inaccessible color pairings hidden behind brand aesthetics;
- stale PDFs that have no owner, version, or source of truth.
Verification
Run a guideline usability test: ask a new collaborator to create one routine and one edge-case artifact using only the guide and canonical assets. Record where they must guess; those gaps are missing rules or examples.
References
- Design Council, public brand guidelines: https://www.designcouncil.org.uk/who-we-are/press/
- W3C WAI, use of color: https://www.w3.org/WAI/WCAG21/Understanding/use-of-color
- W3C WAI, non-text contrast: https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

