用途
model-data 是一个数据工程领域的 AI 技能，用于把计划中的、或已存在但尚未文档化的数据转换，转化为一份 Model Plan（模型计划）Markdown 文件，写入使用方项目的 docs/model-plans/<model>.md。它是一次访谈，而不是模板填充：每一份最终落地的计划都经过多项检验，包括转换终止开关（必须命名上游 Storage Plan）、粒度必须解析为具体基数、断言诚实性、敏感性传播，以及“这是否真的是一个 ADR 时刻”的路由判断。
主要能力
- 运行简短、分支式的访谈，逐步确定模型的契约字段。
- 强制“转换终止开关”：被接受的 Model Plan 必须在 related_storage_plans 中至少命名一个上游 Storage Plan。若无法命名，技能不会写计划，并建议先运行 /plan-storage。
- 支持恢复已有草稿或需要跟进（needs-follow-up）的计划；对 status: accepted、rejected、superseded-by-<path> 的文件视为不可变，不提供编辑。
- 对一次转换产生多个分层模型（如 stg-orders → int-orders → fct-orders）的情况，先完整钻取一个模型，其余以 status: draft 存为占位计划。
- 产出遵循 references/model-plan.md 契约，并可由 scripts/lint-model-plan.sh 进行结构校验。
使用方式
技能按九个回合依次进行，每回合通常只问一个问题（Turn 8 为合并回合）。两个贯穿规则：先推荐再询问（除终止开关外，尽量基于上游计划、模型名、相邻计划或合理默认值给出建议，让用户接受、拒绝或细化）；先探索再询问（先查看项目中已有的 Storage Plans、Ingestion Plans、Source Profiles、DGQ、ADR、相邻 Model Plans、CONTEXT.md 词汇表等，再带入问题）。
运行前会先做可恢复性检查：扫描 docs/model-plans/，若已有计划文件，询问用户是继续草稿、开始新计划，还是列出所有计划及状态。若目录不存在，则在首次写入时创建。
九个回合依次为：
- 命名上游 Storage Plan（终止开关）。先扫描 docs/storage-plans/ 列出可用文件及其 dataset/storage_system 与状态，让用户从具体集合中选择。若上游计划被拒绝或已被取代，会要求指向有效存储；若模型只建立在其他模型之上，仍需追溯到根 Storage Plan；若不存在或无法命名，则触发终止开关，不写计划并建议先运行 /plan-storage。
- 模型与粒度。确定 kebab-case 模型 slug 和 grain（“一行代表什么”），粒度必须解析为具体基数，模糊粒度会被追问。若一次出现多个模型，选择一个完整钻取，其余写为草稿占位。
- 层级与物化方式。layer 取 staging | intermediate | mart | metric | feature；materialization 取 view | table | incremental | materialized-view | ephemeral | streaming。若 mart 或 metric 直接读取存储而无中间层，会指出这一现象并记录理由，但不阻断。
- 建模约定（ADR 时刻检测器）。modelling_convention 取 star、data-vault、one-big-table、activity-schema、normalised 或 none。
- 依赖与敏感性。记录 intra-stage 依赖、depends_on、sensitivity 等。
- 断言姿态。assertions 取 business-invariant（测试绑定到具名业务事实）、shape-only（仅 not null / unique / 引用检查）或 none（尚无测试）。business-invariant 是挣得的，不是愿望式断言；shape-only 和 none 是诚实且被接受的答案。
- 规范定义。记录该模型为下游消费者拥有的规范定义。
- 下游契约（合并回合）。记录下游契约相关内容。
- 收尾与写入。
适用场景
适用于数据团队需要把数据转换的运营与契约模型版本化管理的场景，尤其是希望确保每个模型都能追溯到受治理的存储、避免重复定义业务逻辑（如重复的收入定义）的情况。也适用于需要为分层模型集合建立结构化文档、并希望用 linter 校验契约完整性的团队。
限制
- Model Plan 不是项目管理计划（无 TODO、负责人、交付日期），也不是 dbt/SQL 模型文件（不含 SQL、ref()、Jinja、Dataform/SQLMesh 配置）。
- 技能不输出 SQL、dbt 模型或测试 YAML；实现这些承诺的代码位于使用方的转换仓库中，不在本技能范围内。
- 计划是人工编写的，绝不从工具推断：不解析 manifest.json，不扫描 INFORMATION_SCHEMA，不做仓库或 dbt/Dataform 项目内省。
- 终止开关不可软化：不得替用户编造看似合理的 Storage Plan 路径。
- 典型长度为每个计划 7–11 个实质性交流；不应为凑数截断或填充。
- 关于收费、价格、平台支持范围等事实，资料中暂未提供。