用途：通过访谈用户，确定应用独特的视觉识别，并撰写一份有效的 DESIGN.md（design.md 格式），作为应用外观的提交式事实来源。若仓库存在 USERS.md，它是首要输入：身份必须为其中的用户类型而建，排问前先阅读，并让产品面向的人群驱动每项建议。
主要能力：拒绝转录式记录，采用一次一问的访谈法，拒绝“现代、简洁、极简”等泛化答案；强制唯一性，要求至少一个明确的非显然选择（特色强调色、有个性的字体、明确的构图立场）并记录反面参考；避免滑向默认（如靛蓝/紫色 Tailwind 默认色、反射式选择 Inter）；输出必须能通过 design.md schema 解析并 lint。
使用方式：1. 侦察——扫描仓库中已暗示身份的资产、颜色、字体、现有 DESIGN.md、产品文案、受众线索；若有 USERS.md 先读它作为主简报。2. 按 references/grill-questions.md 的问题树依次提问：产品与感觉、参考与反参考、颜色与角色、字体、布局与密度、深度与形状、动效姿态、明确的做与不做。3. 起草身份并通过 4–6 句回述确认。4. 按 references/design-md-format.md 撰写 DESIGN.md（YAML token 前言 + 规范顺序的正文段落 + 真实 Do's and Don'ts），默认位于仓库根目录，需确认路径。5. 运行 npx @google/design.md lint DESIGN.md，修复 broken-ref 与对比度问题（调整 token 至 WCAG AA 通过），解决 missing-primary/missing-typography，未解决项需解释。6. 交接文件路径、独特选择与 lint 状态。
适用场景：需要为应用定义外观、创建设计规范、撰写 DESIGN.md 时。
限制：资料未提供具体收费、平台支持或效果承诺；若用户确实想要安全常规外观，允许但须为明确声明的选择并仍提交具体值。