SDL 生命周期

想解决什么问题

把 SDL 流程交给 Agent 执行时，最先撞上的往往不是某个 API，而是结构问题。威胁建模、代码走查、依赖扫描、发布卡点这些环节散落在不同文档里，scripts/ 该放什么、references/ 该放什么、assets/ 该放什么，如果没有固定约定，模型每次执行都要重新摸索，技能也很难被团队长期维护。这个技能要解决的就是这个「骨架缺失」的问题。

它给出的结构

• Overview：用一到两句话说明这个技能到底让 Agent 能做什么。
• 正文结构：按场景选择组织模式。Workflow-Based 适合有明确先后顺序的流程；Task-Based 适合把能力拆成一组操作；Reference/Guidelines 适合标准或规范类内容；Capabilities-Based 适合多个相互关联的功能集合。几种模式也可以按需混合。
• 资源目录：scripts/ 存放可直接执行的 Python 或 Shell 代码；references/ 存放需要读进上下文的参考文档；assets/ 存放模板、字体这类在最终产物里使用的文件。三类目录并非必须同时存在，用不上的可以直接删掉。

怎么落地

1. 先写 Overview，把技能的用途钉死。
2. 按场景挑一种正文组织模式，删掉模板里的 Structuring This Skill 指导段落。
3. 用代码示例、决策树或具体 case 填充正文。
4. 整理 scripts/、references/、assets/，只保留真正会被用到的部分。

适用边界与注意点

• 当前版本只是结构骨架：Overview 仍是 TODO，正文也只保留了模板提示，没有实现任何可运行的 SDL 操作。
• 想验证某个安全流程能不能跑通，需要自己按这套结构把内容补完。
• 安装后不会自动获得 SDL 能力，它提供的是组织方式，不是开箱即用的检查器。
• 归类在 IT 运维与安全下，适合作为内部安全流程技能的起始模板。