跳到正文
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(原文)

安装前可以查看交给 AI 代理的指令内容。

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 / 1000 字

此表单受 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月20日 更新

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月20日 更新

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月20日 更新

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月20日 更新

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月20日 更新

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月20日 更新

查看 event4u-app 的全部技能

报告此技能的问题