用途
plan-ingestion 是一个访谈式技能，用于把一条计划中的（或已存在但未文档化的）数据摄取路径，转化为消费者项目 docs/ingestion-plans/<pipeline>.md 下的摄取计划 Markdown 文件。它不是模板填充，而是一场短小、分支式的访谈：每一份落地的计划都经过摄取终止开关（命名的上游 Source Profile）、针对该 profile 的交付模式比较、流式/批处理中立规则、诚实重放测试、诚实隔离测试，以及“这真的是一个 ADR 时刻吗”的路由测试。
摄取计划不是项目管理计划——不是带负责人和日期的 TODO 列表，也不是交付路线图。它是摄取路径的运营与契约模型（幂等性、重放窗口、隔离、模式演进、值班），是 Source Profile 下游一阶段的结构对应物，刻意由人撰写，绝不从代码产物推断（不扫描 dbt manifest、不解析 Airflow DAG、不读取 Terraform）。
主要能力
- 运行九轮访谈，每轮一个问题（Turn 8 为合并轮），把摄取路径固化为一份摄取计划。
- 强制摄取终止开关：Turn 1 必须命名 docs/sources-of-record/ 下至少一个 accepted 或 draft 状态的 Source Profile；若无法命名，则不写计划，建议先运行 /profile-source。
- 可恢复性检查：先扫描 docs/ingestion-plans/，支持继续草稿、新建计划、列出所有计划及状态。
- 分支式提问：根据交付模式（流式/CDC/webhook 与批处理）询问不同的排序与去重子问题。
- 覆盖交付模式、排序与去重、落地与模式演进、失败与重放等契约，并写入对应正文小节。
- 对多管道场景，先完整钻取一条，其余以 status: draft 存为桩文件。
- 自包含：契约参考位于 references/ingestion-plan.md，校验脚本位于 scripts/lint-ingestion-plan.sh。
使用方式
该技能以访谈形式运行。开始前先做可恢复性检查：扫描 docs/ingestion-plans/，若存在计划文件则询问用户是继续草稿/需跟进计划、新建计划，还是列出所有计划及状态。status: accepted、status: rejected、status: superseded-by-<path> 的文件视为不可变，不提供编辑。若目录不存在，在首次写入时创建。
随后按顺序执行九轮访谈，每轮一个问题，除非规范明确为合并轮。两条贯穿规则：先推荐再提问（基于已命名的上游 Source Profile、管道名、相邻计划/ADR 或合理默认值提出候选答案，再请用户接受、拒绝或细化；但 Turn 1 的终止开关答案绝不代拟）；先探查再提问（先查看项目中的 Source Profiles、DGQs、ADRs、相邻摄取计划、CONTEXT.md 术语表，再带入该轮）。
Turn 1 命名上游 Source Profile：先扫描 docs/sources-of-record/ 列出可用文件及其 system/entity 与状态。若有一个或多个 accepted/draft 的 profile，记录路径到 related_sources_of_record 并阅读其 delivery_mode、cadence、late_arrival_window 与运营契约；若 profile 为 rejected 或被取代，则追问活跃上游；若无 profile 或用户无法命名，触发终止开关，不写计划，建议先运行 /profile-source 后退出。
Turn 2 识别管道：捕获 pipeline（kebab-case slug）与 destination（落地原始数据所在位置）。若浮现多条管道，请用户选一条完整钻取，其余写为 status: draft 的桩文件，frontmatter 填入 Turn 1 的上游 Source Profile，其余 linter 必需枚举设为安全占位值，并在 ## Open follow-ups 注明需恢复。
Turn 3 交付模式：对照上游 Source Profile 的 delivery_mode，映射为 cdc | pull-batch | push-batch | streaming | webhook | manual-export 之一。若与 Source Profile 不一致，须在正文 ## Delivery model 记录为有意架构选择并给出一行理由，或作为异味追问。
Turn 4 排序与去重：按 Turn 3 分支提问。流式/CDC/webhook 询问排序保证、分区键、重复识别方式；批处理询问重跑幂等性、去重键。映射为 ordering（source-order | event-time | ingest-time | unordered）与 dedup_key（一个或多个字段，或字面量 not-applicable）。诚实回答“无去重键且接受重复”应记为 dedup_key: not-applicable 并在正文写明理由。答案以短项目符号列表记入 ## Delivery model。
Turn 5 落地与模式演进：询问源新增列、类型拓宽、列重命名时的行为，映射为 schema_evolution（contract-versioned | additive-only | breaking-allowed | none）。同时捕获落地形态（逐列透传、带源发出时间戳与幂等键的信封包装、Avro/Parquet/JSON、落地原始层保留策略）写入 ## Landing contract。
Turn 6 失败与重放（最响亮的一轮）：分两遍。Pass A 重放：询问重跑产生什么、上游重放最近一小时会怎样，映射为 replay_strategy（source-replay | warehouse-rewind | not-replayable）。三条规则：诚实而非理想化；若用户无法回答，不掩盖，设 status: needs-follow-up，命名具体未决问题，停止访谈并促使用户去查明。
适用场景
适用于数据工程团队需要为一条摄取路径建立运营与契约模型时，尤其是需要强制确认上游 Source Profile、明确重放与隔离策略、记录模式演进立场的场景。也适用于把已存在但未文档化的摄取路径补成正式计划。
限制
- 没有命名的上游 Source Profile 时，技能拒绝开始访谈，不写计划。
- 不编辑 status: accepted、rejected、superseded-by-<path> 的计划文件。
- 不提供模板填充；每份计划都需经过访谈压力测试。
- 不推断代码产物；计划刻意由人撰写。
- 关于具体安装命令、收费、价格、平台支持等事实，资料中暂未提供。