核心用法
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 等自动化工具，手动关卡可能造成流程断裂