brand-yml
This Claude Code skill provides guidance for creating and managing `_brand.yml` files that define consistent branding elements like colors, typography, logos, and company metadata for use across Shiny applications and Quarto documents. Use it when establishing brand standards, integrating branding into new or existing Shiny and Quarto projects, modifying brand specifications, or troubleshooting branding implementation issues.
git clone --depth 1 https://github.com/posit-dev/skills /tmp/brand-yml && cp -r /tmp/brand-yml/brand-yml ~/.claude/skills/brand-ymlSKILL.md
# brand.yml Skill
Create and use `_brand.yml` files for consistent branding across Shiny applications and Quarto documents.
## What is brand.yml?
brand.yml is a YAML-based format that translates brand guidelines into a machine-readable file usable across Shiny and Quarto. A single `_brand.yml` file defines:
- **Colors** - Palette and semantic colors (primary, success, warning, etc.)
- **Typography** - Fonts, sizes, weights, line heights
- **Logos** - Multiple sizes and light/dark variants
- **Meta** - Company name, links, identity information
## File Naming Convention
- **Standard name**: `_brand.yml` (auto-discovered by Shiny and Quarto)
- **Custom names**: Any name like `company-brand.yml` (requires explicit paths)
- **Location**: Typically at project root, or in `_brand/` or `brand/` subdirectories
## Decision Tree
Determine the user's goal and follow the appropriate workflow:
1. **Creating a new _brand.yml file?** → Follow "Creating brand.yml Files"
2. **Using brand.yml in Shiny for R?** → Read `references/shiny-r.md`
3. **Using brand.yml in Shiny for Python?** → Read `references/shiny-python.md`
4. **Using brand.yml in Quarto?** → Read `references/quarto.md`
5. **Using brand.yml in R (general)?** → Read `references/brand-yml-in-r.md` (R Markdown, theming functions, programmatic access)
6. **Modifying existing _brand.yml?** → Follow "Modifying Existing Files"
7. **Troubleshooting integration?** → Follow "Troubleshooting"
## Creating brand.yml Files
When creating `_brand.yml` files from brand guidelines:
### Step 1: Gather Information
Collect brand information:
- **Colors**: Primary, secondary, accent colors with hex values
- **Fonts**: Font families and where they're sourced (Google Fonts, local files, etc.)
- **Logos**: Logo file paths or URLs for different sizes
- **Company info**: Name, website, social links (optional)
### Step 2: Read the Specification
Load `references/brand-yml-spec.md` to understand the complete brand.yml structure, field options, and syntax.
### Step 3: Build the File Incrementally
Start with the essential sections and add optional elements:
**Minimum viable _brand.yml:**
```yaml
color:
palette:
brand-blue: "#0066cc"
primary: brand-blue
background: "#ffffff"
typography:
fonts:
- family: Inter
source: google
weight: [400, 600]
base: Inter
```
**Add colors as needed:**
```yaml
color:
palette:
brand-blue: "#0066cc"
brand-orange: "#ff6600"
brand-gray: "#666666"
primary: brand-blue
secondary: brand-gray
warning: brand-orange
foreground: "#333333"
background: "#ffffff"
```
**Add typography details:**
```yaml
typography:
fonts:
- family: Inter
source: google
weight: [400, 600, 700]
style: [normal, italic]
- family: Fira Code
source: google
weight: [400, 500]
base:
family: Inter
size: 16px
line-height: 1.5
headings:
family: Inter
weight: 600
monospace: Fira Code
```
**Add logos:**
```yaml
logo:
small: logos/icon.png
medium: logos/header.png
large: logos/full.svg
```
**Add meta information:**
```yaml
meta:
name: Company Name
link: https://example.com
```
### Step 4: Apply Best Practices
Follow these rules from `references/brand-yml-spec.md`:
- All fields are optional - only include what's needed
- Use hex color format: `"#0066cc"`
- Prefer simple syntax (strings over objects) when possible
- Use lowercase names with hyphens: `brand-blue`, `success-green`
- Include `https://` in all URLs
- Define colors/fonts before referencing them
- For color ranges (shades/tints), choose the midpoint color
### Step 5: Validate Structure
Check that:
- YAML syntax is valid (proper indentation, quotes on hex colors)
- Color references match palette names
- Font families are defined before use
- File paths are relative to `_brand.yml` location
- All URLs include protocol (`https://`)
## Modifying Existing Files
When modifying existing `_brand.yml` files:
1. **Read the current file** to understand existing structure
2. **Consult brand-yml-spec.md** for valid field options
3. **Maintain consistency** with existing naming patterns
4. **Preserve references** - if other colors/elements reference a name, update consistently
5. **Test integration** - verify changes apply correctly in Shiny/Quarto
Common modifications:
- **Adding colors**: Add to `color.palette`, then reference in semantic colors
- **Changing fonts**: Update in `typography.fonts`, ensure weights/styles are available
- **Adding logo variants**: Use `light`/`dark` structure for multiple variants
- **Light/dark mode**: Add `light` and `dark` variants to colors
## Using with Shiny for R
When the user wants to apply brand.yml to a Shiny for R app:
1. **Read `references/shiny-r.md`** for complete integration guide
2. **Key function**: `bs_theme(brand = TRUE)` or `bs_theme(brand = "path")`
3. **Automatic discovery**: Place `_brand.yml` at app root
4. **Page functions**: Works with `page_fluid()`, `page_sidebar()`, etc.
Quick example:
```r
library(shiny)
library(bslib)
ui <- page_fluid(
theme = bs_theme(brand = TRUE),
# ... UI elements
)
```
## Using with Shiny for Python
When the user wants to apply brand.yml to a Shiny for Python app:
1. **Read `references/shiny-python.md`** for complete integration guide
2. **Key function**: `ui.Theme.from_brand(__file__)`
3. **Automatic discovery**: Place `_brand.yml` at app root
4. **Installation**: Requires `pip install "shiny[theme]"`
Quick example (Shiny Express):
```python
from shiny.express import ui
ui.page_opts(theme=ui.Theme.from_brand(__file__))
```
Quick example (Shiny Core):
```python
from shiny import App, ui
app_ui = ui.page_fluid(
theme=ui.Theme.from_brand(__file__),
# ... UI elements
)
```
## Using with Quarto
When the user wants to apply brand.yml to Quarto documents:
1. **Read `references/quarto.md`** for complete integration guide
2. **Automatic discovery**: Place `_brand.yml` at projec>
Write ggsql queries — a grammar of graphics for SQL. Use when the user wants to create, modify, or understand a ggsql visualization query.
Creates a pull request from current changes, monitors GitHub CI, and debugs any failures until CI passes. Activate when the user says "create pr", "make a pr", "open pull request", "submit pr", "pr for these changes", or wants to get their current work into a reviewable PR. Assumes the project uses git, is hosted on GitHub, and has GitHub Actions CI with automated checks (lint, build, tests, etc.). Does NOT merge - stops when CI passes and provides the PR link.
Address PR review feedback by systematically working through every unresolved PR review thread on the current branch's PR - analyze each comment, make the requested code changes (with tests where useful), commit, and optionally reply and resolve.
Bulk resolve unresolved PR review threads on the current branch’s PR — typically after threads have been addressed manually or via /pr-threads-address
>
Guide for drafting issue closure and decline responses as an open-source package maintainer. Use when helping compose a reply that says \"no\" to a feature request, closes an issue as won't-fix, redirects a user to a different package, explains why a design choice is intentional, or otherwise declines or closes a community contribution. Also use when the maintainer needs to explain a deprecation, point out a user misunderstanding, or communicate an effort/scope tradeoff to a contributor.
>