apm-triage-panel

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

APM Triage Panel -- Single-Issue Triage Orchestration

APM分类面板——单问题分类编排

The panel is fixed at 3 mandatory specialist lenses + up to 3 conditional lenses + 1 arbiter lens = up to 6 active persona sections in one triage comment (3 mandatory + 3 conditional). You play each lens in turn from inside a single agent loop (progressive-disclosure skill model -- no sub-agent dispatch). Routing chooses which lenses execute; it never changes which headings appear in the final comment.

This skill mirrors the

apm-review-panel

orchestration shape on purpose. Same single-comment discipline, same completeness gate, same persona-pass procedure -- only the personas, the rubric, and the output template differ.

该面板固定包含3个必填专家视角 + 最多3个条件视角 + 1个仲裁视角 = 单条分类评论中最多6个活跃角色板块（3个必填+3个条件）。你将在单个Agent循环中依次扮演每个视角（渐进式披露Skill模型——不调度子Agent）。路由选择执行哪些视角；但不会改变最终评论中显示的标题。

本Skill刻意镜像

apm-review-panel

的编排架构。遵循相同的单评论规则、完整性检查、角色传递流程——仅角色、评估标准和输出模板有所不同。

Agent roster

Agent阵容

Agent	Persona	Always active?
DevX UX Expert	User-Need Reviewer	Yes
Supply Chain Security Expert	Risk-Surface Reviewer	Yes
APM CEO	Triage Arbiter	Yes (always arbitrates)
OSS Growth Hacker	Contributor-Tone Reviewer	Conditional (see below)
Python Architect	Architecture Reviewer	Conditional (see below)
Doc Writer	Documentation Reviewer	Conditional (see below)

Skipped by default: CLI Logging Expert, Auth Expert. Triage operates on issue intent, not on diffs -- those personas are invoked downstream by

apm-review-panel

once a PR exists.

Agent	角色	是否始终激活？
DevX UX Expert	用户需求审核员	是
Supply Chain Security Expert	风险面审核员	是
APM CEO	分类仲裁员	是（始终参与仲裁）
OSS Growth Hacker	贡献者语气审核员	条件激活（见下文）
Python Architect	架构审核员	条件激活（见下文）
Doc Writer	文档审核员	条件激活（见下文）

默认跳过的角色：CLI日志专家、认证专家。分类基于问题意图，而非代码差异——这些角色会在PR创建后，由

apm-review-panel

在下游调用。

Routing topology

路由拓扑

   devx-ux-expert      supply-chain-security-expert
        \_______________________/
                    |
                    |   <-- python-architect (conditional; design /
                    |       architecture / new primitive / new schema)
                    |
                    |   <-- doc-writer (conditional; docs work or
                    |       user-facing change that needs new doc pages)
                    v
                apm-ceo               <----  oss-growth-hacker
           (final call / arbiter)           (conditional; tunes tone
                                             when author is new)

Specialists raise findings independently -- no implicit consensus.
CEO arbitrates the theme, milestone, priority, and tone of the reply. CEO has the final call on the decision rubric.
Growth Hacker, Python Architect, and Doc Writer are side-channels to the CEO when activated. They never block a specialist finding; they feed the CEO's arbitration:
- Growth Hacker tunes the comment's tone for first-time and low-interaction contributors.
- Python Architect flags feasibility and cross-cutting impact, and pushes the decision toward
```
status/needs-design
```
  when warranted.
- Doc Writer flags whether docs work is implied and whether the suggested comment wording is grounded in the user vocabulary used in the README and guides.

   devx-ux-expert      supply-chain-security-expert
        \_______________________/
                    |
                    |   <-- python-architect（条件激活；设计/
                    |       架构/新原语/新 schema）
                    |
                    |   <-- doc-writer（条件激活；文档工作或
                    |       需要新增文档页面的用户侧变更）
                    v
                apm-ceo               <----  oss-growth-hacker
           (最终决策/仲裁员)           (条件激活；针对新作者
                                             调整语气)

专家独立提交发现——无需达成隐含共识。
CEO负责仲裁回复的主题、里程碑、优先级和语气。CEO对决策标准拥有最终决定权。
Growth Hacker、Python Architect和Doc Writer是CEO的辅助渠道，仅在激活时生效。他们不会阻碍专家的发现；而是为CEO的仲裁提供信息：
- Growth Hacker针对首次贡献或低互动贡献者调整评论语气。
- Python Architect标记可行性和跨领域影响，并在必要时推动决策转向
```
status/needs-design
```
  。
- Doc Writer标记是否涉及文档工作，以及建议的评论措辞是否符合README和指南中使用的用户词汇。

Conditional panelists

条件激活角色

Three personas are conditional: OSS Growth Hacker, Python Architect, and Doc Writer. Each follows the same shape: an explicit YES/NO activation rule plus an inactive-reason fallback. Maximum lenses in a single triage = 6 (3 mandatory + 3 conditional).

三个角色为条件激活：OSS Growth Hacker、Python Architect和Doc Writer。每个角色都遵循相同的规则：明确的YES/NO激活规则加上未激活原因的 fallback。单次分类中最多包含6个视角（3个必填+3个条件）。

OSS Growth Hacker

Activate

oss-growth-hacker

if either rule below matches.

Fast-path author trigger. Activate the Growth Hacker lens immediately when the issue's author meets ANY of:
- GitHub
```
author_association
```
  is
```
FIRST_TIME_CONTRIBUTOR
```
  ,
```
FIRST_TIMER
```
  , or
```
NONE
```
  against
```
microsoft/apm
```
  .
- Author has fewer than 3 prior interactions (issues + PRs + comments) on
```
microsoft/apm
```
  .
- Issue body explicitly says "first issue", "new to APM", or similar.
Fallback self-check. If author signals are ambiguous, answer this before activating the lens:

Would the warmth, framing, or pointer-set in the reply meaningfully change if I knew this was someone's first interaction with the project? Answer YES or NO with one sentence. If unsure, answer YES.

Routing rule:

YES -> take the OSS Growth Hacker lens (per the Persona pass procedure) and capture its tone-tuning findings.
NO -> record
```
OSS Growth Hacker inactive reason: <one sentence>
```
in working notes; do not take the lens.

当以下任一规则匹配时，激活

oss-growth-hacker

。

快速路径作者触发。当问题作者满足以下任一条件时，立即激活Growth Hacker视角：
- 在
```
microsoft/apm
```
  仓库中，GitHub
```
author_association
```
  为
```
FIRST_TIME_CONTRIBUTOR
```
  、
```
FIRST_TIMER
```
  或
```
NONE
```
  。
- 作者在
```
microsoft/apm
```
  中的历史交互（问题+PR+评论）少于3次。
- 问题正文中明确提到“first issue”、“new to APM”或类似表述。
Fallback自我检查。如果作者信号不明确，在激活视角前回答以下问题：

如果我知道这是用户首次与项目交互，回复的热情度、框架或指引是否会有显著变化？用一句话回答YES或NO。若不确定，回答YES。

路由规则：

YES -> 采用OSS Growth Hacker视角（遵循角色传递流程）并记录其语气调整发现。
NO -> 在工作笔记中记录
```
OSS Growth Hacker inactive reason: <一句话说明>
```
；不采用该视角。

Python Architect

Activate

python-architect

if either rule below matches.

Fast-path label / scope trigger. Activate the Architecture Reviewer lens immediately when ANY of:
- The issue carries
```
type/architecture
```
  (current or proposed) or the
```
breaking-change
```
  preserved label.
- The issue body proposes a new top-level CLI command, or a schema change to
```
apm.yml
```
  ,
```
apm.lock.yaml
```
  , or
```
apm-policy.yml
```
  .
- The issue body contains keywords indicating cross-module or cross-file work, a new module, a new pattern, a new contract, or a new primitive design -- e.g. "refactor", "rearchitect", "new module", "design", "abstraction", "schema change", "pluggable", "introduce X pattern".
Fallback self-check. If the issue is ambiguous, answer this before activating the lens:

Does this issue, if accepted as written, require a cross-cutting design decision (interface, data model, migration boundary, or new primitive) before code can land safely? Answer YES or NO with one sentence. If unsure, answer YES.

Routing rule:

YES -> take the Python Architect lens. Capture: feasibility of the design as proposed, callouts of cross-cutting impact, and whether the issue should land as
```
status/needs-design
```
instead of
```
status/accepted
```
.
NO -> record
```
Python Architect inactive reason: <one sentence>
```
in working notes; do not take the lens.

当以下任一规则匹配时，激活

python-architect

。

快速路径标签/范围触发。当满足以下任一条件时，立即激活架构审核员视角：
- 问题带有
```
type/architecture
```
  （当前或拟添加）或
```
breaking-change
```
  保留标签。
- 问题正文提议新增顶级CLI命令，或修改
```
apm.yml
```
  、
```
apm.lock.yaml
```
  或
```
apm-policy.yml
```
  的schema。
- 问题正文包含表示跨模块/跨文件工作、新模块、新模式、新契约或新原语设计的关键词——例如“refactor”、“rearchitect”、“new module”、“design”、“abstraction”、“schema change”、“pluggable”、“introduce X pattern”。
Fallback自我检查。如果问题不明确，在激活视角前回答以下问题：

如果按原文接受此问题，在代码安全落地前是否需要做出跨领域的设计决策（接口、数据模型、迁移边界或新原语）？用一句话回答YES或NO。若不确定，回答YES。

路由规则：

YES -> 采用Python Architect视角。记录：提议设计的可行性、跨领域影响标注，以及该问题是否应标记为
```
status/needs-design
```
而非
```
status/accepted
```
。
NO -> 在工作笔记中记录
```
Python Architect inactive reason: <一句话说明>
```
；不采用该视角。

Doc Writer

Activate

doc-writer

if either rule below matches.

Fast-path label / scope trigger. Activate the Documentation Reviewer lens immediately when ANY of:
- The issue is
```
type/docs
```
  or carries
```
area/docs-site
```
  (current or proposed).
- The issue body proposes documentation, README, reference, guide, or migration-note changes.
- The issue is a user-facing feature that will require new doc pages -- e.g. a new CLI flag, a new primitive, a new authoring concept.
Fallback self-check. If the issue is ambiguous, answer this before activating the lens:
Will an implementing PR for this issue need to add or change user-facing documentation in
```
docs/src/content/docs/
```
or in the README? Answer YES or NO with one sentence. If unsure, answer YES.

Routing rule:

YES -> take the Doc Writer lens. Capture: whether docs work is implied (and whether
```
area/docs-site
```
should be added as a secondary
```
area/*
```
so the implementing PR is reminded), and whether the proposed comment wording is clear and grounded in the user vocabulary used in the README and guides.
NO -> record
```
Doc Writer inactive reason: <one sentence>
```
in working notes; do not take the lens.

当以下任一规则匹配时，激活

doc-writer

。

快速路径标签/范围触发。当满足以下任一条件时，立即激活文档审核员视角：
- 问题为
```
type/docs
```
  或带有
```
area/docs-site
```
  （当前或拟添加）标签。
- 问题正文提议修改文档、README、参考资料、指南或迁移说明。
- 问题是用户侧功能，需要新增文档页面——例如新CLI标志、新原语、新创作概念。
Fallback自我检查。如果问题不明确，在激活视角前回答以下问题：
针对此问题的实现PR是否需要在
```
docs/src/content/docs/
```
或README中添加或修改用户侧文档？用一句话回答YES或NO。若不确定，回答YES。

路由规则：

YES -> 采用Doc Writer视角。记录：是否涉及文档工作（以及是否应添加
```
area/docs-site
```
作为次要
```
area/*
```
标签，以提醒实现PR），以及建议的评论措辞是否清晰且符合README和指南中使用的用户词汇。
NO -> 在工作笔记中记录
```
Doc Writer inactive reason: <一句话说明>
```
；不采用该视角。

Triage decision rubric

分类决策标准

The CEO arbiter picks exactly ONE outcome from this rubric:

```
accept
```
-- direction is clear and aligned with the README spine and the roadmap. Assigns full label set + milestone if a current candidate exists.
```
needs-design
```
-- direction is sound but the design must be settled before code lands. Apply
```
status/needs-design
```
and name in the comment exactly what must be designed (interface, data model, migration, security boundary).
```
decline-with-reason
```
-- out of scope for APM as positioned by the README spine. Suggest an alternative tool, a workaround, or the upstream project. Always courteous, always concrete.
```
duplicate-of #N
```
-- propose the canonical issue. The orchestrator must verify the link resolves before posting.
```
defer-later
```
-- accepted in principle but no current milestone. Sits as
```
status/accepted
```
plus
```
theme/* + area/*
```
only; no
```
priority/*
```
, no milestone.
```
auto-handle
```
-- automated noise such as a daily CLI-consistency report PR or scheduled bot issue. Propose closing if the report has zero unaddressed High findings; otherwise propose splitting into individual issues with the right
```
area/*
```
labels and reference back to the parent.

CEO仲裁员需从以下标准中选择恰好一个结果：

```
accept
```
——方向明确，与README核心内容和路线图一致。分配完整标签集+里程碑（如果当前有可用候选）。
```
needs-design
```
——方向可行，但需先确定设计方案才能落地代码。应用
```
status/needs-design
```
标签，并在评论中明确指出必须设计的内容（接口、数据模型、迁移、安全边界）。
```
decline-with-reason
```
——超出APM的范围（根据README核心内容定位）。建议替代工具、解决方法或上游项目。始终保持礼貌且具体。
```
duplicate-of #N
```
——提议关联原始问题。编排器必须在发布前验证链接可访问。
```
defer-later
```
——原则上接受，但暂无对应里程碑。标记为
```
status/accepted
```
加上
```
theme/* + area/*
```
标签；不添加
```
priority/*
```
标签，不设置里程碑。
```
auto-handle
```
——自动化噪音，例如每日CLI一致性报告PR或定时机器人创建的问题。如果报告中没有未处理的高优先级发现，提议关闭；否则提议拆分为带有正确
```
area/*
```
标签的单个问题，并引用父问题。

Label-set construction rules

标签集构建规则

Triage produces a single proposed label set. The taxonomy:

Mega-themes (one of):

theme/portability

theme/security

theme/governance

Sub-themes (

area/*

, one or more):

area/multi-target

area/marketplace

area/package-authoring

area/distribution

area/mcp-config

area/content-security

area/lockfile

area/mcp-trust

area/audit-policy

area/enterprise

area/cli

area/ci-cd

area/testing

area/docs-site

Types (exactly one):

type/bug

type/feature

type/docs

type/refactor

type/architecture

type/automation

type/release

type/performance

Statuses (exactly one):

status/needs-triage

status/accepted

status/needs-design

status/blocked

status/in-flight

Priorities (optional):
```
priority/high
```
,
```
priority/low
```
.

Preserved (apply when relevant):

breaking-change

good first issue

help wanted

experimental

panel-review

dx

agentic-workflows

dependencies

Construction rules:

Exactly one
```
theme/<mega>
```
label is required UNLESS the issue is pure infra (only
```
area/cli
```
,
```
area/ci-cd
```
,
```
area/testing
```
, or
```
area/docs-site
```
apply, with no product surface implication). State this explicitly in the per-lens notes when omitting the theme.
Multi-theme labels are allowed; the primary theme is listed first and drives the milestone.
Exactly one
```
type/*
```
label.
Exactly one
```
status/*
```
label. The default
```
status/needs-triage
```
is always replaced by the triage outcome (
```
status/accepted
```
,
```
status/needs-design
```
,
```
status/blocked
```
, etc.). Do not leave
```
status/needs-triage
```
on a triaged issue.
```
priority/*
```
only on
```
accept
```
with a current milestone or next minor. Never on
```
defer-later
```
,
```
needs-design
```
, or
```
decline-*
```
.

分类会生成一组拟添加的标签。分类体系如下：

核心主题（选其一）：

theme/portability

theme/security

theme/governance

子主题（

area/*

，选一个或多个）：

area/multi-target

area/marketplace

area/package-authoring

area/distribution

area/mcp-config

area/content-security

area/lockfile

area/mcp-trust

area/audit-policy

area/enterprise

area/cli

area/ci-cd

area/testing

area/docs-site

类型（选其一）：

type/bug

type/feature

type/docs

type/refactor

type/architecture

type/automation

type/release

type/performance

状态（选其一）：

status/needs-triage

status/accepted

status/needs-design

status/blocked

status/in-flight

优先级（可选）：
```
priority/high
```
,
```
priority/low
```
.

保留标签（相关时应用）：

breaking-change

good first issue

help wanted

experimental

panel-review

dx

agentic-workflows

dependencies

构建规则：

必须选择一个
```
theme/<核心主题>
```
标签，除非问题是纯基础设施类（仅适用
```
area/cli
```
、
```
area/ci-cd
```
、
```
area/testing
```
或
```
area/docs-site
```
，且不涉及产品层面）。在省略主题标签时，需在各视角的笔记中明确说明。
允许多主题标签；主主题列在首位，并决定里程碑分配。
必须选择一个
```
type/*
```
标签。
必须选择一个
```
status/*
```
标签。默认的
```
status/needs-triage
```
标签始终会被分类结果（
```
status/accepted
```
、
```
status/needs-design
```
、
```
status/blocked
```
等）替换。已分类的问题不能保留
```
status/needs-triage
```
标签。
```
priority/*
```
标签仅适用于已
```
accept
```
且有当前里程碑或下一个次要版本的问题。绝不能用于
```
defer-later
```
、
```
needs-design
```
或
```
decline-*
```
类问题。

Milestone assignment rules

里程碑分配规则

Current patch milestone (e.g.,
```
0.9.x
```
) for bug fixes and small DX work that fits a patch release.
Next minor (e.g.,
```
0.10.0
```
) for
```
type/feature
```
accepted with
```
priority/high
```
.
No milestone (
null
) for
```
defer-later
```
and
```
needs-design
```
.

The orchestrator looks up open milestones with:

gh api repos/microsoft/apm/milestones --jq '.[]|select(.state=="open")|.title'

The lowest-numbered open patch milestone is "current patch"; the lowest-numbered open minor is "next minor". If neither exists, set milestone to

null

and note it.

当前补丁版本里程碑（例如
```
0.9.x
```
）适用于bug修复和适合补丁版本的小型DX工作。
下一个次要版本（例如
```
0.10.0
```
）适用于已
```
accept
```
且标记为
```
priority/high
```
的
```
type/feature
```
类问题。
**无里程碑（
```
null
```
）**适用于
```
defer-later
```
和
```
needs-design
```
类问题。

编排器通过以下命令查询开放的里程碑：

gh api repos/microsoft/apm/milestones --jq '.[]|select(.state=="open")|.title'

编号最小的开放补丁版本里程碑为“当前补丁版本”；编号最小的开放次要版本为“下一个次要版本”。如果两者都不存在，将里程碑设置为

null

并记录说明。

Quality gates

质量检查

A triage comment passes when:

DevX UX Expert: real user surface identified, the request maps (or fails to map) to a concrete README-anchored capability
Supply Chain Security Expert: P/G/S risk surfaces assessed; if the issue touches lockfile, marketplace, MCP config, signing, or auth,
```
theme/security
```
or
```
theme/governance
```
is on the set
APM CEO: theme, milestone, priority, decision, and reply tone ratified
OSS Growth Hacker lens taken or inactive reason recorded; if taken, tone tuned for a new or low-interaction contributor and the reply names a concrete next step they can take
Python Architect lens taken or inactive reason recorded; if taken, feasibility, cross-cutting impact, and any
```
status/needs-design
```
recommendation are captured
Doc Writer lens taken or inactive reason recorded; if taken, docs implication is named and any
```
area/docs-site
```
secondary label is proposed when the implementing PR will need new pages

分类评论需满足以下条件才算通过：

DevX UX Expert：已识别真实用户场景，请求映射（或未映射）到README中明确的功能
Supply Chain Security Expert：已评估P/G/S风险面；如果问题涉及lockfile、市场、MCP配置、签名或认证，标签集中需包含
```
theme/security
```
或
```
theme/governance
```
APM CEO：已批准主题、里程碑、优先级、决策和回复语气
OSS Growth Hacker视角已采用或已记录未激活原因；若已采用，已针对新贡献者或低互动贡献者调整语气，并在回复中指明他们可以采取的具体下一步操作
Python Architect视角已采用或已记录未激活原因；若已采用，已记录可行性、跨领域影响以及任何
```
status/needs-design
```
建议
Doc Writer视角已采用或已记录未激活原因；若已采用，已指明文档影响，并在实现PR需要新增页面时提议添加
```
area/docs-site
```
次要标签

Notes

注意事项

This skill orchestrates a panel in your own context -- you are the only agent. You load each persona's
```
.agent.md
```
reference file on demand (progressive disclosure), assume that persona's lens to produce its findings, then move to the next persona. Do NOT spawn sub-agents (no
```
task
```
tool dispatch) -- the panel is a sequence of reasoning passes inside one agent loop, not a multi-agent fan-out.
Persona detail lives in the linked
```
.agent.md
```
files. Read each one when you switch to that persona; do not pre-load all of them.

本Skill在你的上下文中编排面板——你是唯一的Agent。你会按需加载每个角色的
```
.agent.md
```
参考文件（渐进式披露），扮演该角色的视角生成发现，然后切换到下一个角色。不要生成子Agent（不调度
```
task
```
工具）——面板是单个Agent循环中的一系列推理步骤，而非多Agent扩散。
角色细节存放在链接的
```
.agent.md
```
文件中。切换到该角色时再读取，不要预先加载所有文件。

Execution checklist

执行检查清单

When this skill is activated for an issue, work through these steps in order, in a single agent loop. Do not skip ahead and do not emit any output before the final step.

Read the issue context (title, body, labels, author,
```
author_association
```
, prior comments). The orchestrating workflow already fetches this with
```
gh issue view --json
```
-- do not re-fetch from inside the skill.
Resolve the three conditional cases -- OSS Growth Hacker, Python Architect, Doc Writer -- using the rules in "Conditional panelists" above. For each, record either an activation decision or
```
<Persona> inactive reason: <one sentence>
```
in working notes.
For each mandatory persona (plus any conditional persona that activated), follow the Persona pass procedure below, one persona at a time. Do not try to play multiple personas in a single pass.
Run the pre-arbitration completeness gate:
- Findings exist in working notes for the 2 mandatory specialists (DevX UX Expert, Supply Chain Security Expert).
- For EACH of OSS Growth Hacker, Python Architect, and Doc Writer: exactly one of
```
<Persona> findings
```
  or
```
<Persona> inactive reason
```
  exists (neither = incomplete; both = inconsistent routing).
- No persona section is missing or empty. If any check fails, redo that persona's pass and repeat the gate. Do not proceed to step 5 until the gate passes.
Take the APM CEO lens (load
```
../../agents/apm-ceo.agent.md
```
) and arbitrate the collected findings into a single decision: rubric outcome, primary theme,
```
area/*
```
set,
```
type/*
```
,
```
status/*
```
, optional
```
priority/*
```
, milestone, and reply tone. Still in your own context. CEO arbitration may run only after the completeness gate has passed.
If the rubric outcome is
```
duplicate-of #N
```
, verify the candidate issue exists and is open with
```
gh issue view N --json state,title
```
before committing the link.
Now (and only now) load
```
assets/triage-template.md
```
and fill it in with the collected findings, decision, label set, milestone, and proposed comment body.
Emit the filled template as exactly ONE comment via the workflow's
```
safe-outputs.add-comment
```
channel. For direct (non-workflow) invocation, return the comment text and the structured
```
triage-decision
```
JSON tail so an orchestrator can apply labels and post the comment without parsing prose. This is the ONLY output emission for the entire panel run -- no per-persona comments, no progress comments.

当此Skill针对某个问题激活时，按顺序完成以下步骤，全程在单个Agent循环中进行。不要提前跳过步骤，也不要在最后一步前输出任何内容。

读取问题上下文（标题、正文、标签、作者、
```
author_association
```
、历史评论）。编排工作流已通过
```
gh issue view --json
```
获取这些信息——不要在Skill内部重新获取。
确定三个条件角色的激活状态——OSS Growth Hacker、Python Architect、Doc Writer——使用上文“条件激活角色”中的规则。对于每个角色，在工作笔记中记录激活决策或
```
<角色> inactive reason: <一句话说明>
```
。
针对每个必填角色（以及任何已激活的条件角色），依次遵循角色传递流程。不要尝试在单次步骤中扮演多个角色。
运行仲裁前完整性检查：
- 工作笔记中存在2个必填专家（DevX UX Expert、Supply Chain Security Expert）的发现。
- 对于OSS Growth Hacker、Python Architect和Doc Writer中的每一个：工作笔记中要么存在
```
<角色> findings
```
  ，要么存在
```
<角色> inactive reason
```
  （两者都没有=不完整；两者都有=路由不一致）。
- 没有角色板块缺失或为空。如果任何检查失败，重新执行该角色的步骤并再次检查。直到检查通过后再进入步骤5。
采用APM CEO视角（加载
```
../../agents/apm-ceo.agent.md
```
），将收集到的发现仲裁为单个决策：标准结果、主主题、
```
area/*
```
标签集、
```
type/*
```
、
```
status/*
```
、可选的
```
priority/*
```
、里程碑和回复语气。仍在你的上下文内执行。只有在完整性检查通过后，才能进行CEO仲裁。
如果标准结果为
```
duplicate-of #N
```
，在确认链接前，通过
```
gh issue view N --json state,title
```
验证候选问题存在且处于开放状态。
现在（且仅在此刻）加载
```
assets/triage-template.md
```
，填入收集到的发现、决策、标签集、里程碑和提议的评论正文。
通过工作流的
```
safe-outputs.add-comment
```
通道输出填写完成的模板，作为恰好一条评论。对于直接（非工作流）调用，返回评论文本和结构化的
```
triage-decision
```
JSON尾部，以便编排器无需解析文本即可应用标签、设置里程碑并发布回复。这是整个面板运行的唯一输出——不要输出每个角色的单独评论、进度更新评论或“我将调用X”的状态评论。

Persona pass procedure

角色传递流程

For each persona, run this exact procedure in your own context:

Open the persona's
```
.agent.md
```
file (linked in the roster) and read its scope, lens, anti-patterns, and required return shape.
From that persona's lens, review the issue title, body, labels, author signals, and any prior comments against the scope declared in the file.
Write the findings to working notes under
```
<persona-name>: <findings>
```
(or, for an inactive conditional persona,
```
<Persona> inactive reason: <one sentence>
```
).
Drop the persona lens before moving on. Do not emit any comment from inside a persona pass; persona findings stay in working notes until step 7 synthesizes them.

针对每个角色，在你的上下文内严格执行以下流程：

打开角色的
```
.agent.md
```
文件（阵容中已链接），读取其范围、视角、反模式和要求的返回格式。
从该角色的视角出发，对照文件中声明的范围，审核问题标题、正文、标签、作者信号和任何历史评论。

在工作笔记中写入

<角色名称>: <发现内容>

（对于未激活的条件角色，写入

<角色> inactive reason: <一句话说明>

）。

在切换到下一个角色前，退出当前角色视角。不要在角色传递过程中输出任何评论；角色发现需保留在工作笔记中，直到步骤7进行综合处理。

Output contract

输出约定

This contract is non-negotiable -- it is the difference between a triage that lands as one cohesive comment and one that fragments into per-persona noise.

Produce exactly one comment per triage run.
Use
```
assets/triage-template.md
```
as the comment body. Keep its section headings exactly as written. Adapt the body of each section to the issue. Do not invent new top-level sections or drop existing ones.
The trailing fenced ```json block named
```
triage-decision
```
is REQUIRED. It is the machine-readable contract that downstream automation uses to apply labels, set the milestone, and post the reply without parsing prose.
ASCII only inside the comment body and JSON tail. No emojis, no Unicode dashes, no box-drawing characters. Use
```
[+] [!] [x] [i] [*] [>]
```
if status symbols are needed.
CEO arbitration may run only after the completeness gate passes.
Never emit findings as separate comments, intermediate progress comments, or "I will now invoke X" status comments.
Load
```
assets/triage-template.md
```
at synthesis time only (step 7 above) -- not at activation, not while collecting findings.

此约定不可协商——它是分类评论保持连贯还是分裂为单个角色噪音的关键。

每次分类运行生成恰好一条评论。
使用
```
assets/triage-template.md
```
作为评论正文。严格保留其章节标题。根据问题调整每个章节的内容。不要新增顶级章节或删除现有章节。
末尾名为
```
triage-decision
```
的围栏```json块是必填项。这是机器可读的约定，下游自动化将使用它来应用标签、设置里程碑并发布回复，无需解析文本。
评论正文和JSON尾部仅使用ASCII字符。不要使用表情符号、Unicode破折号或方框绘制字符。如果需要状态符号，使用
```
[+] [!] [x] [i] [*] [>]
```
。
只有在完整性检查通过后，才能进行CEO仲裁。
绝不要将发现作为单独评论、中间进度评论或“我将调用X”的状态评论输出。
仅在综合阶段（上文步骤7）加载
```
assets/triage-template.md
```
——不要在激活时或收集发现时加载。

Anti-patterns

反模式

Over-labelling. Do not exceed 6 labels per issue across
```
theme/* + area/* + type/* + status/* + priority/* + preserved/*
```
. If you find yourself reaching for 7+, prune the weakest
```
area/*
```
.
Milestone without status. Never assign a milestone to an issue whose status is not
```
status/accepted
```
or
```
status/in-flight
```
.
```
needs-design
```
and
```
defer-later
```
are explicitly milestone-free.
Silent decline. Do not auto-close or
```
decline-with-reason
```
without a courteous reason linked to the README spine, the manifesto, or the public roadmap. Every decline names where the user can go instead.
Vague needs-design. Never apply
```
status/needs-design
```
without naming, in the suggested comment, exactly what must be designed (interface, data model, migration, security boundary). "We need to think about this" is not a design-needed reason.
Naked
status/needs-triage
carryover. Triage replaces the default
```
status/needs-triage
```
label. Leaving it on a triaged issue is a routing bug.
Wildcard heuristics. Do not activate the OSS Growth Hacker on
```
*new*
```
or
```
*first*
```
keyword matches alone -- always cross-check
```
author_association
```
and prior interactions on
```
microsoft/apm
```
. Same discipline for Python Architect (do not fire on the bare word "refactor" in unrelated context -- check the issue's actual scope) and Doc Writer (do not fire purely on the word "docs" appearing in passing -- the issue must propose or imply a doc-surface change).

过度打标签。
```
theme/* + area/* + type/* + status/* + priority/* + preserved/*
```
标签总数不要超过6个。如果需要第7个，移除最弱的
```
area/*
```
标签。
无状态的里程碑。绝不为状态不是
```
status/accepted
```
或
```
status/in-flight
```
的问题分配里程碑。
```
needs-design
```
和
```
defer-later
```
类问题明确不设置里程碑。
静默拒绝。不要在没有给出礼貌原因的情况下自动关闭或标记
```
decline-with-reason
```
，原因需关联README核心内容、宣言或公开路线图。每次拒绝都要指明用户可以转向的替代方案。
模糊的needs-design。应用
```
status/needs-design
```
标签时，必须在建议评论中明确指出必须设计的内容（接口、数据模型、迁移、安全边界）。“我们需要考虑这个”不是需要设计的合理理由。
保留status/needs-triage标签。分类会替换默认的
```
status/needs-triage
```
标签。已分类的问题保留该标签属于路由错误。
通配符启发式。不要仅根据
```
*new*
```
或
```
*first*
```
关键词匹配就激活OSS Growth Hacker——始终交叉验证
```
author_association
```
和作者在
```
microsoft/apm
```
中的历史交互。Python Architect（不要仅在无关上下文中出现“refactor”就触发——检查问题的实际范围）和Doc Writer（不要仅因偶然出现“docs”就触发——问题必须提议或涉及文档层面的变更）也需遵循相同原则。

Gotchas

注意要点

Roster invariant. The frontmatter description, the roster table, the conditional-panelist rule, the triage template, and the quality gates MUST agree on the persona set. If you change one, change all of them in the same edit.
No new persona required. This skill deliberately reuses
```
devx-ux-expert
```
,
```
supply-chain-security-expert
```
,
```
apm-ceo
```
,
```
oss-growth-hacker
```
,
```
python-architect
```
, and
```
doc-writer
```
. Do not create a
```
triage-*
```
persona; the README spine plus the label taxonomy plus the existing CEO arbiter are sufficient grounding.
Bundle layout on the runner. When this skill runs inside an agentic workflow, the APM bundle is unpacked under
```
.github/skills/apm-triage-panel/
```
first, with
```
.apm/skills/...
```
as a fallback. The asset path is the same relative to the skill root (
```
assets/triage-template.md
```
) in both layouts -- prefer the
```
.github/...
```
path when present.
No multi-persona-in-one-pass. Each persona has its own
```
.agent.md
```
for a reason -- read it when you take that lens, write the findings, then drop the lens before moving on.
Single-emission discipline is fragile under interruption. If you find yourself wanting to "post a quick partial decision and then update it", don't. Buffer in working notes; emit once.

阵容不变性。前置描述、阵容表格、条件角色规则、分类模板和质量检查必须在角色集上保持一致。如果修改其中一项，需在同一编辑中修改所有相关项。
无需新增角色。本Skill刻意复用
```
devx-ux-expert
```
、
```
supply-chain-security-expert
```
、
```
apm-ceo
```
、
```
oss-growth-hacker
```
、
```
python-architect
```
和
```
doc-writer
```
。不要创建
```
triage-*
```
角色——README核心内容、标签分类体系和现有的CEO仲裁员已足够提供基础支撑。
运行器上的包布局。当此Skill在Agent工作流中运行时，APM包会先解压到
```
.github/skills/apm-triage-panel/
```
下，
```
.apm/skills/...
```
作为 fallback。在两种布局中，资产路径相对于Skill根目录都是相同的（
```
assets/triage-template.md
```
）——优先使用
```
.github/...
```
路径（如果存在）。
不要单次扮演多个角色。每个角色都有自己的
```
.agent.md
```
文件——采用该视角时再读取，写入发现后退出视角，再切换到下一个角色。
单次输出规则在中断时易受影响。如果你想“先发布一个快速的部分决策，然后再更新”，不要这样做。在工作笔记中缓冲内容；仅输出一次。