专治版本泛滥的发布守门人

社区开发者 gyeuun97 打造的发布纪律守门人，通过六大检查关卡强制冷却期、用户反馈验证与文档完整性审查，根治版本泛滥与半成品发布，让每次发布都经得起检验。

基本信息

• 技能名称?release-discipline
• 中文名称?专治版本泛滥的发布守门人
• 作者?gyeuun97
• 分类?其他
• 版本?未标注
• 标签?devops, product-management, project-program-management, automation, development-engineering

使用方法

使用说明
核心用法
release-discipline 是一款面向 AI Agent 和开发者的 发布纪律强制工具 ，在检测到发布意图（release/publish/deploy/배포 等关键词）时自动激活，执行六层递进式预审关卡：

1. Cooldown Check（24小时冷却期） ：阻断频繁发布冲动，少于24小时直接拒绝
2. User Feedback Check（用户反馈验证） ：检查 GitHub issues、npm 下载量等真实使用数据，无人使用的版本不得迭代
3. Documentation Check（文档完备性） ：README 缺失即阻断，无英文文档警告
4. Quality Check（实质内容审查） ：要求明确回答"本次发布唯一改进点"，禁止模糊表述
5. Kill Criteria Check（终止条件设定） ：强制定义项目失败标准，防止无限投入
6. Self-Contradiction Check（原则一致性） ：读取 SOUL.md 等原则文件，发现言行不一立即阻断
   通过后在 memory/release-log.md 记录发布日志，并支持每周回顾分析。
   显著优点
   心理刹车机制 ：将"发布冲动"转化为结构化反思，特别适合完美主义与拖延症两极的开发者
   数据驱动决策 ：用真实用户反馈替代主观感觉，避免"自嗨式迭代"
   原则锚定 ：通过读取项目原则文件，防止行动与价值观背离
   轻量零侵入 ：纯文档型 skill，不修改代码、不访问网络、不收集数据
   反模式针对性 ：精准狙击版本泛滥（17版/3天）、有始无终、文档债务等常见病症
   潜在缺点与局限
   刚性门槛可能误伤 ：紧急安全补丁也需等待24小时冷却，或关键反馈缺失时阻碍必要迭代
   依赖外部数据可及性 ：npm 下载量、GitHub issues 等数据若未公开或平台受限，检查效果打折
   主观判断灰色地带 ："质量"与"实质改进"的判定标准依赖用户自陈，存在自我说服空间
   T3 来源信任成本 ：社区个人开发者维护，长期更新与背书力度有限
   非自动化执行 ：仅作提醒检查，无法真正阻断 CI/CD 流程，最终纪律仍靠自觉
   适合的目标群体
   独立开发者/Solo Builder ：缺乏团队 Code Review 制衡，需外部化纪律约束
   开源项目维护者 ：面临社区压力频繁发版，需建立发布节奏权威
   AI Agent 工作流设计 ：为自主 Agent 设置行为边界，防止自动化导致的版本泛滥
   产品导向型技术团队 ：从"功能交付"转向"价值交付"的组织转型期
   使用风险
   流程摩擦成本 ：严格检查可能延长发布周期，与敏捷团队快节奏文化冲突
   数据隐私顾虑 ：需向 skill 暴露项目反馈数据（issues、下载量）以完成检查
   过度依赖风险 ：将发布决策外包给 checklist，可能削弱开发者的产品直觉
   与其他工具链冲突 ：若团队已用 semantic-release 等自动化工具，手动关卡可能造成流程断裂