Skip to content
cccskills
FreePublished on GitHub

brand-audit

Audit how a brand is currently expressed across touchpoints and flag drift from its defined tokens, voice, and strategy. Use to inventory and critique an existing brand before changing it.

The English summary is being prepared. Showing the original description.

See how to install

Files included (2)

  • SKILL.md7.0 KB
  • evals/triggers.json1.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

brand-audit

Method skill. Inventories current brand expression across touchpoints and flags drift against defined brand tokens, voice, and strategy. For the UI surface it leans on existing-ui-audit rather than re-implementing component inventory. Output is a drift findings list — not a redesign.

When to use

  • Before a rebrand or brand refresh — establish the baseline first.
  • When auditing brand consistency across touchpoints (web, decks, docs, ads, copy).
  • To create an evidence base before running brand-strategy.
  • When "is this on-brand?" needs a systematic answer across many assets, not a gut call.

Procedure

  1. Gather the source of truth. Run brand:status --json and take the sources it reports: the registered tokens.json and the brand-voice slot (agents/context-spine/brand-voice.md) — three {is, is_not, proof} attributes, the tone matrix, avoid[], claims[]; only a schema-valid slot counts. Add logo rules and the strategy doc if they exist. Consumer brand definition is authoritative; corpus defaults are gap-fill only. No valid slot makes every voice observation undefined, never drift — there is nothing to diverge from. <!-- ref-ignore -->

  2. Inventory current expression per touchpoint. Cover logo usage, colour palette, typography, voice/copy tone, imagery style, and iconography across the relevant surfaces (site, app, decks, marketing, docs).

    Personal and company profile surfaces, including LinkedIn, X, and GitHub organization profiles, are deliberately excluded regardless of whether their content is fetched, pasted, or supplied as a file, pending a written public-profile-field privacy floor defining what may be processed.

    Recorded so the next reader does not re-derive the gap, which has already happened once. The exclusion is about handling, not retrieval: a pasted profile is mechanically a different thing from a network fetch, but the missing artefact is a field-level classification saying which profile fields are brand surface (logo, palette, bio messaging) and which are PII-adjacent (employment history, contributor names, location). A profile's About text carries both in one field. Without that classification the skill cannot distinguish them, and no test can assert that it did. AI council 2/2, 2026-08-25. Include user-supplied profile inputs once a written, testable field-level privacy floor exists; include fetched inputs only after both that floor and a host-agent fetch contract exist.

  3. UI surface. Invoke existing-ui-audit for UI component inventory. Do not re-implement it here — take its output as an input to this audit.

  4. Compare observed vs. defined. For each touchpoint value, check it against the matching token or voice rule.

  5. Classify each finding. Three buckets: on-brand (matches the defined token), drift (observed value diverges from the token), undefined (no token exists to audit against — this is a governance gap, not automatically wrong).

  6. Rank drift findings by visibility (how prominent the touchpoint is) multiplied by frequency (how often it appears). Surface the top items first.

  7. Verify completeness. Confirm every inventoried touchpoint is classified (on-brand / drift / undefined) — the audit is complete only when the classified count equals the inventoried count, and existing-ui-audit has run for every in-scope UI surface. Ensure each drift finding cites BOTH the defined value and the observed value; a finding missing either side is not yet verified.

  8. Output the findings list (see Output format). Do not redesign or author replacements — hand drift findings to brand-identity or brand-strategy.

Two constraints on platform-specific guidance

Both are constraints on what this skill may assert, not machinery, and neither is a registry.

  • Any platform-specific guidance carries a source tier and a review date. Platform conventions — an image aspect ratio, a character limit, where a profile crops a banner — change without notice, so a number stated here without a date and a source is a claim that quietly stops being true. Tier it (platform-doc / observed / inferred) and date it, or take it from the platform's own current spec at audit time instead of stating it.
  • No engagement metric is stated as fact. Reach, impression and best-time-to-post figures are platform- and account-specific and are not auditable from a brand token. Where such a figure is load-bearing to a finding, attribute it; never assert it as a general truth.

Output format

  1. Source-of-truth summary — what brand tokens, voice rules, and strategy exist and where they were found (or "none defined" if absent).
  2. Drift findings — table-style list: touchpoint | defined value | observed value | severity (high/medium/low).
  3. Undefined gaps — values with no token to check against; listed separately so they can feed a token-creation pass.
  4. Ranked top drift — ordered list of the highest-severity drift items to fix first, with a one-line rationale per item.

Do NOT

  • Redesign or author replacement assets — that is brand-identity work, not audit work.
  • Re-implement UI component inventory — call existing-ui-audit and consume its output.
  • Invent a "correct" value where none is defined — mark the finding undefined and surface it as a governance gap.
  • Treat corpus defaults as the consumer's source of truth — consumer brand definition always wins.

Gotcha

  • undefined is a real finding. A value with no token to check against is a governance gap that deserves its own section, not a pass.
  • Drift severity is visibility times frequency, not personal taste. A rarely-seen off-palette icon ranks lower than a wrong primary colour used on every page header.
  • Consumer brand tokens outrank any corpus default. If the consumer has defined a token, audit against that; ignore what the corpus suggests.

See also

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Use when reviewing UI for accessibility — WCAG 2.2 AA, keyboard nav, focus, ARIA, contrast, screen-reader semantics — even on 'is this a11y-OK?' or 'mach das barrierefrei'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 19, 2026

Use when defining or auditing the activation event — aha-moment selection, retention correlation, falsifiable definition. Triggers on 'what is our aha moment', 'redefine activation'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 19, 2026

Use when capturing an architectural decision — file naming, next ADR number, Status / Context / Decision / Consequences, index regen; fires even without saying 'ADR'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 19, 2026

Adversarial critique — devil's advocate, stress-test, honest teardown ('poke holes', 'be brutal', 'was hältst du davon'); explicit request only. Routine code or design review → code-review.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 19, 2026

Use when reading, creating, or updating agent documentation, module docs, roadmaps, or AGENTS.md. Understands the full .augment/, agents/, and copilot-instructions structure.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 19, 2026

Use for an adversarial red-team / blue-team / auditor review of an AI agent's CONFIG + behaviour (rules, skills, MCP, hooks, permissions) — attack-chain → defensive-gap list, not a code audit.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 19, 2026

See all skills by event4u-app

Report a problem with this skill