From maigo
Triages inbound GitHub issues from a maintainer perspective using a 9-item checklist to decide READY / NEEDS_INFO / DUP / CLOSE verdicts, surface label disagreements, and draft responses with gh commands.
How this skill is triggered — by the user, by Claude, or both
Slash command
/maigo:strict-triageThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- mkdocs-include-start -->
Owner Agent: Soyo (Reviewer)
Consumers: /maigo:triage-issue step 3
Verdict starts at NEEDS_INFO. Maintainer time is the scarce resource. An issue with missing info or unclear scope wastes the next contributor who picks it up. "Looks reasonable at a glance" must not become "wasted three contributors before we realized scope was wrong" — the checklist is the guardrail.
These do not count as enough to upgrade to READY:
Every triage must walk through every item. Output explicitly marks [x] or [ ] per item.
[—] if not bug.[—] if not bug.[—] if not bug.#N..github/ISSUE_TEMPLATE/ exists in the repo, the relevant sections are filled. Missing template → [ ] and call out which sections are blank.Any [ ] blocks READY — verdict downgrades to NEEDS_INFO / DUP / CLOSE per the table below.
Tomori's .maigo/triage-rubric.md includes a ## Category line — one of
bug / feature / question / documentation / other. Soyo's output always
echoes Tomori's classification and adds a disagreement line if existing
GitHub labels point at a different category:
## Classification
- Tomori's call: bug
- Existing labels: [enhancement]
- Disagreement: ⚠️ labels say enhancement but body describes a regression after upgrade — recommend re-label as bug
If no existing labels → just print - Existing labels: (none).
If Tomori's call matches labels → just print - Aligned with existing labels and move on.
Classification is not part of the 9-item checklist — it is an orthogonal
output axis. An issue can be [x] on all 9 items and still have a label
disagreement worth surfacing.
| Verdict | When | Required output additions |
|---|---|---|
| READY | All 9 [x] (or [—] for items 2–4 if not bug) AND no classification disagreement | Suggested labels to add (good-first-issue if applicable); suggested assignee if you can infer one from CODEOWNERS or recent contributors |
| NEEDS_INFO | Items 1–4 partial | Specific bullet list of what's missing; polite draft asking for it (don't dump 9 questions — pick the 2–3 that unlock the rest) |
| DUP | Item 5 fails OR Tomori flagged a likely dup in rubric | Link the original #N; draft close as duplicate of #N with a one-line note on which one survives |
| CLOSE | Items 6 or 7 fail (out of scope / not actionable) | Draft close reason naming the specific item that failed; if question category, suggest moving to Discussions instead of close |
Don't combine verdicts. An issue cannot be "NEEDS_INFO and also a DUP" — pick the most actionable one (DUP wins, because asking for info is wasted work if the answer is "see #N").
strict-review's reviewer voice (calm, polite, doesn't retreat on the standard).For each verdict, provide one or more gh commands the maintainer can paste:
| Verdict | 建議操作 |
|---|---|
| READY | gh issue edit <N> --add-label <X>(每個 suggested label 一條) |
| NEEDS_INFO | issue 連結 + 純內文回覆 block(見下);gh issue edit <N> --add-label needs-info(若有此 label) |
| DUP | issue 連結 + 純內文回覆 block;gh issue close <N> --reason "not planned" |
| CLOSE | issue 連結 + 純內文回覆 block(close reason);gh issue close <N> --reason "not planned"(或 --reason "completed") |
Reply 慣例(NEEDS_INFO / DUP / CLOSE 的回覆部分):不用 gh issue comment --body-file -——改給 issue 連結 + 純內文 fenced code block,maintainer 在 GitHub 網頁直接貼上送出:
https://github.com/<owner>/<repo>/issues/<N>
````
```
Label / close 操作(READY / DUP / CLOSE 的 label 與 close 部分):這些沒有純文字等價物,仍用 gh 指令草稿(maintainer 自己貼到 terminal 執行)。
Skill does not run these commands. Suggest them; maintainer pastes them.
Reply 走「連結 + 純內文 block」慣例;label / close 走 gh 指令——對齊
/maigo:address-comments 的新分流。
## Verdict
READY | NEEDS_INFO | DUP | CLOSE
## Classification
- Tomori's call: <bug | feature | question | documentation | other>
- Existing labels: <list, or "(none)">
- <"Aligned with existing labels" | "Disagreement: ⚠️ <one-line reason>">
## Checklist
- [x] specific title
- [ ] repro steps — missing: 沒寫怎麼觸發
- [—] expected vs actual — skipped (not bug)
- [—] environment info — skipped (not bug)
- [x] no obvious duplicate — Raana grep cleared
- [x] in project scope
- [ ] actionable next step — author 提了想法但沒提怎麼驗收
- [x] follows issue template
- [x] signal not buried
## Suggested labels
- Add: `needs-info`, `question`
- Remove: `bug` (Tomori reclassified as question)
## Draft response
作者的描述提到 X 不如預期,但沒看到怎麼觸發——能補一段 minimal repro 嗎?
具體想看:(1) 哪個指令 / API 呼叫,(2) 跑出來實際 output 與你期待 output 的差。
有的話可以直接進開發;沒有的話我們會先標 needs-info 等補上再回來看。
## Reply
https://github.com/<owner>/<repo>/issues/<N>
````
gh issue edit <N> --add-label needs-info --remove-label bug
## Re-triage (when issue updated)
When the author replies with more info or a new comment lands:
- Walk through the previous round's `[ ]` items one by one
- New info clearing a `[ ]` → check it off; if all 9 now pass → verdict can upgrade
- Verdict can downgrade too (new comment reveals scope creep → CLOSE)
- "I think they answered it" without quoting the specific reply doesn't clear an item — quote it
## What this skill does NOT cover
- Running the actual gh commands (skill produces drafts, maintainer pastes)
- Code-level review of any attached patches (that's [`strict-review`](https://github.com/Lee-W/maigo/blob/main/skills/strict-review/SKILL.md))
- Reproducing bugs (no Taki in triage flow — if maintainer decides "yes worth pursuing", switch to `/maigo:go`)
- Classifying issues that are clearly spam or off-topic — just close, no checklist needed
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub lee-w/maigo --plugin maigo