triage
维护者显式调用 /triage，AI 扮演分诊员：把 issue 和外部 PR 推过「分类 + 状态」双角色状态机，先验证真实性再决定拷问补全，最终把可委派的活儿写成 agent brief 交给无人值守 agent，被拒请求沉淀进 .out-of-scope/ 知识库去重。
仓库：mattpocock/skills
热度证据：同上，issue 工作流
五维评分
热度4/5
质量5/5
创新4/5
易用4/5
文档5/5
优秀点拆解
- 状态机建模：2 分类（bug/enhancement）× 5 状态（needs-triage/needs-info/ready-for-agent/ready-for-human/wontfix）双角色，每个 issue 恰好一个分类+一个状态，状态冲突显式交给维护者裁决，把混乱的 issue 工作流变成可枚举、可预测的决策空间
- 先验证后拷问的漏斗流程：bug 按 reporter 步骤复现、PR checkout diff 跑测试、输出 confirmed/failed/insufficient 三态结论，再决定要不要调用 /grilling 深挖——资源花在真实问题上，不给幻觉或重复 issue 做昂贵打磨
- Agent Brief 耐用性写作规范（AGENT-BRIEF.md）：不写文件路径和行号（会过期），只写接口/类型/行为契约；behavioral not procedural；必须带可独立验证的验收标准和显式范围边界——解决「brief 挂几周后代码已变」的跨时间委派痛点，附 3 正 1 反完整示例教学
- .out-of-scope/ 知识库边界拿捏极细：被拒 enhancement 按概念归档（多 issue 合并一文件）、匹配按语义相似度而非关键词，且「已实现」的 wontfix 明确不写入——防止记录 built feature 污染去重检查产生假拒绝
- 人机协作边界清晰：AI 评论强制带 AI 生成免责声明、推荐后等维护者指示、异常转移先问再动、openai.yaml 声明 allow_implicit_invocation:false 禁止 AI 自动发起分诊——可安全用于真实生产仓库
可复用的设计模式
- 专家 SOP → 有限状态机固化：把成熟工程实践抽象成角色+状态转移图，冲突、例外、人类裁决都画进流程，不让模型自由发挥
- 双层规范 + 配置映射：canonical 角色名与真实系统标签解耦，由 /setup-matt-pocock-skills 配置映射，同一套逻辑可跑 GitHub/Linear/本地文件
- 给未来 agent 写契约式任务卡：统一模板（Category/Summary/Current behavior/Desired behavior/Key interfaces/Acceptance criteria/Out of scope）+ 正反例教学，让委派标准可复用、验收可独立验证
- 决策持久化知识库（KB 模式）：被拒请求按概念建文档、写入带决策与理由、读取做相似度匹配、维护者三种处置路径（确认/重新考虑/不同意），并区分「拒绝」与「已实现」防止污染
适用场景
开源或内部仓库的 issue 分诊：分类、定优先级、识别缺信息的 issue 并批量发出 needs-info 提问把可执行的工作委派给 AFK（无人值守）agent：生成 agent brief 作为验收契约，维护者只审核不实现跨 GitHub/Linear/本地文件多 issue tracker 统一分诊工作流；通过 .out-of-scope/ 知识库沉淀拒绝决策，防止同类功能请求反复被提
边界与注意：完全依赖维护者在环确认（每一步都要人拍板，AI 无法自动关闭/转移 issue），单人小项目或无人值守场景用起来偏重；需先跑 /setup-matt-pocock-skills 配置标签映射，且依赖同仓库的 /grilling、/domain-modeling 等配套技能，单独拆用需自行补齐。
完整拆解分析文档
本页为摘要版，完整精读分析（核心机制、逐条优秀点拆解、写作过程）见本地 Markdown 文档：
analysis/mattpocock-triage.md