Back to Details

classify-github-issues

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

classify-github-issues

分类GitHub Issues

Turn findings (from 
extract-findings
+ 
triage-findings
) into a 
github_backlog_input.json
that 
github-create-issues
can create. Unlike ADO, GitHub Issues are flat — type, priority, and size are expressed as labels; the batch grouping is a milestone; the parent tracker is a tracking issue created last.
Schemas live in 
references/data-contracts.md
— read it for the exact shapes.
将（来自
extract-findings
和
triage-findings
工具的）结果转换为
github-create-issues
工具可用于创建任务的
github_backlog_input.json
文件。与ADO不同，GitHub Issues是扁平化的——类型、优先级和规模都通过标签来体现；批量任务的分组通过里程碑实现；父追踪任务则是最后创建的追踪Issue。
相关模式定义在
references/data-contracts.md
文件中——如需了解具体格式请阅读该文档。

1. Map findings to label sets

1. 将结果映射为标签组

For each finding, assign three labels:
Type label (pick one):
finding kindlabel
rename
/ 
disambiguation
/ wrong/mislabeled existing thing
bug
missing
/ net-new capability
enhancement
process / administrative work
task
docs-only change
documentation
When a finding is ambiguous between 
bug
and 
enhancement
, ask the user.
Priority label (based on 
severity
):
severitylabel
Critical
P0
High
P1
Medium
P2
Low
P3
(none)
P2
— default Medium, note it
Size label (based on estimated hours):
hourslabel
≤ 2h
size:XS
3–4h
size:S
5–8h
size:M
9–16h
size:L
> 16h
size:XL
Use these work-kind anchors:
kindbaseline
rename (one spot)1–2h
rename (multi-screen)3–4h
disambiguation / mapping4–8h
missing field (UI + submit)6–8h
structural / new column4–6h
If an item exceeds ~16h, propose splitting it instead.
针对每个结果，分配三类标签：
类型标签（选其一）：
结果类型标签
rename
/ 
disambiguation
/ 现有内容命名错误/标签错误
bug
missing
/ 全新功能需求
enhancement
流程/行政类工作
task
仅文档变更
documentation
如果某个结果在
bug
和
enhancement
之间存在歧义，请询问用户确认。
优先级标签（基于
severity
）：
严重程度标签
Critical
P0
High
P1
Medium
P2
Low
P3
（无）
P2
— 默认中等，需标注说明
规模标签（基于预估工时）：
工时标签
≤ 2小时
size:XS
3–4小时
size:S
5–8小时
size:M
9–16小时
size:L
> 16小时
size:XL
可参考以下工作类型的基准工时：
工作类型基准工时
单处重命名1–2小时
多页面重命名3–4小时
歧义消除/映射4–8小时
新增字段（UI + 提交功能）6–8小时
结构调整/新增列4–6小时
如果某个任务的预估工时超过约16小时，建议将其拆分为多个任务。

2. Write the issue title

2. 编写Issue标题

Specific and self-contained. Name the thing and the expected state:
  • Good: 
    Portal label "Auto" should display "Automotive Cargo"
  • Bad: 
    Fix naming
标题需具体且完整，明确指出对象和预期状态：
  • 示例：
    Portal label "Auto" should display "Automotive Cargo"
    （好）
  • 反例：
    Fix naming
    （差）

3. Write the issue body (Markdown)

3. 编写Issue正文（Markdown格式）

markdown
undefined
markdown
undefined

Finding

结果详情

Current: <current value> Expected: <expected value> Section: <section>
Recommendation: <recommendation>
<notes if any>
Estimate: Xh

The raw hour estimate goes at the bottom of the body as `**Estimate:** Xh` so it
survives label changes.
当前状态: <当前值> 预期状态: <预期值> 所属模块: <模块>
建议方案: <建议>
<备注（如有）>
预估工时: Xh

原始工时预估需放在正文底部，格式为`**Estimate:** Xh`，这样即使标签发生变更，预估信息也能保留。

4. Propose a milestone

4. 提议里程碑

Name the batch milestone (e.g. 
Audit Wave 1
, 
Security Findings Q2 2026
). Ask the user to confirm or rename it. 
create_github_issues.py
creates the milestone if it doesn't exist.
为这批任务命名里程碑（例如
Audit Wave 1
、
Security Findings Q2 2026
）。请用户确认或重命名该里程碑。如果里程碑不存在，
create_github_issues.py
脚本会自动创建它。

5. Decide assignees

5. 确定经办人

A fresh backlog is usually created unassigned (assigned later in planning). Ask the user: leave unassigned, assign to themselves, or map per-row. Use GitHub username strings in 
assignees[]
.
新创建的待办事项通常不指定经办人（后续在规划阶段再分配）。请询问用户：是保持未分配状态、分配给自己，还是按行映射分配。在
assignees[]
中使用GitHub用户名。

6. Show estimates table and get approval

6. 展示预估工时表格并获取批准

Before writing the JSON, show a table and wait for explicit OK:
 key  | title (truncated)               | type        | priority | size   | est
------|---------------------------------|-------------|----------|--------|-----
 1    | Portal label "Auto" should...   | bug         | P1       | size:S | 4h
 2    | Add rate limiting to API        | enhancement | P2       | size:M | 6h
                                                                          ----
                                                                          ~10h
Let the user adjust any value before proceeding to the dry-run.
在生成JSON文件之前，需向用户展示如下表格并等待明确确认：
 序号 | 标题（截断显示）               | 类型        | 优先级 | 规模   | 预估工时
------|---------------------------------|-------------|----------|--------|-----
 1    | Portal label "Auto" should...   | bug         | P1       | size:S | 4h
 2    | Add rate limiting to API        | enhancement | P2       | size:M | 6h
                                                                          ----
                                                                          ~10h
在进入试运行阶段前，允许用户调整任意参数。

7. Write github_backlog_input.json

7. 生成github_backlog_input.json文件

Assemble the full JSON per the contract in 
references/data-contracts.md
and write it next to the findings file. Every item must have a 
key
, a non-empty 
title
, at least one label of each type/priority/size dimension, and a populated 
body
.
Then hand off to github-create-issues for the visual dry-run and creation.
按照
references/data-contracts.md
中的约定组装完整的JSON文件，并将其写入结果文件所在目录。每个任务项必须包含
key
、非空的
title
、至少一个类型/优先级/规模维度的标签，以及完整填充的
body
。
之后将任务交由github-create-issues工具进行可视化试运行和实际创建。