apm-triage-panel

# APM Triage Panel -- Single-Issue Triage Orchestration

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.

## Agent roster

| Agent | Persona | Always active? |
|-------|---------|----------------|
| [DevX UX Expert](../../agents/devx-ux-expert.agent.md) | User-Need Reviewer | Yes |
| [Supply Chain Security Expert](../../agents/supply-chain-security-expert.agent.md) | Risk-Surface Reviewer | Yes |
| [APM CEO](../../agents/apm-ceo.agent.md) | Triage Arbiter | Yes (always arbitrates) |
| [OSS Growth Hacker](../../agents/oss-growth-hacker.agent.md) | Contributor-Tone Reviewer | Conditional (see below) |
| [Python Architect](../../agents/python-architect.agent.md) | Architecture Reviewer | Conditional (see below) |
| [Doc Writer](../../agents/doc-writer.agent.md) | 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.

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

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

Activate `oss-growth-hacker` if either rule below matches.

1. **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.

2. **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.

### Python Architect

Activate `python-architect` if either rule below matches.

1. **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".

2. **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.

### Doc Writer

Activate `doc-writer` if either rule below matches.

1. **Fast-path label / scope trigger.** Activate the Documentation
   Reviewer lens immediately when ANY of:
   - The is