用途：当用户在使用过程中出现摩擦、bug、改进愿望，或用了新的说法时，feedback 技能负责在指定仓库提交 GitHub issue，让协作者 Brent 据此修复和改进工具。用户 Blake 不是开发者，因此不应让他接触 GitHub，沟通需用平实语言。
主要能力：按信号类型打标签，便于快速分诊。困惑或“没搞懂”记为 friction；报错或未按预期工作记为 bug；想法或更顺手的做法记为 improvement；git-ops 需要猜测路由的措辞记为 vocabulary；其他值得关注的内容记为 observation。对 vocabulary 尤其要逐字记录用户原话，不得改写，因为这些措辞会被反馈进路由器。
使用方式：先搜索是否已有同类 issue，避免重复。命令为 gh issue list --search "<key words or the verbatim phrase>" --state all --limit 5。若已有接近的 issue，则用 gh issue comment <number> --body "Heard again: "<verbatim>"" 追加评论后停止。若无匹配，先确认仓库上下文并确保标签存在：gh repo view --json nameWithOwner -q .nameWithOwner；gh label create <label> --color ededed 2>/dev/null || true；再用 gh issue create 提交，标题格式为 [<type>] <short scannable summary>，正文包含用户正在做什么、原话、发生了什么、用户反应。若 gh 报错（认证、网络、无仓库），应原样报告错误并停止，不得静默吞掉。
适用场景：用户表达困惑、遇到错误、提出改进想法，或路由器无法理解其措辞时。
限制与安全：issue 是共享且持久的，正文中绝不能包含文件内容、密钥、令牌、API 密钥或完整文件路径，只记录措辞和上下文。对 friction、bug、improvement 要温暖地确认已转达；对 vocabulary 和 observation 则静默提交，不打断用户。与用户沟通时避免 GitHub 术语，例如不说“我提交了 #42 号 issue”，而说“知道了，我已经告诉 Brent，让他把这里弄得更清楚”。