Triage

Name: Triage
Author: shumingyang-opencode

ASecurity

讓 issues 與外部 PR 穿過分診角色的狀態機——分類、驗證、視需要 grill，並撰寫可供代理使用的簡報。

3 stars

0 votes

0 copies

1 views

Added 9/19/2026

ai-agents

Security Analysis

A100/100

Pro scans all 4 files and shows the line behind each finding

Scanned 10/7/2026

$npx -y skills add shumingyang-opencode/mattpocock-skills-zh-tw --skill triage --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Triage?

Add the live security badge to your README — it updates automatically with every re-scan.

[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/shumingyang-opencode-triage/badge)](https://www.skillsdirectory.com/skills/shumingyang-opencode-triage)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro

Files

SKILL.md

---
name: triage
description: 讓 issues 與外部 PR 穿過分診角色的狀態機——分類、驗證、視需要 grill，並撰寫可供代理使用的簡報。
disable-model-invocation: true
---

# 分診

在專案 Issue 追蹤器上，讓 issues 穿過由分診角色構成的小型狀態機。

如果這個 repo 把外部 pull requests 視為請求介面（見 issue-tracker 設定），分診也涵蓋它們：**PR 就是附帶程式碼的 issue**——相同的角色、相同的狀態、相同的機器，只有下面標註「for a PR」的幾處差異。依追蹤器設定，把孤伶伶的 `#42` 解析成 issue 或 PR。

分診期間貼到 Issue 追蹤器上的每一則評論或 issue，都**必須**以此免責聲明開頭：

```
> *This was generated by AI during triage.*
```

## 參考文件

- [AGENT-BRIEF.md](AGENT-BRIEF.md) — 如何撰寫耐用的代理簡報
- [OUT-OF-SCOPE.md](OUT-OF-SCOPE.md) — `.out-of-scope/` 知識庫如何運作

## 角色

兩個**類別**角色：

- `bug` — 有東西壞了
- `enhancement` — 新功能或改善

五個**狀態**角色：

- `needs-triage` — 需要維護者評估
- `needs-info` — 等待報告人提供更多資訊
- `ready-for-agent` — 規格完整，可供 AFK 代理使用
- `ready-for-human` — 需要人類實作
- `wontfix` — 不會處理

對 PR 而言，相同的狀態要對照附帶的程式碼來解讀：`ready-for-agent` 表示已附上簡報，代理應該在 diff 上採取下一步；`ready-for-human` 表示已準備好由人類合併。

每個已分診的 issue 都應該正好帶一個類別角色和一個狀態角色。如果狀態角色互相衝突，先標註出來並詢問維護者，再做任何其他事。

這些是正式的角色名稱——Issue 追蹤器實際使用的標籤字串可能不同。這個對應關係應該已經提供給你——如果沒有，執行 `/setup-matt-pocock-skills`。

狀態轉移：未加標籤的 issue 通常先進入 `needs-triage`；從那裡移到 `needs-info`、`ready-for-agent`、`ready-for-human` 或 `wontfix`。一旦報告人回覆，`needs-info` 就會回到 `needs-triage`。維護者隨時可以推翻——把看起來不尋常的轉移標註出來，並在繼續前詢問。

## 叫用

維護者叫用 `/triage` 並以自然語言描述他們想要什麼。解讀請求並採取行動。例如：

- 「讓我看任何需要我注意的內容」
- 「我們來看一下 #42」（issue 或 PR）
- 「把 #42 移到 ready-for-agent」
- 「有哪些是代理可以接手的？」

## 顯示需要關注的內容

查詢 Issue 追蹤器，呈現三個類別，最舊的優先：

1. **未加標籤** — 從未分診。
2. **`needs-triage`** — 評估進行中。
3. **自上次分診筆記以來有報告人活動的 `needs-info`** — 需要重新評估。

當 PR 在範圍內時，把外部 PR 納入這些類別，並為每一行標上 `[PR]` 或 `[issue]`。探索只會浮現*外部* PR（追蹤器設定會定義誰算是外部）——協作者進行中的 PR 不是分診工作。這個過濾只影響探索；被明確點名的 PR，無論作者是誰都會被分診。

顯示每個項目的數量與一行摘要。讓維護者挑選。

## 分診特定的 issue 或 PR

1. **收集上下文。** 讀取完整的 issue 或 PR（內文、評論、標籤、作者、日期；若是 PR，還包括 diff）。解析任何先前的分診筆記，這樣你就不會重問已經解決的問題。使用專案的領域詞彙表探索程式碼庫，並尊重該區域的 ADR。對程式碼庫執行兩項檢查：(a) **冗餘**——依領域概念（不只是請求的措辭）搜尋是否已有既有實作，並回報你查過哪裡。如果找到，它就是一項已實作的 `wontfix`（步驟 5）。(b) **先前拒絕**——讀取 `.out-of-scope/*.md`，浮現任何與此請求相似的內容。

2. **建議。** 告訴維護者你的類別與狀態建議及理由，外加與此請求相關的簡短程式碼庫摘要——包括它是否已實作。等待指示。

3. **驗證主張。** 在任何 grilling 之前，先檢查主張是否成立。對 bug，依報告人的步驟重現它。對 PR，確認 diff 做到它所宣稱的事——把它 checkout 出來，執行相關的測試或指令。回報發生的事：已確認（附程式碼路徑）、失敗，或細節不足（一個強烈的 `needs-info` 訊號）。已確認的驗證會讓代理簡報強上許多。

4. **Grill（如果需要）。** 如果請求需要充實內容，就一起運行 `/grilling` 與 `/domain-modeling` 技能——一輪一輪地問問題，把它 grill 成型，磨利領域術語，並在決策落定時就地更新 `GLOSSARY.md`/ADR。

5. **套用結果：**
   - `ready-for-agent` — 貼上代理簡報評論（[AGENT-BRIEF.md](AGENT-BRIEF.md)）。
   - `ready-for-human` — 結構與代理簡報相同，但要註明為什麼無法委派（需要判斷、外部存取、設計決策、手動測試）。
   - `needs-info` — 貼上分診筆記（見下方範本）。
   - `wontfix` — 關閉，評論依*原因*而定：
     - **已實作** — 這項變更已存在於程式碼庫。指出它在哪裡；**不要**寫入 `.out-of-scope/`（那個知識庫是給*被拒絕*的請求，不是給已建置的）。
     - **拒絕（bug）** — 有禮貌地說明，然後關閉。
     - **拒絕（enhancement）** — 寫入 `.out-of-scope/`，在評論中連結它，然後關閉（[OUT-OF-SCOPE.md](OUT-OF-SCOPE.md)）。
   - `needs-triage` — 套用角色。如果已有部分進展，可選擇加上評論。

## 快速狀態覆寫

如果維護者說「把 #42 移到 ready-for-agent」，相信他們並直接套用角色。先確認你即將做的事（角色變更、評論、關閉），然後行動。跳過 grilling。如果在沒有 grilling session 的情況下移到 `ready-for-agent`，詢問他們是否要撰寫代理簡報。

## Needs-info 範本

```markdown
## Triage Notes

**What we've established so far:**

- point 1
- point 2

**What we still need from you (@reporter):**

- question 1
- question 2
```

把 grilling 期間解決的一切記在「已確立內容」之下，這樣工作才不會遺失。問題必須具體且可執行，而不是「請提供更多資訊」。

## 恢復先前的 session

如果 issue 或 PR 上已有先前的分診筆記，讀取它們，檢查報告人是否已回答任何未決問題，並在繼續前呈現更新後的全貌。不要重問已解決的問題。

Attribution

shumingyang-opencode

View source See grades on GitHub More from shumingyang-opencode →

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

--- name: triage description: 讓 issues 與外部 PR 穿過分診角色的狀態機——分類、驗證、視需要 grill，並撰寫可供代理使用的簡報。 disable-model-invocation: true --- # 分診在專案 Issue 追蹤器上，讓 issues 穿過由分診角色構成的小型狀態機。如果這個 repo 把外部 pull requests 視為請求介面（見 issue-tracker 設定），分診也涵蓋它們：**PR 就是附帶程式碼的 issue**——相同的角色、相同的狀態、相同的機器，只有下面標註「for a PR」的幾處差異。依追蹤器設定，把孤伶伶的 `#42` 解析成 issue 或 PR。分診期間貼到 Issue 追蹤器上的每一則評論或 issue，都**必須**以此免責聲明開頭： ``` > *This was generated by AI during triage.* ``` ## 參考文件 - [AGENT-BRIEF.md](AGENT-BRIEF.md) — 如何撰寫耐用的代理簡報 - [OUT-OF-SCOPE.md](OUT-OF-SCOPE.md) — `.out-of-scope/` 知識庫如何運作 ## 角色兩個**類別**角色： - `bug` — 有東西壞了 - `enhancement` — 新功能或改善五個**狀態**角色： - `needs-triage` — 需要維護者評估 - `needs-info` — 等待報告人提供更多資訊 - `ready-for-agent` — 規格完整，可供 AFK 代理使用 - `ready-for-human` — 需要人類實作 - `wontfix` — 不會處理對 PR 而言，相同的狀態要對照附帶的程式碼來解讀：`ready-for-agent` 表示已附上簡報，代理應該在 diff 上採取下一步；`ready-for-human` 表示已準備好由人類合併。每個已分診的 issue 都應該正好帶一個類別角色和一個狀態角色。如果狀態角色互相衝突，先標註出來並詢問維護者，再做任何其他事。這些是正式的角色名稱——Issue 追蹤器實際使用的標籤字串可能不同。這個對應關係應該已經提供給你——如果沒有，執行 `/setup-matt-pocock-skills`。狀態轉移：未加標籤的 issue 通常先進入 `needs-triage`；從那裡移到 `needs-info`、`ready-for-agent`、`ready-for-human` 或 `wontfix`。一旦報告人回覆，`needs-info` 就會回到 `needs-triage`。維護者隨時可以推翻——把看起來不尋常的轉移標註出來，並在繼續前詢問。 ## 叫用維護者叫用 `/triage` 並以自然語言描述他們想要什麼。解讀請求並採取行動。例如： - 「讓我看任何需要我注意的內容」 - 「我們來看一下 #42」（issue 或 PR） - 「把 #42 移到 ready-for-agent」 - 「有哪些是代理可以接手的？」 ## 顯示需要關注的內容查詢 Issue 追蹤器，呈現三個類別，最舊的優先： 1. **未加標籤** — 從未分診。 2. **`needs-triage`** — 評估進行中。 3. **自上次分診筆記以來有報告人活動的 `needs-info`** — 需要重新評估。當 PR 在範圍內時，把外部 PR 納入這些類別，並為每一行標上 `[PR]` 或 `[issue]`。探索只會浮現*外部* PR（追蹤器設定會定義誰算是外部）——協作者進行中的 PR 不是分診工作。這個過濾只影響探索；被明確點名的 PR，無論作者是誰都會被分診。顯示每個項目的數量與一行摘要。讓維護者挑選。 ## 分診特定的 issue 或 PR 1. **收集上下文。** 讀取完整的 issue 或 PR（內文、評論、標籤、作者、日期；若是 PR，還包括 diff）。解析任何先前的分診筆記，這樣你就不會重問已經解決的問題。使用專案的領域詞彙表探索程式碼庫，並尊重該區域的 ADR。對程式碼庫執行兩項檢查：(a) **冗餘**——依領域概念（不只是請求的措辭）搜尋是否已有既有實作，並回報你查過哪裡。如果找到，它就是一項已實作的 `wontfix`（步驟 5）。(b) **先前拒絕**——讀取 `.out-of-scope/*.md`，浮現任何與此請求相似的內容。 2. **建議。** 告訴維護者你的類別與狀態建議及理由，外加與此請求相關的簡短程式碼庫摘要——包括它是否已實作。等待指示。 3. **驗證主張。** 在任何 grilling 之前，先檢查主張是否成立。對 bug，依報告人的步驟重現它。對 PR，確認 diff 做到它所宣稱的事——把它 checkout 出來，執行相關的測試或指令。回報發生的事：已確認（附程式碼路徑）、失敗，或細節不足（一個強烈的 `needs-info` 訊號）。已確認的驗證會讓代理簡報強上許多。 4. **Grill（如果需要）。** 如果請求需要充實內容，就一起運行 `/grilling` 與 `/domain-modeling` 技能——一輪一輪地問問題，把它 grill 成型，磨利領域術語，並在決策落定時就地更新 `GLOSSARY.md`/ADR。 5. **套用結果：** - `ready-for-agent` — 貼上代理簡報評論（[AGENT-BRIEF.md](AGENT-BRIEF.md)）。 - `ready-for-human` — 結構與代理簡報相同，但要註明為什麼無法委派（需要判斷、外部存取、設計決策、手動測試）。 - `needs-info` — 貼上分診筆記（見下方範本）。 - `wontfix` — 關閉，評論依*原因*而定： - **已實作** — 這項變更已存在於程式碼庫。指出它在哪裡；**不要**寫入 `.out-of-scope/`（那個知識庫是給*被拒絕*的請求，不是給已建置的）。 - **拒絕（bug）** — 有禮貌地說明，然後關閉。 - **拒絕（enhancement）** — 寫入 `.out-of-scope/`，在評論中連結它，然後關閉（[OUT-OF-SCOPE.md](OUT-OF-SCOPE.md)）。 - `needs-triage` — 套用角色。如果已有部分進展，可選擇加上評論。 ## 快速狀態覆寫如果維護者說「把 #42 移到 ready-for-agent」，相信他們並直接套用角色。先確認你即將做的事（角色變更、評論、關閉），然後行動。跳過 grilling。如果在沒有 grilling session 的情況下移到 `ready-for-agent`，詢問他們是否要撰寫代理簡報。 ## Needs-info 範本 ```markdown ## Triage Notes **What we've established so far:** - point 1 - point 2 **What we still need from you (@reporter):** - question 1 - question 2 ``` 把 grilling 期間解決的一切記在「已確立內容」之下，這樣工作才不會遺失。問題必須具體且可執行，而不是「請提供更多資訊」。 ## 恢復先前的 session 如果 issue 或 PR 上已有先前的分診筆記，讀取它們，檢查報告人是否已回答任何未決問題，並在繼續前呈現更新後的全貌。不要重問已解決的問題。