---
name: product-identity
description: Define or revise a product visual identity within a brand family, using existing assets and approved decisions. Use for identity briefs and design direction, not routine styling fixes or prose editing.
---

# Product identity

Make the product recognizable to its intended audience while preserving its relationship to the parent brand. Start from the actual product and existing decisions; do not assume that every category needs a new logo, palette, or domain.

## Ground the direction

Read the project identity and voice briefs, applicable repository instructions, existing interfaces, and asset provenance. Inspect rendered examples when available. Record the source revisions and which materials were actually seen. An existing visual choice is evidence of implementation, not automatically owner approval. Mark approval as unknown when its source is absent.

Identify the audience, the product's primary job, its release status, and the permitted scope of change. Preserve approved decisions across runs. If a new request conflicts with them, identify the specific conflict; do not silently replace the brief. Missing assets can remain explicit gaps rather than invented approved artwork.

## Separate family and product decisions

Describe the shared publisher elements and product-specific choices. Common navigation, operator attribution, support, and accessible interaction conventions can coexist with different imagery, display typography, and tone. Explain exceptions in terms of the audience and task rather than novelty.

Produce a concise brief covering color roles, typography and fallback fonts, imagery, layout, motion, and parent-brand relationship. Distinguish **approved**, **observed**, **proposed**, and **unknown** decisions and cite their sources. Include rationale and constraints, not merely a mood adjective or a list of hex codes. Use the consuming project's identity-brief template when present; otherwise deliver these sections directly without depending on another installation.

For every proposed asset or font, record source, revision or hash, license evidence, permitted use, and unresolved clearance. Public availability is not permission to redistribute. Keep private briefs, manuscripts, and uncleared examples in the owning project. Do not copy a reference company's distinctive branding or artwork.

## Apply and hand off

When mockups are requested, use real cleared content and existing assets first. Label unapproved directions in review notes outside the customer-facing design. A placeholder must not imply a live feature, approved cover, real testimonial, or measured forecast. Compare related product treatments together at desktop and narrow widths; preserve clear actions and release status.

Return the brief, requested mockups, source/skill revisions, approval gaps, and checks actually performed. Reference the project's voice brief for prose decisions rather than duplicating editorial rules. Use an available execution skill only when its capability is needed; no external skill, design service, framework, or image generator is required by this workflow. Do not install dependencies or publish the result merely because the brief is complete.

## Export a design kit

For editable assets, print candidates or website-preview handoffs, follow
[export handoff](references/export-handoff.md). Preserve an explicit source root,
a new output root, and an exact public website file inventory separate from
review documents and private material. Validate QR codes from final exported
rasters, and distinguish software checks from physical/vendor proofs. Use the
optional read-only checker only when an export actually needs these checks;
it grants no publishing or purchasing authority.