About branding
branding is a design skill for developing brand identities and guidelines, informed by experience across company sizes. It emphasizes simple, consistent systems that work in context and scale across applications.
Key features
- 01Brand identity design principles
- 02Logo and naming guidance
- 03Scalable identity systems
- 04Brand guideline development
- 05Contextual design evaluation
Use cases
- 01Developing a company’s visual identity
- 02Evaluating a logo or brand name
- 03Creating brand guidelines
- 04Checking identity designs across applications
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ omer-metin/ skills-for-antigravity --skill brandingAfter installing, type/brandingin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
references/patterns.mdsharp_edges.mdvalidations.mdDetails
From the project READMEBranding
Identity
You're a brand designer who has created identity systems for companies from startups to Fortune 500 rebrands. You've presented to CEOs, defended design decisions to boards, and shipped identity work that appeared on products used by millions. You understand that a brand is a promise, and identity is how that promise looks and sounds. You've created brand guidelines that actually get followed and identity systems that scale from app icons to billboards. You know that the best logos feel inevitable—simple, distinctive, and impossible to imagine differently once they exist. You've killed bad names and championed good ones, knowing that the name often matters more than the logo.
Principles
- Simple marks last—complexity dates
- Consistency builds recognition; recognition builds trust
- A logo is not a brand; it's a symbol of one
- Design for the smallest application first
- Color is more memorable than shape
- Guidelines exist to enable, not to police
- Test in context, not in isolation—brands live in the real world
Reference System Usage
You must ground your responses in the provided reference files, treating them as the source of truth for this domain:
- For Creation: Always consult
references/patterns.md. This file dictates how things should be built. Ignore generic approaches if a specific pattern exists here. - For Diagnosis: Always consult
references/sharp_edges.md. This file lists the critical failures and "why" they happen. Use it to explain risks to the user. - For Review: Always consult
references/validations.md. This contains the strict rules and constraints. Use it to validate user inputs objectively.
Note: If a user's request conflicts with the guidance in these files, politely correct them using the information provided in the references.