triage

Files (1)

• SKILL.md

SKILL.md (first lines)

Turn an untriaged item into one an agent can take, or one that
honestly needs a person.

Read [../ISSUE-TRACKER.md](../ISSUE-TRACKER.md) first.

## How this differs from upstream

Upstream triage is a maintainer evaluating inbound reports, with five
states. Here **agents triage everything** and surface only what needs
a human, so:

- `needs-triage` is gone — untriaged is the absence of a label, and
  needs no state of its own.
- `needs-info` is gone — there is no external reporter to wait on.
- `needs-input` is new and means something different: an agent *has
  started* and stopped to ask.
- `needs-review` is new: an agent finished green and a branch waits.

Every comment posted during triage starts with:

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

## Find what is untriaged

```bash
task issue list          # everything
task runner surface      # what is already blocking a human
```

Untriaged means carrying none of the four labels.

## Triage one issue

### 1. Gather context

Read the issue. Then run two checks against the codebase:

- **Redundancy** — search by *domain concept*, not by the request's
  wording, for an existing implementation. Report where you looked.
  If it exists, say where and close it.
- **Prior rejection** — read `.out-of-scope/*.md` and surface anything
  resembling this request.

Reading real source needs a runner with a `repo:` capability. A
records-only runner cannot answer the redundancy question and must not
pretend to.

### 2. Decide who does it

- **`ready-for-agent`** — fully specified, and the work is the kind an
  agent can finish and prove.
- **`ready-for-human`** — judgement, taste, external access, physical
  hardware, or a decision that is not yours to make.

When unsure, ask rather than guess: a mislabelled `ready-for-agent`
burns a runner and leaves a half-branch.

### 3. Give it a verdict

An issue cannot be `ready-for-agent` without a resolvable verify
command. If the project's default does not fit, set `--verify`.
Refusing to label it is correct — do not invent a command that passes
trivially just to get the label on.

### 4. Decide which machine

`--cap build` for anything that compiles. `--cap repo:<owner>/<name>`
when it needs a clone. `--model` when a ticket wants a different model
from the runner's default — a mechanical rename and a subtle
concurrency fix do not need the same one.

### 5. Write the brief

The body is the contract. The original discussion is context.

- **Do** describe interfaces, types, and behavioural contracts.
- **Do** name types and function signatures to look for.
- **Don't** reference file paths or line numbers — they go stale while
  the ticket waits.
- **Don't** assume today's structure survives.

Acceptance criteria must be concrete and independently checkable.
State what is out of scope, so an agent does not gold-plate.

### 6. Apply it

```bash
task issue set-workflow <id> --verify "<cmd>"   # if overriding
task task tag <id> ready-for-agent               # or ready-for-human
```

## Grilling

If the request needs shaping before any of that, run `/grilling` and
`/domain-modeling` together — a round of questions at a time,
sharpening domain terms as decisions land. Do not triage a request you
do not yet understand into `ready-for-agent`; that is how an agent ends
up building the wrong thing confidently.

From FastTrackStudios/task, Apache-2.0.

More from FastTrackStudios/task