用途
本技能用于设计开发者反馈的流转路径：从 Discord、Slack、论坛、支持渠道、GitHub issue、销售通话和线下活动等来源，把开发者反馈送达决定产品方向的人，再把决定回复给提出者。它针对三类常见缺口：产品侧无人承诺接收和决策、需求以“解决方案”形式到达而缺少证据、无人负责告知提出者结果。
主要能力
- 通过一次性一问的访谈澄清关键前提，例如产品侧是否有明确接收人、每周可用工时、是否有临近的规划节点、是清理存量还是建立长期闭环、各渠道反馈量与产品跟踪位置等。
- 依据访谈答案决定工作顺序：无人接收时先做泄漏追踪和契约提案，不设计入口；仅有非正式接收人时先做泄漏追踪与契约，再并行设计入口；有明确接收人时按步骤全流程执行。
- 追踪反馈泄漏：抽样 60–90 天内 20–30 条请求，至少覆盖三个渠道，记录是否被捕获、是否到达产品、是否获得决定、提出者是否被告知，并优先修复流失最多的阶段。
- 与产品团队签订决策契约：明确接收人及备份、评审节奏与主持者、双方承诺、哪些内容流出本闭环、谁可发布日期、产品缺席评审时的处理方式。
- 选择记录载体，按产品阅读可能性、搭建成本和价值排序，可选产品现有空间、公开跟踪器、DevRel 自有看板或新工具，并处理开源与商业产品并存时的双记录链接。
- 设计捕获与合并动作：引导跳转、每周渠道清扫、代提记录、自动聚合，并按工时与请求量取舍；记录统一采用“问题优先”写法，按提出者人数而非提及次数计数。
- 运行交接：决策评审、产品规划席位、季度开发者声音报告、每周摘要，按产出决策的效率排序；评审议程以阻塞项和独立提出者数量排序。
- 闭环回复：公布状态词表（received、under review、needs discovery、planned、not planned、shipped、duplicate），按状态安排回复时点，明确说“不”并给出原因、替代方案和改变决定的条件。
- 度量闭环：建议保留三到五个指标并各配负责人和触发动作，如首次员工回复时间、捕获率、决定率、关闭率、由反馈驱动的发布数；目标值取自团队自身的泄漏追踪并标注为自设。
使用方式
以访谈开始，逐题询问并尽量提供选项，跳过用户已说明的内容；可将任务上下文存入 devrel-context.md 或沿用现有记忆系统。之后按访谈结果依次执行七个步骤：追踪泄漏、撰写产品契约、选择记录载体、捕获合并并撰写记录、运行交接、闭环回复、度量闭环。技能附带多个参考文件路径（如 ./references/loop-metrics.md、./references/product-contract-and-politics.md 等），资料中仅给出路径，未提供其具体内容。
适用场景
适用于有开发者社区、开源项目或商业 API/开发者工具的组织，尤其是反馈分散在多个渠道、产品团队看不到社区诉求、或反馈有明确规划节点需要对齐的团队。也适用于需要一次性清理积压反馈或建立长期机制的情形。
限制
资料未说明该技能的具体运行环境、安装命令、收费方式或实际效果数据。部分步骤依赖组织内产品团队的配合与决策授权，若产品侧无接收人，技能建议只做泄漏追踪与契约提案，不设计入口。技能明确与 issue 队列分诊、社区健康指标、DevRel 公司级 KPI、变更日志撰写、开发者分层、开发者拥护者、Stack Overflow 运营、公开路线图策略和 API 测试计划等相邻任务划分边界，不负责这些内容。