classify-github-issues
Turn findings (from
+
) into a
github_backlog_input.json
that
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.
1. Map findings to label sets
For each finding, assign three labels:
Type label (pick one):
| finding kind | label |
|---|
| / / wrong/mislabeled existing thing | |
| / net-new capability | |
| process / administrative work | |
| docs-only change | |
When a finding is ambiguous between
and
, ask the user.
Priority label (based on
):
| severity | label |
|---|
| Critical | |
| High | |
| Medium | |
| Low | |
| (none) | — default Medium, note it |
Size label (based on estimated hours):
| hours | label |
|---|
| ≤ 2h | |
| 3–4h | |
| 5–8h | |
| 9–16h | |
| > 16h | |
Use these work-kind anchors:
| kind | baseline |
|---|
| rename (one spot) | 1–2h |
| rename (multi-screen) | 3–4h |
| disambiguation / mapping | 4–8h |
| missing field (UI + submit) | 6–8h |
| structural / new column | 4–6h |
If an item exceeds ~16h, propose splitting it instead.
2. Write the issue title
Specific and self-contained. Name the thing and the expected state:
- Good:
Portal label "Auto" should display "Automotive Cargo"
- Bad:
3. Write the issue body (Markdown)
markdown
## 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
so it
survives label changes.
4. Propose a milestone
Name the batch milestone (e.g.
,
Security Findings Q2 2026
). Ask
the user to confirm or rename it.
creates the milestone
if it doesn't exist.
5. Decide assignees
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
.
6. Show estimates table and get approval
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.
7. Write 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
, a non-empty
,
at least one label of each type/priority/size dimension, and a populated
.
Then hand off to github-create-issues for the visual dry-run and creation.