creative-brief
This skill should be used when the user asks to "write a creative brief", "build a motion brief", "the client doesn't know what they want", "turn this vague client request into a brief", "what questions should I ask the client", or "make a brief I can get sign-off on". It turns a fuzzy client ask into a structured, sign-off-ready motion design brief and the exact clarifying questions to send back.
1How It Works & Mechanism
Core stance: The brief is a decision document, not a wish list—every project decision must trace back to a specific line.
A brief is not a wish list — it is a decision document. Every project decision should trace back to one line in the brief.
Interrogate across 11 dimensions where each must have a concrete answer; if unanswered, fire the corresponding single high-leverage question.
Capture a concrete answer for each. If the client cannot answer, send the matching clarifying question (see references/clarifying-questions.md).
Classify gaps into two tiers: items altering price or specs (budget/launch date/core message/placement) are blockers; items affecting only execution details are written as marked assumptions.
Rule of thumb: gaps that change the *price or the spec* are blockers; gaps that only change *execution detail* become flagged assumptions.
Perform a necessity check first: if creative intent is already clear in writing, draft a lightweight 1-page brief and proceed immediately without repeating interrogation.
Is the creative intent already clear and agreed in writing?
Build a gap-to-question mapping table (one question per issue) and require bundling them into a single email rather than piecemeal daily asks.
| No measurable goal | "If this works, what number on a dashboard moves?" |
Never ask clients to design; use bounded-choice questions instead (A or B, pick one of three), translating every adjective into concrete options.
- Replace "What tone do you want?" with "Closer to A (calm, premium, slow) or B (punchy, bold, fast)?"
Close out with a sign-off block and a single decision-maker: once signed, semantic meaning becomes contractual, and subsequent changes require a change request.
This brief is the agreed creative intent. Changes after sign-off are handled as change requests.
Counter-examples are quantified: a kitchen-sink brief turns round 1 into a client discovery meeting (on the client's billable clock).
**ANTI-PATTERN — the "kitchen-sink" brief that guarantees revisions:**
2Core Capabilities
3External Dependencies
| Kind | Dependency / Endpoint |
|---|---|
| package | 兄弟 skill:motion-art-direction(锁定 tone 后选 Motion Personality)与 animation-principles(三支柱为 brief 逻辑的上游)——均属 iart-ai/motion-design-skills 仓库 |
| package | 下游交付规格 skill(投放渠道决定规格与价格;brief 内以 placements 定语) |
4Recommended Governance & Evidence
- SKILL.md: Pure prompt instructions and rule text; no script execution or external impact
5Second-Pass Verification
- [ok] 是否存在脚本或联网动作 — 全目录仅 Markdown;代码块只有 brief 模板与邮件文本,无 shell/JS/URL(除署名页脚)。
- [ok] 问题银行 reference 是否与 SKILL.md 的映射表一致(防两套问题打架) — references/clarifying-questions.md 按 11 维组织(13 个标题段,含合并邮件模板),SKILL.md 的映射表是其压缩版;两者关系为「摘要 → 完整」,未发现口径冲突。
- [discrepancy] 跨仓引用的两个兄弟 skill 能否解析 — SKILL.md 的 Related frameworks 要求引用 motion-art-direction(Motion Personality 预设)与 animation-principles(三支柱),但二者属 iart-ai/motion-design-skills 仓库。只装 freelance-motion-skills 时这两条引用悬空(文档未标注需另装),实际使用需同时安装 motion pack。
- [unlocatable] 「prevent ~80% of tone revisions」这类比例声明的出处 — SKILL.md 常见错误表写「guardrail adjective … prevents ~80% of tone revisions」,pin 仓库内无数据来源或案例统计;作为经验性断言记录,不计入已核事实。
6Verdict & Scenarios
3d97d9c1f580425d…