submit-lithe-issue

---
name: submit-lithe-issue
description: >-
  用户要求为 Lithe 报告问题、提出功能建议、整理 Issue 草稿或提交 GitHub Issue 时使用。
  根据用户描述追问缺失信息，采集并脱敏必要诊断数据，先查重和初步诊断，
  再严格遵循仓库最新 Issue 模板及 #394 提交须知；禁止用自由正文、API 或表单标记标签绕过 gh 模板。
---

# 提交 Lithe Issue

把用户提供的现象整理成维护者能够理解、复现和分派的 Issue。信息不明确时，
要么针对缺口追问，要么从与问题相关的环境中采集可验证、经过脱敏的数据；
不能猜测后直接提交。

## 触发与范围

以下请求使用本 Skill：

- “帮我报一个 Lithe 的 Bug / 提一个功能建议 / 提交 Issue”。
- “把这些现象、日志或截图整理成 Issue 草稿”。
- 用户明确输入 `$submit-lithe-issue`。

只要求排查、修复问题或解释日志，不代表授权提交 Issue。只要求草稿时，
完成可审阅草稿即可。用户已明确要求提交，且信息和提交条件齐备时，直接执行，
不重复索要发布授权。创建或修改本 Skill 本身也不代表要发布 Issue。

开始前加载 `.agents/skills/develop-lithe/SKILL.md`。GitHub 操作使用 `gh CLI`，
不用 Computer Use。沿用现有 `gh` 登录态；遇到沙盒访问限制时按环境规则申请
该命令所需权限，不输出 Token，不通过导出凭据或改用其他接口绕过限制。

## 1. 读取当前规则，选定模板

每次任务都读取这些真源，不依赖本 Skill 中固化的字段清单：

1. [提交 Issue 须知 #394](https://github.com/1lck/Lithe-IDEA/issues/394) 的正文；
   有相关补充时再读取评论。
2. 目标仓库默认分支的 `.github/ISSUE_TEMPLATE/config.yml`，以及将使用的
   Issue 模板全文。先通过 `gh api` 确认默认分支，不把本地开发分支当作线上规则。
3. 仓库现有标签和 `gh` 实际可用的原生模板。具体命令与兼容性规则见
   [gh 模板提交规则](references/gh-template-submission.md)。

默认目标为 `1lck/Lithe-IDEA`；用户指定其他仓库时以用户指示为准。请求前确认
目标身份和仓库重定向，所有 GitHub 命令都显式指定目标仓库。

现有行为出错使用问题报告模板；新增能力或改善工作流使用功能建议模板。
无法确定时先问清“当前行为哪里出错，还是希望增加什么能力”。一个 Issue
只处理一个可独立说明的问题，多个无关现象应分别整理。

模板是硬性要求。即使提交账号是仓库所有者或协作者，也不得援引 #394 中的
开发者例外使用空白 Issue，不得删除、修改模板来让不完整报告通过。

## 2. 先查重，再做初步诊断

用模块名、具体症状、错误码或关键错误文本搜索所有状态的 Issue，必要时分别
使用中文和英文关键词；阅读候选正文后判断是否为同一问题。不要把“搜索过一次”
当作已排除重复，也不要因同属一个模块就认定重复。

发往 GitHub 或其他外部搜索服务的关键词也必须先脱敏：只保留通用模块名、
症状、错误码和公开组件信息，不能把包含凭据、私人路径、私有项目名或内部地址
的原始错误整段作为查询。

```bash
gh issue list --repo 1lck/Lithe-IDEA --state all --search '模块 具体症状' --limit 50 --json number,title,state,url
gh issue view 123 --repo 1lck/Lithe-IDEA --json number,title,body,state,url
```

发现重复时，返回原 Issue 链接并整理可补充的新证据，优先复用原报告。
只有用户已授权向原 Issue 补充时才发表评论；否则把采用原 Issue 作为需要
用户选择的下一步。已关闭 Issue 也要检查关闭原因和修复版本，确认是否是
不同问题或新回归后再决定是否新建。

结合用户描述、脱敏日志、相关版本的已知问题以及必要的源码阅读进行初步诊断。
区分 Lithe 行为、项目配置、插件、工具链和外部服务故障。没有运行证据不能
宣称已复现，日志中出现错误也不能直接当作已证明的根因。

- 已确认是环境或配置问题：说明依据和修复办法，不发布成已确认的 Lithe Bug。
- 有合理的产品异常证据但根因未明：可以报告现象，在对应字段标明待确认的推测。
- 连产品异常本身都不清楚：继续追问或采集相关数据，不能为完成提交而编造结论。

这一步由当前 Agent 完成，不把原始诊断包再发送给其他 AI 或第三方服务。

## 3. 补齐信息：能验证就采集，不能验证就追问

先从本轮对话和已有证据提取信息，再列出会影响模板填写或问题判断的缺口。
优先自行完成任务范围内只读、低影响且可验证的采集，剩下的缺口集中提问，
每个问题说明它对应哪个字段或判断。已给出的信息不重复询问。

只有故障确实发生在当前机器、产品和项目中，才用本机数据填故障环境。
不能拿当前 checkout 的 SHA 代替用户正在运行的发布版本，也不能用 Agent
宿主机的系统版本代替用户报告的 Windows、远程机器或另一台电脑。

采集前必须读取 [环境信息核对清单](references/environment-checklist.md)：逐项
核对产品版本与安装、系统硬件、项目、配置扩展和发生条件，再按实际模块补齐
工具链、运行组件、文件系统、资源状态、显示输入、网络、权限、远程/虚拟化及
外部服务信息。所有相关环境项必须覆盖；逐项区分已确认、未采集及不适用，
记录来源和必要时点，关键缺口继续追问或采集，不能一律用“不适用”略过。
整理结果时按清单映射放回现有模板字段，不增加替代模板。

Bug 至少需要以下实质信息，即使某些字段在 YAML 中是可选的：

- **平台、模块、实际 Lithe 版本或运行构建 SHA**，以及与问题相关的操作系统
  版本、CPU 架构、插件与工具链版本。只采集相关依赖，不收集无关环境清单。
- **最小复现步骤、预期行为、实际行为**。步骤包括必要前置条件和触发动作；
  偶发问题记录发生频率、最近发生时间及已尝试的条件，不伪装成稳定复现。
- **影响与优先级**：依据模板中的优先级选项和已知用户影响选择；影响不清楚时
  询问是否阻断核心工作流、有无替代办法，不能自行把所有问题标为最高级。
- **性能问题的规模和条件**：项目/模块数量、相关文件数量与体积、相关单文件大小、
  当前任务、持续时间、CPU/内存等必要指标。采样写明口径和时点，区分源码规模
  与生成物/依赖/缓存；无法取得的数据如实标记，不猜测。
- **相关证据**：按当前 Wiki 的日志获取说明或实际产品诊断导出能力采集与故障
  时间对应的最小日志片段。交互或视觉问题尽量提供脱敏 GIF、截图或录屏；
  无法提供时说明具体限制，不伪造附件或公开链接。

功能建议至少说明用户正在完成的工作、现有困难和影响、期望的新行为、目标平台、
模块及优先级；替代方案和示例放到模板对应字段。不要把尚未调研的实现猜想写成
已确定的技术方案。

日志位置必须依据当前 Wiki、相关版本文档或实现确认，不硬编码某个人的主目录，
也不扫描整台机器。若需要用户导出诊断或提供材料，说明具体操作和脱敏范围。

复现中若需要启动、重启产品或执行会修改用户项目的动作，先确认已有任务授权
覆盖该动作；只为补齐报告不擅自进行破坏性复现。由本任务启动的应用和子进程，
在采集结束后按仓库规则关闭并清理。

## 4. 采集与提交前脱敏

采集以最少必要为限。采集前确定允许输出的字段和脱敏方式，工具输出进入对话前
先过滤或脱敏；优先使用产品自带的诊断脱敏导出，并再次检查结果。对已有材料
生成脱敏副本，不改写原始证据。无法安全输出时先在本地处理，只返回脱敏结果；
不能先把原文贴进对话、草稿或工具输出，再承诺提交前删除。

必须检查正文、标题、环境信息、配置/启动参数、代码块、附件内容与元数据、
文件名、图片、GIF 每一帧、视频画面、链接及其查询参数，移除或稳定替换：

- Token、密码、Cookie、Authorization、私钥、连接串、签名 URL 等秘密。
  秘密值完整移除，不能保留可识别的前后缀或因用户已贴出就再次引用。
- 用户名、邮箱、主机名、设备序列号/唯一标识、主目录和绝对路径中的身份信息。
- 私有仓库地址、内网域名/IP、客户名称、业务数据、无关源码和其他个人数据。

同一对象使用一致占位符，例如 `<USER>`、`<WORKSPACE>`、`<PRIVATE_HOST>`、
`<TOKEN>`；保留理解问题需要的相对目录、文件类型、错误码、时序和调用栈。
不要用不可逆的整段删除掩盖关键错误含义，也不要给占位符附上原值对照表。
环境字段逐类脱敏的要求见 [环境信息核对清单](references/environment-checklist.md)。

`gh auth token`、完整环境变量转储、凭据文件、数据库全量导出和整个私有项目
都不是诊断材料。脱敏映射和原始日志留在本地，不提交到仓库、不上传到 Issue，
也不上传到临时公开图床。无法可靠脱敏的附件不上传，改用文字或最小示例。

脱敏必须经过两轮核对：采集时生成脱敏副本；生成最终草稿、提交或追加附件前，
再对最终文本和实际附件复查。检查嵌套字段、URL 编码、多行密钥、压缩包内文件
和图片元数据；不能仅凭一次正则替换或工具声称已脱敏就判定合格。视觉材料使用
裁剪或不透明遮盖并导出实际成品，复查最终画面，不能依赖可移除图层或模糊处理。

脱敏后重新判断证据是否足以支持描述；不足就补采或追问。发现仍有敏感内容或
无法确认安全的材料，先修正或替换材料，不得提交该内容。只在真实完成查重、
脱敏等动作后勾选模板相应检查项，不能预先全部打勾。

## 5. 按当前模板准备可审阅内容

逐项对照选定模板填写草稿或表单字段：

- 保留模板标题前缀，用“触发条件 + 具体异常/诉求”写完整标题，避免“有 Bug”、
  “优化一下”等无信息标题。
- 按 `body` 顺序保留所有输入字段；Markdown 草稿使用 `### <attributes.label>`
  对应当前字段原名，不翻译、合并、改名、删节或另起一套顶层结构。静态说明不
  冒充用户回答；证据、推测和关联链接放在模板已有的适当字段中。
- 下拉框只使用模板允许的准确选项；复选框逐条保留原文，只勾选已完成事项。
  所有必填字段和必选检查项均须真实完成，不能用“待补充”“未知”或占位符充数。
- 可选但暂缺的字段保留，明确写“未采集（原因）”或“未提供”；只有实际不适用
  时才写“不适用”。不要复制 placeholder、留下空代码块或声称“见附件”却无附件。
- 检查版本、步骤、影响、日志时点和附件之间是否一致。公开可见内容全部脱敏。

标签先用 `gh label list` 查询。遵循模板自带类型标签，按实际证据补齐平台、
模块和优先级标签；优先使用现有的 `platform:*`、`area:*`、`P0/P1/P2` 等
约定，名称和大小写必须真实存在。不要凭空创建标签或给报告随意指定负责人。

跨平台选择必须有用户意图或多平台证据，不能把未验证平台写成已受影响；
Bug 模板没有跨平台选项时，按实际复现平台填写并在对应字段说明其他平台证据。
纯 Rust Core 问题可遵照 #394 的平台标签例外，但不能省略模板必填的平台和模块。
`issue-form:*` 是表单来源标记，不能手工添加来伪装通过表单，详见提交规则。

## 6. 严格走模板提交并核验

执行前必须阅读并遵守 [gh 模板提交规则](references/gh-template-submission.md)。
只有查重、必要信息、脱敏、字段检查和所需授权均满足，才进入提交。

提交结果必须回读核验：正文结构与字段值、真实完成的检查项、平台/模块/优先级
标签以及附件是否成功。命令报错不代表一定没创建成功；先根据返回 URL 或最近
创建记录确认结果，不能盲目重试导致重复 Issue。

最终交付按实际状态说明：

- **已提交**：给出真实 Issue 链接、所用模板、关键环境与证据、重要限制。
- **已有重复**：给出原 Issue 链接及可补充内容，不谎称创建了新报告。
- **仅草稿/等待补充**：给出完整草稿、缺失字段和具体待回答的问题。
- **gh 不支持当前表单**：给出按字段整理好的脱敏草稿和带 `template=` 的官方
  表单链接，明确“尚未提交”，说明无法继续的具体模板能力限制。

不能把打开页面、生成草稿、上传附件或命令部分成功描述为“已完整提交”。

More agent context in 1lck/Lithe-IDEA

13 other files this repository gives its agents.