본문으로 건너뛰기
cccskills
무료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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(2)

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

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

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

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

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'.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

event4u-app/agent-config122026년 10월 21일 업데이트

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

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

event4u-app/agent-config122026년 10월 21일 업데이트

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

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

event4u-app/agent-config122026년 10월 21일 업데이트

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

event4u-app/agent-config122026년 10월 21일 업데이트

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

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

event4u-app/agent-config122026년 10월 21일 업데이트

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

event4u-app/agent-config122026년 10월 21일 업데이트

event4u-app의 스킬 모두 보기

이 스킬의 문제 신고