Menu
先查验代码再创建 GitHub Issue。只要用户提出“先确认是不是问题再提 issue”“根据代码排查并建单”“把用户反馈转成 issue”这类请求，就必须启用本技能：先验证问题是否成立，证据不足时主动追问用户补充，再用 gh CLI 按模板创建 issue。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
用于按优先级串行修复 GitHub issue 的技能。只要用户提到“修 issue / 批量修 bug / 从 P0 开始处理 / 逐个修复问题 / 自动修复 issue 队列”等，都应启用。必须先复用 `gh.issue` 技能获取 issue，上游按 P0->P1->P2->P3->P4 排序，每次只处理一个 issue，并且每个 issue 都用子 Agent 修复；默认自动连续处理，只有遇到功能语义或产品策略需要产品经理确认时才暂停并向用户确认。每个成功修复的 issue 都必须由子 Agent 完成 commit（commit 信息关联 issue）并自动评论“已修复”后关闭。
Practical Anki v11 schema and import/export compatibility guide for Echoe. Use this skill whenever the user mentions Anki, .apkg/.anki2, notes/cards/revlog tables, notetype/deck JSON blobs, or fields like flds/sfld/csum/guid/usn/due. Even if the request sounds generic (for example "flashcard import" or "Anki sync issue"), consult this skill first before implementing or reviewing code.
面向 React + TypeScript 项目的代码坏味道审查 Skill。当用户提到 code review、clean code、技术债、可维护性、重构建议、组件太复杂、组件拆分过细、Hook 混乱、类型设计问题、PR 审查，或 @rabjs/react 领域模式与状态传递问题时，必须优先使用本 Skill。发现可执行问题时，必须使用 `gh` CLI 创建 GitHub issue。
审查需求文档（PRD/需求说明/业务规则）是否足够清晰、无歧义并可用于生成技术方案。Whenever user asks "帮我看需求是否清楚"、"这个需求能不能直接出技术方案"、"找出模糊定义/规则歧义/功能不清晰"，都应主动使用本技能，即使用户只提供需求片段或会议纪要。
Generate a Product Requirements Document (PRD) for a new feature. Use when planning a feature, starting a new project, or when asked to create a PRD. Triggers on: create a prd, write prd for, plan this feature, requirements for, spec out.
读取 Echoe 的 ADR 知识库（`arch.adr/references`）作为架构 Source of Truth，用于技术方案设计、PRD 对齐、架构评审与 Guardrails 检查。只要用户提到“按 ADR 出方案/按 ADR 对齐 PRD/查架构约束/避免架构漂移”，都应立即启用。`。
| name | github.create-issue |
| description | 先查验代码再创建 GitHub Issue。只要用户提出“先确认是不是问题再提 issue”“根据代码排查并建单”“把用户反馈转成 issue”这类请求，就必须启用本技能：先验证问题是否成立，证据不足时主动追问用户补充，再用 gh CLI 按模板创建 issue。 |
把“用户口头问题”转成“有证据、可执行、可追踪”的 GitHub issue。
本技能不做“听到问题就直接建单”，而是按以下原则执行：
出现以下任一语义时立即使用本技能：
如果用户只要求纯 issue 运维（如关单、打标签、批量改 assignee），应切换到 gh.issue。
至少收集到以下信息中的 3 项；不足时先提问：
创建 issue 前必须先确认：
gh --versiongh auth statusgh repo view --json nameWithOwner,viewerPermission若失败，先输出修复建议再停止建单流程。
先把用户描述重写为“可验证假设”，格式如下：
按最小必要范围定位证据：
confirmed：问题成立rejected：不成立（属于预期行为或误解）needs-info：证据不足当结果为 needs-info 或存在关键歧义时，向用户发起定向提问。
提问要求：
可用追问模板：
我还缺 2 条信息才能确认是否建单：
1) 你触发问题时的具体操作步骤（为什么问：用于确认复现路径）
2) 你期望的正确结果（为什么问：用于判断当前行为是否真的是 bug）
拿到用户反馈后，回到 Step 1/2 继续查验。
仅在以下条件同时满足时创建 issue：
否则输出“暂不建单 + 缺失信息列表 + 下一步建议”。
issue 正文必须使用以下模板（字段名保持一致）：
## 1) 总体结论
- `可方案化状态`: 可直接修复 / 有条件修复 / 暂不可修复
- `一句话结论`: ...
- `问题等级`: P0 / P1 / P2 / P3 / P4
- `置信度`: 高 / 中 / 低
## 2) 问题详情（证据表）
| ID | 严重度 | 问题类型 | 问题描述 | 用户证据 | 代码证据 | 影响范围 | 需确认问题 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| P1-1 | P1 | 规则歧义/流程缺口/实现缺陷/... | ... | ... | ... | ... | ... |
## 3) 复现步骤
1. ...
2. ...
3. ...
## 4) 预期行为
- ...
## 5) 最小补充信息集（MCI）
- `缺失信息`:
- `为什么必须补`:
- `建议由谁给出`:
## 6) 建议修复方向
- ...
## 7) 验收标准
- [ ] Given ... When ... Then ...
- [ ] Given ... When ... Then ...
这套结构来自 review.prd 的“结论 + 问题表 + MCI”思路，确保 issue 具备可执行性和可追踪性。
[create-issue][P?][category] <short summary>bug / logic / data / performance / securitybug、create-issue、P0~P4（三选一）推荐命令：
gh issue create --repo owner/repo --title "[create-issue][P1][bug] short summary" --body-file /tmp/create-issue-body.md --label bug --label create-issue --label P1
若标签不存在，不阻塞创建；在最终回执里标注“标签缺失”。
执行完成后，用以下结构向用户回执：
owner/repoconfirmed/rejected/needs-info#123 title - urlneeds-info 状态下强行建单。