strict-triage

name	strict-triage
description	This skill should be used when triaging an inbound GitHub issue from a maintainer perspective — applying a 9-item checklist to decide a verdict (READY / NEEDS_INFO / DUP / CLOSE), surfacing classification disagreements with existing labels, and producing a draft response plus gh command suggestions. Parallel to strict-review but for issues, not code.

Strict Triage

Owner Agent: Soyo (Reviewer) Consumers: /maigo:triage-issue step 3

Core stance: default NEEDS_INFO

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:

• "感覺像是 bug 吧" — without repro steps, you can't tell
• "之前有人問過類似的" — without the prior issue # linked, the next contributor will re-investigate
• "我猜作者意思是 X" — issue body is the source of truth; if it's ambiguous, ask

The 9-item triage checklist

Every triage must walk through every item. Output explicitly marks [x] or [ ] per item.

1. Specific title — Title points at a concrete behaviour or feature, not "doesn't work" / "請新增功能" / "壞了"
2. Repro steps (bug only) — If classified as bug: numbered or bulleted steps a maintainer can run. Skip with [—] if not bug.
3. Expected vs actual (bug only) — Both sides stated; "it crashes" without "what should have happened instead" doesn't count. Skip with [—] if not bug.
4. Environment info (bug only) — Version / OS / runtime / relevant config. Skip with [—] if not bug.
5. No obvious duplicate — Raana's grep / linked-issue scan did not surface a same-bug / same-request issue. If one was found, must reference its #N.
6. In project scope — Belongs in this repo, not an upstream dep / unrelated tool / fork-only concern.
7. Has actionable next step — A maintainer could write a 1-line response that moves it forward (ask X, label as Y, assign to Z, close as W). "Interesting thought" with no path forward fails this.
8. Follows issue template — If .github/ISSUE_TEMPLATE/ exists in the repo, the relevant sections are filled. Missing template → [ ] and call out which sections are blank.
9. Signal not buried — Discussion / "+1" / "me too" comments do not overwhelm the original report. If they do, summarise the core in your draft response so future readers don't have to dig.

Any [ ] blocks READY — verdict downgrades to NEEDS_INFO / DUP / CLOSE per the table below.

Classification (parallel to checklist, always required)

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 semantics

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").

Draft response rules

• One paragraph max. Maintainer pastes this, doesn't edit it down.
• Cite line numbers / sections of the issue body so the author knows you read it.
• No "thanks for filing!" opening fluff. Skip straight to the substance.
• End with a concrete ask or a concrete next step — never an open question with no scaffolding.
• Polite but not soft — same stance as strict-review's reviewer voice (calm, polite, doesn't retreat on the standard).

gh command suggestions

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 的新分流。

Output format

## 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>

````

Suggested gh commands

gh issue edit <N> --add-label needs-info --remove-label bug

What's good (optional)

• 作者引用了相關 PR #123 的 commit hash，幫忙縮小了範圍

## 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