用途
sdlc-design 用于在某个意图（intent）被接受之后，编写该意图的规格与设计，产出物为 intent/<slug>/spec.md。它适用于用户为已有意图请求 spec 或设计时。
按照描述，正常运行时需要等待批准；被明确授权的自主队列可在完成下述置信度评估后批准。批准后应读取 sdlc-apply 并从 plan 步骤执行，本技能本身不实现代码。
主要能力
规格内容组织：需求与设计都保留在 spec.md 中，不另行编写 design.md。需要把被接受的结果与每一项实质约束追溯到可观察的需求/场景，并在提供的情况下使用用户的具体示例与限制。不把期望行为悄悄替换为更易实现的方案，缺失的产品决策应向前传递以待解决，而不应发明默认值。
范围守护：把明确的自动化、指定的提供方或集成、请求的数据覆盖范围保留为需求。在需求/场景容易丢失时，保留用户简短但决定性的措辞或来源摘录。未经用户明确接受，不把请求的结果移入“范围外”。检查新增范围与缺失范围；超出请求流程的额外界面、必需输入、确认、再确认步骤或门禁属于产品决策，需要追溯到明确的用户请求或现有制品中有证据的约束。自主批准不能扩大被接受的结果，也不能缩减被接受的结果。
阻塞处理：若访问、凭据或依赖不可用，记录阻塞并完成有用的已授权工作，但把请求的能力保持为阻塞，直到交付，或用户在看到取舍后明确接受不同结果。对于关键自动化或集成，需指定可观察的端到端场景；人工回退不满足该要求。
设计取舍：在理解受影响流程后应用 YAGNI：先复用合适的现有代码与模式，再在满足需求时优先使用标准库、原生平台或已安装依赖的能力。仅为已证实的缺口新增自定义代码或依赖。避免为未来功能做推测性配置、扩展点和脚手架；保留由当前契约或清晰性证明合理的抽象。尽量减少实现复杂度，而不是削减请求的能力：保留明确结果、兼容性、校验、错误处理、安全与可访问性。
前置条件：需要 intent/<slug>/intent.md 且状态为 accepted（或本会话中有接受记录）。若仍为 draft，应回到 sdlc-plan。已存在的草稿 spec 可在此继续，应修订而非用模板覆盖。
版本控制：工作流授权对自有制品进行提交，除非用户或宿主限制。写入前记录仓库、分支、HEAD、已暂存路径以及工作树/未跟踪路径。优先复用自有检出；新的工作树默认放在 <agreed-project-workspace>/.worktrees/。绝不移动活跃检出。若现有工作会重叠或被吸收，使用干净的隔离工作树；否则停止提交并说明冲突。绝不重置或 stash 他人的改动。只暂存本关注点。使用 Conventional Commits（type(scope): 祈使句摘要，可选 scope），空行，以及一句说明原因；用 ! 或 BREAKING CHANGE: 标记破坏性变更。除非被要求，否则不推送。
并行与编排：每个产品仓库只保留一个活跃的代码实现通道；并行设计研究是只读的，新增请求不启动另一个写入者。此处编写直白的 spec。当有大量独立工作值得交接时，委托有边界的只读研究；在本处用其证据编写制品。对相关问题复用研究者，传入有界输入，使用完成通知而不是反复轮询。正常运行时等待人工批准；自主批准遵循下述置信度规则。
契约与边界证据：修改共享命令、不变量或持久化契约时，在设计中识别受影响的现有调用方和变更生产者，用场景覆盖其保留行为或被明确接受的变更。仅在旧客户端、后台任务和相邻流程使用该契约时才纳入。新路径测试不能证明现有写入者的兼容性。对于提供方/运行时边界，先检查既有适配器与错误解析器；把有实质影响的响应和错误假设建立在当前源码、版本匹配的文档或已获授权的捕获响应上，而不是臆造的 mock 形状。对有状态流程，指定相关状态转换以及失败、重试或重载后可观察的持久化结果，而不只是即时响应。
使用方式
置信度与挑战：高置信度需要同时满足四项：明确的结果/约束；当前源码支持；相关契约与重要失败模式有证据；没有未解决的实质假设或冲突证据。隐私、迁移、并发和不可逆行为需要更强证据。一致同意或声明的概率不足够。在 Decision review 下记录置信度与证据以供自主批准。高置信度时跳过挑战者。否则向一名新的只读挑战者发送最强未解决假设，检查引用，解决异议，并记录残余不确定性。缺失偏好/权限时需要用户。跨门禁携带有效证据；只挑战发生变化的实质不确定性。
步骤：
- 解析 slug（由用户命名，或唯一一个已接受且无 spec 或有草稿 spec 的意图）。
- 读取 intent.md、已存在的 spec.md 以及任何 context.md；对照产品仓库验证上下文声明，只向前携带与设计相关的未解决事实。
- 使用 ### Requirement: 块，每条一个 SHALL，并至少有一个 #### Scenario: 采用 WHEN / THEN 形式。在 Scenario THEN 中原样引用数值/枚举/校验限制，而不只写在设计中；这些场景是验证者的测试用例。
- 仅在创建 spec 时把 assets/spec.md 复制为 intent/<slug>/spec.md；否则修订现有草稿。保持 status: draft 直到批准。把 intent_digest 设为当前已接受意图的 approved_digest；不匹配意味着意图已变化，必须先协调。
- 把 context.md 压缩为制品中未出现的未解决事实、下一步行动和证据链接，目标 500–1,000 字或更少。删除已转移或已被取代的条目，在 Git 中保留历史；若为空则删除该文件。
- 在下一步之前提交这些编辑。
- 批准前，检查可能实质改变架构、安全行为或验收标准的未解决选择。正常运行时，就只有用户能做的决策询问用户，修订并提交草稿，然后寻求批准。自主运行时，对新出现或变化的实质决策评估置信度。
- 在人工批准或完成自主决策审查后，设置 approved_by: human 或 autonomous，用 python3 <this-skill-dir>/scripts/fingerprint.py intent/<slug>/spec.md 计算 approved_digest，设置 status: specified，并提交。然后读取 sdlc-apply 并从 plan 步骤执行。
- 若已指定的 spec 需要阻塞性更正，将其退回 draft 并提交修订。若已存在 plan，在同一提交中把其状态退回 draft。spec 重新批准后，sdlc-apply 必须在实现恢复前协调并重新批准 plan。
资源解析：assets/ 和 scripts/ 应针对本技能由宿主提供的安装目录解析，而不是产品仓库。命令以 python3 为例；请选择可用的 Python 3.8+ 解释器并引用已解析路径。通过宿主或其安装的 SKILL.md 加载所需的下一技能；若其或资源不可用，在该门禁处交接，而不是自行发明。
适用场景
- 用户为已接受意图请求规格或设计。
- 在 ai-sdlc 流程中，意图已被接受、需要产出可验证的 spec 与设计时。
- 存在草稿 spec 需要继续修订时。
限制
- 前置要求 intent.md 状态为 accepted，否则须回到 sdlc-plan。
- 本技能不实现代码；批准后交由 sdlc-apply 执行。
- 正常运行时等待人工批准；自主批准有严格置信度条件。
- 不编造缺失的产品决策、默认值或模拟形状。
- 除上述流程外，具体支持的平台、收费与价格信息暂未提供。