用途：为一个工程团队或开源项目提供软件生命周期文档的管理规范，把提案、决策、规格、事后复盘与操作指南串成一条固定流程，并让模板和文件夹说明保持整洁。该技能是包级指导，所有 Markdown 操作仍受平台 open-knowledge 技能（读、写、预览、链接、依据规则）约束，生命周期约定叠加在其上。
主要能力：定义五类目录的流转——proposals（RFC 式设计中提案）获批后进入 decisions（冻结的 ADR）；decisions 派生 specs（实现规格）；出故障时写 postmortems（无指责事故复盘）；guides 存放操作、入门与运行手册并被各处引用。
规则与代理行为：proposals 每文件一个（0001-feature-name.md），状态 draft→fcp→accepted/rejected，结构含 Motivation/Design/Drawbacks/Alternatives/Unresolved questions；草稿超 14 天时代理提示作者推进、搁置或关闭。decisions 采用 MADR/Nygard 形式，获批即冻结，状态 proposed/accepted/deprecated/superseded，可经 Supersedes: 关联旧记录；新决策提交前代理扫描同子系统记录并提示候选。specs 从获批提案派生，采用 github/spec-kit 形式（specs/NNN-name/ 下 spec.md、plan.md、tasks.md 三个模板）；状态变为 shipped 后若该子系统报事故，代理建议使用复盘模板。postmortems 每事件一个（YYYY-MM-DD-name.md），含 Summary/Timeline/Root cause/What went well/Action items；代理生成 Related: 块链接同子系统旧复盘。guides 采用 Diátaxis how-to 形式，附带 last_verified 以在定期评审中暴露过时内容；复盘发布后代理扫描行动项中可成指南的后续，预填症状与时间线片段生成指南草稿。
使用方式：配套五个独立技能——frame-a-proposal（构思提案）、write-a-spec（写规格）、record-a-decision（记录决策）、write-a-postmortem（写复盘）、review-a-design（评审设计）。创建文档用 write({ document: { path, template: "<name>" } })，模板仅含结构与 frontmatter 骨架。
适用场景：需要以提案驱动设计、用 ADR 留存决策背景、以规格落地实现、并对事故做无指责复盘的工程或开源项目。
限制：资料未提供具体安装命令、收费方式、支持平台范围及实际效果，暂未提供。