# Ticket Priority Triage Procedure

## Purpose

Provide a context-efficient way to respond when the user asks to work on "the highest priority ticket" or otherwise gives an open-ended request to move work forward.

## Core Principle

Do not dump every active ticket into the main context. Use a ticket-triage subagent or a small summary script, then read only the selected ticket and its current artifact.

## Procedure

### 1. Preflight

- Run `git status --short`.
- If unrelated dirty work exists, do not start new implementation in-place. Planning/triage is okay; implementation should wait for triage, branch/worktree isolation, or explicit approval.

### 2. Use ticket triager

Invoke `nimrod-ticket-triager` to summarize active tickets by priority/status/blockers.

The triager should return only:

- top recommendation
- next 1–3 candidates
- blockers/waiting items
- backlog/not-truly-active candidates
- risks/process issues

### 3. Interpret "highest priority"

If the user intentionally leaves the request open-ended, choose a reasonable next action using these priority drivers:

1. safety/security/secrets/access risk
2. live infrastructure or data-loss risk
3. blocks many other tasks
4. dirty repo/agent coordination risk
5. user-stated current focus
6. quick high-leverage unblock

If two options are close, state the assumption and proceed with planning rather than asking excessive questions.

### 4. Load narrow context

After choosing the ticket:

- read the ticket file;
- read only the current relevant artifact, e.g. `05-plan.md` or recovery notes;
- read runbooks/status files only if directly needed;
- avoid loading historical logs unless verifying a claim.

### 5. Choose action mode

Classify the next step:

- planning/spec only
- recovery/triage
- software implementation
- infrastructure mutation
- documentation cleanup

Apply the matching workflow:

- software QRSPI for code/app work;
- DevOps QRSPI for infrastructure mutation;
- context-hygiene recovery for terminated/dirty work;
- questionnaire for multiple closed/user-decision questions.

### 6. Safety gates

For secrets/Vaultwarden/security-sensitive work, do not proceed to real secret migration until these are verified or deliberately accepted as blockers:

- base OS install complete;
- auditable admin SSH path exists;
- TLS/HTTPS approach is satisfactory;
- backup plan exists;
- recovery/restore plan exists;
- break-glass material location is documented outside Vaultwarden;
- restore test is planned before critical dependence.

If the user chooses to defer one of these, record it as a blocker/risk, not as normal completion.

## Output Pattern

```markdown
I found <N> plausible priority candidates. I recommend starting with `<ticket>` because <reason>.

Current dirty-tree note: <clean/dirty/isolation needed>.

Next safe action: <one concrete next step>.

I will read only <ticket/artifact paths> next unless you redirect me.
```