SDLC Pipeline 是一个用于规范软件交付工作的上下文工程技能，围绕单一主题，将工作拆分为三个顺序阶段，每个阶段产出一份经确认的文档。
用途 将一个主题从意图梳理推进到可执行的实施计划。它适用于需要正式化交付工作、创建或恢复规划文档、在存在开放设计决策时规划请求的场景。文档使用 ASD-STE100 简化技术英语撰写：指令句不超过 20 词，描述句不超过 25 词，使用主动语态，步骤使用祈使句，每个词只表示一个含义，要求一律使用 must，不使用 shall 或 should。对话本身保持自然口语。
三个阶段 第一阶段 Intent，产出 intent.md，用于验证完整意图。第二阶段 Design，产出 spec.md：先确定交付范围，再审查需求、适用时的 UI 以及高层设计（HLD），之后进行自主设计草稿与最终验证。第三阶段 Plan，产出 plan.md，用于验证完整计划。流水线在计划通过验证后结束，计划文件作为外部计划执行技能的输入；执行不属于本技能范围。
主题与阶段管理 主题对应一个文件夹：docs/context-engineering/<subject>/，subject 使用简短的 kebab-case。用户未指定主题时，扫描该目录下的各主题并读取三份文档的 frontmatter，展示主题、当前阶段和状态，请用户选择恢复或新建；用户指定主题时匹配已有文件夹并提供恢复选项，无匹配则新建主题。流水线顺序为 intent.md、spec.md、plan.md，当前阶段是第一个缺失或未标记 status: validated 的文档。上一阶段未验证时不会进入下一阶段；即使用户直接要求写 spec，也会先补全并经过缺失的早期阶段与审批关卡。
不变规则 每个阶段在 Scout 可用时用 Scout 获取仓库证据，不可用时本地完成；Oracle 仅用于第二阶段 HLD 关卡，且仅按该关卡的 Oracle 规则使用，不得用于需求关卡、UI 关卡、自动驾驶、第一或第三阶段，也不得用于回答用户问题；规划期间不使用 Worker 或 Reviewer，包括作为 Scout 或 Oracle 不可用时的替代。该技能不编写生产代码，不运行 git commit、不创建分支、不推送变更；不得检查、编辑或询问 .gitignore，保存文档后可提示用户考虑手动将 docs/context-engineering/ 加入 .gitignore。
状态与过期校验 已确认的文档即状态。每个阶段在对话中完成，在首次呈现验证时创建草稿文件，按用户要求就地修正，只有获批后才设置 status: validated。若在写入前会话中断，则从上游已确认文档重新开始该阶段，不从聊天记录重建部分工作。每份文档记录上游文件的确切 SHA-256 哈希：spec.md 记录 intent_sha256，plan.md 记录 spec_sha256。阶段工作前与验证前都要比对哈希，不一致时停止、展示差异并询问用户如何处理；修改已确认文档会使所有下游文档过期，修改前须告知用户，不得静默覆盖。写入失败时报告失败并停止，不得声称未保存的工作可恢复。
适用场景与限制 适合需要结构化需求、设计与实施计划，并希望获得逐阶段人工确认的软件交付规划。限制包括：仅做规划不写代码、不执行 git 操作；审批与校验流程严格，不能跳过阶段；依赖 references/facilitation-rules.md 与各阶段参考文件执行；具体参考文件内容与详细交互关卡在给定资料中未完全展开，暂未提供。