（14267期）release-discipline – 专治版本泛滥的发布守门人

专治版本泛滥的发布守门人 社区开发者 gyeuun97 打造的发布纪律守门人，通过六大检查关卡强制冷却期、用户反馈验证与文档完整性审查，根治版本泛滥与半成品发布，让每次发布都经得起检验。 使用说明 核心用法 release-discipline 是一款面向 AI Agent 和开发者的发布纪律强制工具，在检测到发布意图（release/publish/deploy/배포 等关键词）时自动激活，执行六层递进式预审关卡： Cooldown Check（24小时冷却期）：阻断频繁发布冲动，少于24小时直接拒绝 User Feedback Check（用户反馈验证）：检查 GitHub issues、npm 下载量等真实使用数据，无人使用的版本不得迭代 Documentation Check（文档完备性）：README 缺失即阻断，无英文文档警告 Quality Check（实质内容审查）：要求明确回答"本次发布唯一改进点"，禁止模糊表述 Kill Criteria Check（终止条件设定）：强制定义项目失败标准，防止无限投入 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 等自动化工具，手动关卡可能造成流程断裂 原始说明 Enforce release discipline for AI agents and developers. Prevents version spam, forces quality checks before publishing, and maintains a 24-hour cooldown between releases. Use when the user wants to publish, release, deploy, or bump versions. Triggers on "release", "publish", "deploy", "version bump", "npm publish", "릴리즈", "배포", "버전".