yida-feedback git:20261020.b175255A

Immutable. This exact content never changes and is served at /api/v1/blob/38a78e4b11310af9.

---
name: yida-feedback
description: OpenYida 本地使用故障的根因分析、脱敏反馈包与 GitHub Issue/Fork PR 辅助。适用于反复报错、技能容易误用、用户不会提 issue/PR 或没有 GitHub 账号和源码时；普通宜搭产品 VOC 清单用 yida-voc。
---

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

用户只需描述“哪里出错了”。默认环境是 npm/插件安装，无 OpenYida Git 工作区、无上游写权限，也可能没有 GitHub 账号。不要以 Git、gh、源码或宜搭登录作为整理反馈的前置条件。

## 何时进入

- 用户要求排查并反馈 OpenYida、整理 Issue、贡献修复或提 PR。
- 当前会话同一操作已重复失败，或明确的 CLI/技能缺陷导致反复绕路时，停止无修改重试，先处理原任务，再简短建议整理反馈。自动进入只允许本地分析/草稿；不得自动登录、安装工具、联网提交或不断提醒。
- 反馈建议前可读取 `openyida feedback status`；尊重当天/永久关闭。用户主动要求反馈不受提醒开关限制。同一会话同一问题只建议一次；当前上下文之外的发生频次写未知，不扫描完整历史。

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

## 收集与根因分析

1. 从当前会话提取目标、最短复现、期望与实际、报错关键片段、已尝试方法及其结果。先复用现有信息，确有阻碍时才询问缺失信息。
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。用户明确选择提交 Issue 后，用 `openyida feedback github status --json` 检查当前 GitHub 账号的 Star 与个人 Fork 状态；仅对明确未完成的操作提供一次可选邀请，已有的不重复提示，未知状态不说成未完成。按 [GitHub 提交](references/github-contribution.md) 处理用户选择、正文公开确认与查重。拒绝 Star/Fork 不影响提交；登录由用户在可信本机流程完成，不索取 Token。
- **有账号，希望提交修复 PR**：仅适用于公开 OpenYida CLI/skill/docs 的可验证问题。先准备最小修复和验证，再通过用户自己的 Fork 提交到公开上游，详见同一参考。没有源码时由 Agent 在独立目录准备公开源码，不修改 npm 全局安装或用户业务目录。无法定位/验证时如实写入测试对比，优先交付 Issue 草稿；不要承诺未经验证的修复。

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

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