核心用法
ORDER_KICKOFF() 是一款专为硬件、设备及备件订单设计的启动协调 Skill，在订单确认后快速组织采购、工程、QC、包装、物流、财务和销售等跨部门完成启动确认。其核心操作模式为"参数驱动式协调"：用户输入订单信息后，Skill 首先解析并生成参数状态表（已命中/部分命中/缺失/冲突/待验证），只有达到最低运行条件（订单已确认、关键商务条件明确、主要参会部门可识别、初步风险清单已建立）才进入正式分析阶段。
输出成果包含十大模块：参数完整度结论、参数状态表、订单概要、会前缺失信息、必须参会部门、各部门确认清单、当前主要风险、需会议决策的问题、责任人和截止时间，以及会后跟踪表。其中"确认清单"是区别于普通会议工具的关键设计——它要求每个部门对货源、兼容性、固件、测试标准、包装规格、物流限制等具体事项给出明确结论，而非仅参会表态。
显著优点
结构化防遗漏机制：通过 7 大必填参数+10 大可选参数的完整框架，强制覆盖订单启动的关键维度，有效解决"把启动会当普通会议""遗漏付款和交期边界"等典型风险。
责任闭环设计：每个确认事项必须绑定责任人与截止时间，输出直接生成会后跟踪表，避免"模糊责任人""只生成议程不生成确认清单"的执行断层。
证据优先级规则：明确人工确认的订单、付款、交期和物流事实优先，禁止用预计、口头反馈或推测覆盖关键数据，从源头防范过早承诺客户时间的业务风险。
部门专业化清单：针对不同部门设计差异化确认维度——采购需确认替代货源和延期风险，工程需验证配置兼容性和固件版本，QC 需明确全检/抽检方式和不良处理机制，体现硬件供应链的专业深度。
潜在缺点与局限性
准入门槛较高：最低运行条件要求订单必须已确认，若订单处于待确认状态需回退调用 ORDER()，这对用户的前期判断能力提出一定要求。
人工依赖仍重：虽强调"不得覆盖人工判断"，但这也意味着系统无法自动解决参数冲突或补全缺失信息，需人工介入验证，在快节奏业务中可能成为瓶颈。
场景边界严格：明确区分硬件设备订单与"一般产品、服务或项目启动"，后者需调用 zayn-general-order-kickoff，用户需准确识别场景否则可能选错 Skill。
输出颗粒度待验证：当前版本为 0.1.0 Draft 状态，"待补充完整证据优先级"等说明提示部分规则尚未固化，实际运行稳定性需进一步观察。
适合的目标群体
硬件设备贸易企业：涉及服务器、网络设备、工业硬件等需要跨部门协调货源、测试、包装、清关的订单履约场景。
供应链管理/订单履约团队：需要将订单启动从"经验驱动"转为"流程驱动"的中小型企业，尤其是面临多部门协作效率低下、责任推诿问题的组织。
项目型销售组织：订单涉及复杂配置、分批交付、多国清关等变量，需要结构化工具管理不确定性的场景。
使用风险
版本稳定性风险：0.1.0 Draft 版本存在规则未完全固化的可能，关键业务场景建议配合人工复核。
参数误填风险：用户若将"预计到货时间"误填为"到货时间"，可能触发"用预计覆盖事实"的禁止事项，需严格培训输入规范。
跨 Skill 调用断点：订单未确认时无法自动流转至 ORDER()，需用户手动判断并切换，存在流程断点风险。
过度结构化风险：对于简单订单或长期合作客户的标准化订单，完整参数输入可能带来不必要的操作负担，需评估投入产出比。