用途：当 Infrahub 技能因规则缺失、写错或不清晰而让模型反复试错时，本技能判断是哪条规则出问题，并起草一份可审阅的技能摩擦 issue 草稿。它不提交、不决定报告去向，只把完整、脱敏的草稿交给 infrahub-reporting-issues，由后者负责 11 个仓库的注册表、路由、用户同意、提交方式和确认。触发语如“报告技能摩擦”“这个技能缺少说明能修吗”。Infrahub 产品本身的缺陷不属于本技能，应走 infrahub-reporting-issues。
主要流程：先确认缺口，依次使用验证器判定（同一目标上红转绿）、覆盖检查（ls skills/<skill>/rules/ 并 grep 主题）、修订差异（对比初稿与被接受的版本）、会话计数（重试、编辑反复等）；仅靠计数不足以定论。接着检查 opsmill/infrahub-skills 跟踪器，匹配则改为评论，否则新建带置信标签的 issue。随后分流：技能缺陷、产品缺陷或都不是；技能缺陷再分为 bug、feature 或 docs gap，其中 docs gap 要求未覆盖、文档逃逸失败且底层行为已定。定位涉及的具体规则文件或缺失处后，按 templates/skill-friction.md 填写草稿，并使用 bug:/feat:/bug(docs): 标题前缀。
脱敏与版本：起草前按规则移除可识别用户基础设施或组织的信息；标题头需带技能版本（SKILL.md 的 metadata.version）、Infrahub SDK 版本与 Infrahub 版本，均来自 infrahubctl info，且只复制版本值，不复制服务器地址和部署 ID，读不到就写 unknown。最后由本技能以 {type, title, body, searched, issue?} 负载交接，不直接 filing 或评论，也不保留本地状态。
限制：不处理 Infrahub 产品 / SDK 缺陷；未定位到技能与规则文件不起草；重复问题应评论而非新建；单个观察需标为未确认；错误文本须转述而非原样粘贴；本技能没有同意门、重复搜索或提交方式。