keel 工作流编排器
pipeline 是 keel 工作流的顶层编排器，提供 8 个流程入口，降低用户面对 13 个原子 skill 时的认知负担。其定位是：用户 → /pipeline → 自动路由到合适的 skill 组合，取代手动选择 13 个原子 skill。核心价值是用户只需说"我要做什么"，pipeline 负责"用哪些 skill、按什么顺序"。
语言规则
支持中英文提问，统一中文回复。
适用边界
本 skill 仅用于 keel 工作。已指定原子 skill 时直接使用它，例如已知目标 skill 可直接调用 /requirements、/feature、/bugfix 等，不必经过 pipeline。
运行模式 / 入口语法
/pipeline 为提问式调度（自动判断）；/pipeline init 为新项目全流程；/pipeline feature 为新功能开发（自动检测 Harness 深度）；/pipeline bugfix 为 Bug 修复；/pipeline verify 为质量检查；/pipeline close 为周期收尾；/pipeline insights 为外部洞察吸收；/pipeline design 为设计稿到达/更新（主动推送）；/pipeline realign 为规范升级入口（统一 realign 维度）。档位与详略由自然语言决定，编排层归一化后下传，用户不需要记参数。
路由播报（强制）
选定入口后、委托第一个 skill 之前，先播报三行：路由（入口名，附阶段检测命中的依据）、链路（skillA → skillB → skillC）、排除（最接近的另一个入口及原因）。播报之后才开始委托，不得边跑边说。原因在于路由选错的代价在链路跑完后才显现，而那时已产生文档与提交；播报把纠错点提前到零成本的位置，同时把静默跳步变成可观察的缺席。
提问式调度（智能引导）
无参数调用时，通过阶段感知与智能引导收敛到合适入口。阶段检测首先扫描 docs/devdocs/ 实际文件（而非依赖 00-context.md 进度），按下表首个命中即路由。无 keel 文件时，会依据已有脚手架与新需求意图、PRD 候选与 maturity（ready / idea / draft）、是否存在 src/、lib/、app/ 等代码、输入长度与类型等给出路由建议。已有 keel 文件时，会依据 00-baseline.md、verify-report、01~04 文档、readiness-report、05-insights.md 待确认条目等判断路由，报告类文件应比其源文件更新，过期时建议重新验证。
一次性升级提示（阶段检测后）
阶段检测完成后、返回路由建议之前，执行 drift 轻量检查。包括两类语义不同、不可混用的 drift：A. 升级类 drift（一次性版本决策，受 .devdocs-realign-ack 控制），检测各产物 spec_version 与各 skill 当前常量差距；B. 健康类 drift（持续监控信号，baseline-aware，不受 ack 控制），路由时跑廉价探针，命中则提示 /pipeline realign --scope=health。.devdocs-realign-ack 标记文件入 git，协作者共享决策。
自适应 Harness 深度
根据变更影响面自动推荐流程深度：Lite（单文件改动、无新接口、配置变更、UI 微调）走 requirements(增量) → dev-tasks → dev-workflow；Standard（多文件改动、新接口、新模块）走全流程；Deep（跨模块架构变更、安全相关、核心数据模型变更）走全流程加强制独立审查与强制文档对齐验证。自动检测信号包括涉及文件数量与是否新增 API/数据模型/模块、跨模块依赖变更等。
入口详解
init：全新项目，从需求到开发的完整流程，链路为发布状态提问 → requirements → agent-memory --update → system-design → test-cases → dev-tasks → verify --readiness → dev-workflow（批量）→ verify --docs --impl → sync。feature：已有项目追加新功能，按 Harness 自动选择 Lite/Standard/Deep。bugfix：修复 Bug，简单 Bug 与复杂 Bug 走不同链路。verify：任意阶段质量检查，可按代码变更、文档变更、UI 设计稿分别选择 --impl、--docs、--ui。close：开发周期结束收尾，链路为 sync → compound → onboard --update → prd clear。insights：外部洞察吸收。design：用户主动推送设计资产，pipeline 只做阶段检测和收集。backlog：暂缓任务池维护。realign：规范升级后回扫已完成产物，不破坏原完成证据，仅追加差距补齐。
编排规范（子 Agent 调度）
pipeline 调用其他技能时必须通过 Task tool 启动子 Agent，阶段间只传递 YAML 摘要与文件路径，编排 Agent 不读取子技能的完整输出文档。子 Agent 返回 failed 加 blockers 时，展示阻塞项询问用户，不自行读取文档排障；返回 partial 时不得当成完成，停在该处不进入链路下一阶段，并给出续做入口。每个子 Agent 自行读取所需前置文档。
阶段边界约束
keel 工作流严格区分文档阶段和编码阶段。需求、设计、测试设计、任务拆分、项目改造阶段产出文档，不允许编码；开发执行与 Bug 修复阶段产出代码，允许编码。文档阶段仅写入 docs/devdocs/ 下的 Markdown 文档。
子 Agent 摘要格式
本 Skill 作为子 Agent 运行时返回 yaml-summary-v1，pipeline 私有字段只放在 summary.details，包括 entry、harness_depth、stages_completed、stages_remaining、interrupt_reason。output_files、new_ids、next_recommended 仍使用共享 envelope 字段。
下一步
pipeline 完成后，所有产出文档均已生成或更新，用户可继续下一轮 feature/bugfix，或运行 /onboard --read 传递上下文给新 AI。新增功能开发时不得跳过 test-cases、dev-tasks、verify --readiness 直接进入 dev-workflow；Bug 修复按 /pipeline bugfix 路径处理。
其他细节（如 shared/constraints.md、references/realign.md、health-lint 清单、workspace-topology 协调等）依据资料原文所述，具体实现文档暂未在本资料中提供全文。