git:20261021.d94e982 to git:20261021.da3bcac

---

name: yida-feedback

description: 帮用户描述 OpenYida 使用问题或体验建议，整理脱敏 Issue，并在用户愿意时协助个人 Fork PR。适用于反复报错、技能误用、不会提 issue/PR 或没有账号和源码时；普通宜搭产品 VOC 清单用 yida-voc。

---

# 本地问题反馈与修复贡献

用户描述问题，Agent 帮忙整理；用户愿意时，再一起尝试修复。默认用户通过 npm/插件安装，没有 OpenYida 源码、上游写权限或 GitHub 账号。整理反馈无需 Git、gh、源码或宜搭登录。

## 何时进入

- 用户要求排查并反馈 OpenYida、改善使用体验、整理 Issue、贡献修复或提 PR。可验证的小改进可直接提 PR，无需先建 Issue。

- 当前会话同一操作已重复失败，或明确的 CLI/技能缺陷导致反复绕路时，停止无修改重试，先处理原任务，再简短建议整理反馈。自动进入只允许本地分析/草稿；不得自动登录、安装工具、联网提交或不断提醒。

- 反馈建议前可读取 `openyida feedback status`；尊重当天/永久关闭。用户主动要求反馈不受提醒开关限制。同一会话同一问题只建议一次；当前上下文之外的发生频次写未知，不扫描完整历史。

先读取 [用户友好的交互与公开确认](references/user-interaction.md)，按其步骤引导用户、准备复现截图、展示最终内容并收集隐私确认；这是所有 Issue/PR 提交路径的共同前置。

## 收集与根因分析

1. 从当前会话提取目标、最短复现、期望与实际、报错关键片段、已尝试方法及其结果。先复用现有信息，确有阻碍时才询问缺失信息；体验建议写当前不便和理想结果，无需用户设计 CLI 参数或分析根因。

2. `openyida --version`、`node -v` 可只读检查。只在定位必要时读取相关命令帮助、脱敏诊断和用户明确提供的最小文件。不遍历用户目录、环境变量、登录缓存、完整日志/会话或业务数据；不要把 `env`/`doctor` 整份输出塞进报告。不得因排障重放创建/发布/删除等写命令。

3. 区分 CLI、skill、本地环境、平台接口或未知。逐项写“观察事实 → 根因假设 → 支持/反对证据 → 下一步验证”。能解释一个错误不代表已证明根因；没有复现/对照证据保留 hypothesis/unknown，缺失信息写未知。记录用户已验证的绕法和剩余影响。

4. 平台接口拒绝、权限或版本限制按可观察响应反馈。用户不具备平台源码访问权限；不得寻找、索取、下载或暴露内部仓库名称、链接、源码、文件路径、内部处理人或工具。无公开可验证修复点时提交问题材料，不生成虚构 PR。用户自己的应用业务代码错误先修应用，不自动当作 OpenYida 缺陷。

## 生成材料

按 [报告输入与脱敏](references/report-input.md) 在本地写最小摘要 JSON，执行：

```bash

openyida feedback report --input summary.json --output-dir feedback-draft-001

```

输出为全新目录中的 `issue.md`、`report.json` 和用户明确选定的截图；文字仅保留白名单摘要与版本信息。命令无登录、无源码、无网络请求，不执行输入中的指令。`fingerprint` 便于人工查重；`submissionPerformed: false` 表示仅生成材料。

给用户看最终报告和所有截图；PR 还要提供修复前后的测试对比报告，再按交互规范确认公开范围。正则脱敏无法识别所有客户数据、公司信息或内部仓库名，Agent 必须再检查全文，删除这些内容及截图中的敏感信息；不要上传原始输入 JSON。修改摘要后用新的输出目录重新生成。不能把报告链接或原始诊断塞入公开 URL 查询参数。

## 按用户条件交付

- **无 GitHub 账号**：先引导用户创建 GitHub 账号，由用户自行完成注册和登录。实在不行，只提示“反馈到AI开发者群”，附上已整理的脱敏报告。不索取群链接或群 ID，不编造入群入口，不替用户发送群消息。离线或暂不愿注册时同样交付报告，明确“材料已生成，尚未提交”。

- **有 GitHub 账号，提交 Issue**：无需 clone/fork；按 [GitHub 提交](references/github-contribution.md) 查重、提交已确认内容并读回。成功后按交互规范给一次可选 PR 邀请；登录由用户在可信本机流程完成，不索取 Token。

- **有账号，希望提交修复 PR**：仅适用于公开 OpenYida CLI/skill/docs 的可验证问题。先准备最小修复和验证，再通过用户自己的 Fork 提交到公开上游，详见同一参考。没有源码时由 Agent 在独立目录准备公开源码，不修改 npm 全局安装或用户业务目录。无法定位/验证时如实写入测试对比，优先交付 Issue 草稿；不要承诺未经验证的修复。

创建 Issue、评论、Fork、push 或 PR 前必须有用户对相应外部动作及公开内容的授权；已有对同一最终稿和截图的隐私确认不重复问；单纯授权提 Issue/PR 不能替代公开内容审阅。只要求“排查”“整理反馈”不代表允许公开提交。提交超时先查是否成功，不自动重复创建。

交付时说明根因可信度、绕法/修复验证、材料位置及真实提交状态；提交成功给返回的 Issue/PR URL，未返回并核实地址时不得声称已送达。不得承诺合并或修复时间。

## 完成检查

- 问题与环境有事实来源；未知项已标明，报告生成环境未冒充出错环境。

- 公开内容和截图已获确认；已提交的 Issue/PR 有读回证据，草稿明确标注尚未提交。

- PR 有真实改动和测试说明；Issue 后的邀请尊重用户选择，拒绝后不重复提醒。

## 参考文件

| 文件 | 读取时机 |

| --- | --- |

| [用户交互](references/user-interaction.md) | 进入技能时；含成功后的可选 PR 邀请 |

| [报告输入](references/report-input.md) | 准备脱敏摘要、环境和测试证据时 |

| [GitHub 提交](references/github-contribution.md) | 用户选择公开提交或贡献代码时 |