| name | brand-guidelines |
| description | Apply comprehensive brand style guidelines to all project work including UI components, code, documentation, and user-facing content. Use when creating or editing Angular components, HTML/CSS, TypeScript code, writing copy, documenting features, or any customer-facing materials to ensure brand consistency. |
| allowed-tools | Read, Edit, Write, Grep, Glob |
Brand Style Guidelines
Apply consistent brand standards across all aspects of the Angular project.
When to Use
Automatically invoke this skill when:
- Creating new Angular components, modules, or services
- Writing user-facing text (labels, errors, help text, notifications)
- Editing existing components for consistency
- Creating or updating documentation
- Writing TypeScript code (to follow naming and structure conventions)
- User explicitly requests brand compliance check
Instructions
Step 1: Identify Work Type
Determine what needs brand guidelines:
- UI/Visual: Angular components, templates, CSS/SCSS, styling
- Copywriting: Headings, body text, CTAs, messages
- Code: Components, services, modules, interfaces, file structure
- Documentation: README, API docs, guides, comments
Step 2: Load Relevant Guidelines
Read the appropriate reference files from reference/:
visual-ui.md- Colors, typography, spacing, componentswriting-tone.md- Voice, terminology, messagingcode-conventions.md- Naming, structure, Angular patternsdocumentation.md- Format, style, organization
Step 3: Apply Guidelines
For UI/Visual Work
- Use only approved brand colors from palette
- Apply correct typography hierarchy and font families
- Follow spacing system (8px grid)
- Use established component patterns
- Ensure WCAG AA accessibility compliance
For Copywriting
- Match brand tone of voice (professional yet approachable)
- Use approved terminology consistently
- Write clear, action-oriented copy
- Address users directly ("you")
- Keep language concise and specific
For Code
- Follow Angular style guide and naming conventions
- Use consistent file and folder structure
- Apply established architectural patterns (services, guards, interceptors)
- Write self-documenting code with clear intent
- Add JSDoc comments for public APIs
For Documentation
- Follow standard document structure
- Use consistent formatting and headers
- Include required sections (Purpose, Usage, Examples)
- Write for the intended audience
- Keep examples current and tested
Step 4: Use Templates
Start from templates when creating new artifacts:
templates/component-template.component.tsfor Angular componentstemplates/service-template.service.tsfor servicestemplates/documentation-template.mdfor docs
Step 5: Validate Compliance
Run through the checklist:
- ✓ Visual elements match brand system
- ✓ Copy matches tone and terminology
- ✓ Code follows Angular conventions
- ✓ Documentation is complete and formatted correctly
- ✓ Accessibility standards met
- ✓ Consistent with existing project patterns
Quick Reference Rules
Visual
- Colors: Use CSS custom properties (
var(--primary-color), not hex codes directly) - Typography: Follow hierarchy (H1: 32px, H2: 24px, Body: 16px)
- Spacing: Multiples of 8px only
- Components: Reuse existing, don't recreate
Writing
- Voice: Clear, helpful, professional yet friendly
- Structure: Active voice, verb-first CTAs
- Terminology: Consistent (see writing-tone.md)
- Length: Concise and scannable
Code
- Naming:
- Components: PascalCase with suffix (e.g.,
UserProfileComponent) - Services: PascalCase with suffix (e.g.,
AuthService) - Files: kebab-case (e.g.,
user-profile.component.ts)
- Components: PascalCase with suffix (e.g.,
- Organization: Feature-based module structure
- Comments: JSDoc for public APIs, explain "why" not "what"
- Patterns: Follow Angular best practices
Documentation
- Structure: Purpose → Usage → Examples → API
- Code blocks: Syntax-highlighted with language tags
- Links: Relative paths for internal docs
- Updates: Keep in sync with code changes
Examples
See examples/before-after.md for concrete transformations across all guideline types.
Troubleshooting
Issue: Existing code doesn't match guidelines
- Solution: Refactor incrementally, prioritize user-facing areas
Issue: Guidelines conflict with technical requirements
- Solution: Document exceptions with reasoning
Issue: Unclear which guideline applies
- Solution: Check reference files or ask for clarification
Validation Checklist
Before completing any work:
- Follows visual/UI guidelines
- Copy matches brand voice
- Code adheres to Angular conventions
- Documentation is complete
- Consistent with existing patterns
- No accessibility issues
- User-facing content reviewed