用途：在收到代码评审意见、PR 反馈、代理评审结论或变更请求时，以技术严谨的方式处理反馈。评审意见是需要评估的技术输入，不是必须执行的命令流；不追求完美，只应用让改动更安全、更清晰或更符合契约的反馈，对错误、臆测或增加不必要复杂度的反馈进行反驳。
主要能力：提供反馈分类（有效、无效、不清晰、权衡、已处理）及对应动作；给出验证关卡（是否匹配原始需求、是否保留既有行为、是否符合项目约定、是否引入未被要求的功能、是否破坏公共契约、是否有清晰验证路径）；列出需要反驳的情形，如破坏既有行为、与需求冲突、违反约束、引入未使用功能（YAGNI）、需要架构决策、安全或性能上的臆测；提供回复格式（已处理、已推迟/反驳、验证）；指定实现顺序：先澄清阻塞与模糊项，再修复正确性/安全/数据丢失问题，再修小的机械问题，再做大重构，然后运行针对性验证，必要时用 doing-code-review 重新评审。
使用方式：编码相关工作时先加载 engineering-principles；在 doing-code-review 产生发现或评审意见后使用本技能；按区域（正确性、测试、架构、安全、性能、风格）分组评论，逐条分类，成小批次实施有效修复，运行针对性验证，报告改动、推迟项与验证结果。回复 GitHub 行内评论应在线程内进行，而非作为无关的顶层 PR 评论。
适用场景：收到评审意见、PR 反馈、代理评审发现、请求变更或建议时；需要判断某条反馈是否值得采纳、是否需要先澄清时。
限制：不能替代具体工程判断；对不清晰项应先提具体问题而非部分实现；涉及架构决策应转交用户/编排者或 architecting-changes；安全或性能反馈需先索要威胁模型、度量或具体失败模式。相关技能包括 doing-code-review、verification-before-completion、architecting-changes、security-and-hardening、performance-optimization、code-simplification。材料未提供定价、平台支持、安装步骤等信息。