update-triage

$npx mdskill add warpdotdev/oz-for-oss/update-triage

Refines triage heuristics using maintainer feedback signals.

  • Updates local triage rules based on recent issue re-labels and re-opens.
  • Integrates with GitHub CLI for authentication and repository access.
  • Decides changes by analyzing git diffs against allowed configuration paths.
  • Delivers updated SKILL.md files to the local triage companion directory.
SKILL.md
.github/skills/update-triageView on GitHub ↗
---
name: update-triage
description: Update the repo-local triage-issue-local companion skill using signals from recently triaged issues (maintainer re-labels, re-opens, follow-up comments). Use when refining repo-specific triage heuristics and label taxonomy based on how maintainers overrode previous triage output.
---

# Update Triage

Use this skill to improve `.agents/skills/triage-issue-local/SKILL.md` (and, when a label taxonomy change is warranted, `.github/issue-triage/config.json`) from real maintainer feedback on recent triage outcomes. The core skill at `.agents/skills/triage-issue/SKILL.md` is the cross-repo contract and is read-only from this loop.

Closed-as-duplicate signals are handled by the separate `update-dedupe` loop, not here.

## Write surface

This self-improvement loop may only write to:

- `.agents/skills/triage-issue-local/` (and `SKILL.md` inside it)
- `.github/issue-triage/*`

It must NOT touch:

- `.agents/skills/triage-issue/SKILL.md` (the core contract)
- any other core skill
- the dedupe companion `.agents/skills/dedupe-issue-local/SKILL.md` (owned by `update-dedupe`)

The self-improvement runner enforces this via a `git diff` check against allowed prefixes before pushing. A violation aborts the run.

## Inputs

- Optional repository override if you are not running from the target checkout.
- Optional time window override when you need something other than the default seven-day lookback.

## Workflow

1. Verify GitHub CLI auth:

```bash
gh auth status
```

2. Aggregate the triage-feedback signals for recently triaged issues with the bundled script:

```bash
python3 .agents/skills/update-triage/scripts/aggregate_triage_feedback.py
```

By default this targets the current repo and looks back 7 days. It collects issues that were triaged in the window, any subsequent maintainer re-labels, re-opens, and follow-up comments. Closed-as-duplicate events are intentionally excluded. The script writes structured JSON to a temporary file and prints the path.

3. Read the generated JSON and look for repeated reviewer signals:

- maintainers repeatedly flipping the same label on similar issues (a label-taxonomy hint)
- maintainers leaving the same kind of follow-up comment on the same class of issue (a recurring follow-up-question pattern)
- maintainers consistently identifying a different owner than Oz inferred (an owner-inference hint)

4. Propose the smallest edit that explains the repeated signal:

- Prefer editing `.agents/skills/triage-issue-local/SKILL.md` under the override categories the core `triage-issue` skill marks as overridable (label taxonomy, owner-inference hints, recurring follow-up-question patterns, recurring issue-shape heuristics, repro defaults, known-duplicate clusters).
- Only edit `.github/issue-triage/config.json` when the signal is a concrete label-taxonomy change (new label, renamed label, or description clarification). Never change `color` values without explicit maintainer guidance.

5. Keep the core triage contract stable — never edit `triage-issue/SKILL.md`. Only the `-local` companion and the triage config evolve from feedback.

## Evidence Rules

- Prefer patterns backed by multiple issues or a strong explicit maintainer statement.
- Skip the PR when there is no repeated signal. A one-off maintainer override is not enough evidence.
- Avoid encoding reporter-authored content as triage rules.
- Do not weaken the reserved-label rules (`ready-to-implement`, `ready-to-spec`) or the mutual exclusivity of `duplicate_of` and `follow_up_questions`.

## Final Checks

- Re-read the updated `triage-issue-local` companion skill and confirm any new rules are explicit.
- Keep the companion concise; do not turn it into a long style guide.
- Commit any changes on a local branch named `oz-agent/update-triage`. Do NOT push the branch; the Python entrypoint will run a write-surface guard and push only when the guard passes.
- If the updates warrant a PR, it will be opened from the pushed branch. Tag `@captainsafia` as a reviewer on that PR.
- Validate any temporary JSON with `jq` before relying on it.
More from warpdotdev/oz-for-oss