用途：Quality Judgment 用于在开发与发布环节中，判断某个功能是否“足够好、可以发布”，以及何时应继续投入打磨。它围绕质量标准、发布决策、够好与完美之辨、质量一致性展开。
主要能力：要求在动手构建前先定义质量标准，而不是在发布决策时才临时确定；标准应随场景变化，核心流程（注册、支付、核心动作）的质量门槛必须高于次要功能；必须区分“能正确运行”与“运行良好”；标准不可隐式存在，要写下来。
发布决策框架：是否解决核心用户问题，否则不发；是否存在会导致数据丢失、安全问题或流程中断的缺陷，若有则不发；用户能否无需解释就理解用法，否则先修引导；是否愿意让记者报道这一体验，否则继续打磨；剩余工作是打磨还是实质内容，打磨可后置，实质不可。
够好与完美：核心价值可用时即使边缘粗糙也应发布；采用渐进式质量，先发核心再快速跟进打磨；要能区分“以后会修”中真正会修与不会修的情况；不要因外观问题在用户等待核心功能时扣留发布；也不要为赶日期而在核心流程中发布已知损坏的体验。
质量一致性：产品整体质量应保持一致，一个精致功能挨着一个损坏功能会侵蚀信任；建立质量仪式，如缺陷排查、内部试用、定期 QA；把质量债与技术债一同追踪；不要因新功能兴奋而忽视质量回退。
使用方式：在对话中输入 /quality-judgment 以应用质量判断约束；或输入 /quality-judgment <feature> 评估所描述功能是否可发布。
适用场景：功能发布评审、原型与正式流程的质量门槛设定、核心流程与次要功能的分级、发布前检查。
限制：资料未提供具体实现方式、平台支持、收费或价格、效果数据；本技能为约束性指导，不替代实际测试与缺陷修复流程。