Triage Public

---
name: triage-public
description: Triages public issue tracker items — classify, reproduce, ask reporters for information, decide scope, publish agent briefs — then promotes accepted work inward to the private execution engine. Inward only. Use when reviewing incoming public issues or promoting one into private execution.
---

# Triage Public

Operate a project's public collaboration layer. The public tracker is declared in `.brain/project.yaml`
(`public-tracker:`); execution itself is planned and tracked privately through `manage-work-graph`.
This skill is tracker-agnostic — it owns the triage workflow. The tracker's CLI mechanics and label
vocabulary live in the tracker reference ([references/github.md](references/github.md) for GitHub).

The private execution engine is the source of truth for all work. The public tracker holds issues
raised by reporters or intentionally opened for contributor collaboration. When one is accepted,
record it in the private engine as a work item that references the public origin. This flow is
inward only: private designs, epics, and beads never generate public tracking issues.

Every comment posted to a public issue during intake must start with:

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

## Context files

Read at session start, before doing anything else:

1. **`.brain/project.yaml`** — selects the public tracker (`public-tracker:`).
   - `none` — nothing to intake; all work lives in the private engine. Tell the user and stop.
   - `gh` — operate GitHub Issues; load [references/github.md](references/github.md) for CLI
     mechanics and labels. Infer the repo from the adopter remote; use `public-tracker-id` only
     when it is explicitly set.
2. **`.brain/AGENTS.md`** (Project section) — project tracker conventions shared with
   `manage-work-graph`: linking rules, ADR policy, priority deviations. Absent or empty means pure defaults.

## Triage roles

Every triaged issue carries exactly one **category** and one **state**:

- Category: `bug`, `enhancement`
- State: `needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`

These are the public layer's vocabulary, realized as the tracker's native mechanism (GitHub labels;
see [references/github.md](references/github.md)). Private work uses the engine's native fields
instead: when promoting inward, `manage-work-graph` translates a role to the right field (type,
status, close reason) rather than copying it as a label. A project records any mapping deviations
in `.brain/docs/labels.md` (owned by `manage-work-graph`).

## Public boundary

Use the public tracker when the issue itself is a collaboration artifact: external intake,
reporter follow-up, maintainer/contributor discussion, or work intentionally offered to public
contributors. Use a PR to surface code review without manufacturing an issue. Planning,
dependencies, readiness, ownership, and status stay exclusively in the private execution engine.

## Show what needs attention

Query the tracker and present, in order: unlabeled issues, `needs-triage`, then `needs-info` with
reporter activity since the last intake note. Show counts and a one-line summary per issue; let the
maintainer pick.

## Intake a specific issue

### 1. Gather context

Read the issue body, comments, labels, reporter, and dates. Parse previous intake notes. Explore the
codebase with the project vocabulary and ADRs. Check `.out-of-scope/` for similar rejected
enhancements.

Completion: the issue's history, the code it touches, and any prior rejection of the same idea are
each accounted for — or explicitly noted as absent.

### 2. Reproduce the bug

For a bug, attempt reproduction before recommending anything. Grilling an issue nobody has tried to
reproduce spends the reporter's patience on a question the codebase may already answer.

Completion: the attempt is reported as confirmed repro, failed repro, or missing information, with
the steps run.

### 3. Grill if needed

Use `grill-decisions` when the issue needs design or terminology clarification.

Completion: every ambiguity blocking a category or state call is resolved or named as a question for
the reporter.

### 4. Recommend

Recommend category and state with reasoning. Wait for maintainer direction before any public write.

Completion: one category and one state are proposed with their evidence, and the maintainer has
answered. No public mutation has happened yet.

### 5. Apply the outcome

- `ready-for-agent`: post an agent brief (see [agent brief](references/agent-brief.md));
  promote to a private work item via `manage-work-graph`.
- `ready-for-human`: post a brief-style summary and explain why it needs human work.
- `needs-info`: ask specific reporter questions; summarize what is already established.
- `wontfix` bug: explain and close.
- `wontfix` enhancement: write/update `.out-of-scope/` (see
  [out-of-scope guide](references/out-of-scope.md)), link it from the issue, close.
- `needs-triage`: apply the state, with a comment only if useful.

Completion: the issue carries exactly one category and one state, every public comment opens with
the AI-generated marker, and any promoted work item references the public origin.

## Quick override

If the maintainer says to move an issue to a state, trust them. Confirm public mutations, apply the
roles, and ask only whether they want an agent brief or private work item created. This applies to
an issue already on the public tracker; it never authorizes projecting unrelated private work there.

## Needs-info template

```markdown
## Triage Notes

**What we've established so far:**
- point 1

**What we still need from you (@reporter):**
- question 1
```

Do not ask vague questions like "please provide more info."