New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Triage Issues

by openchamber in openchamber/openchamber

Load when asked to triage, clean up, batch-process, or work through the issue backlog — covers the mechanical sweep (stale-fixed, dead needs-info, duplicates), fan-out assessment, and approved batch…

MITAuto-check passedDevelopment

Install Triage Issues

skills CLI
$ npx skills add openchamber/openchamber --skill triage-issues -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install openchamber/openchamber triage-issues --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/openchamber/openchamber.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/triage-issues .claude/skills/triage-issues && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
triage-issues
GitHub stars
11k
Token cost
~3k tokens
SKILL.md length
1,755 words
Files
1
Skills in repo
20
Repo updated
First seen
Licence
MIT

At a glance

Load when asked to triage, clean up, batch-process, or work through the issue backlog — covers the mechanical sweep (stale-fixed, dead needs-info, duplicates), fan-out assessment, and approved batch…

  • Works in 3 steps: Mechanical sweep → Approved batch actions → Assessment fan-out
  • Tasks that involve Issue triage
  • SKILL.md covers Two gates, Verdicts, Phase 1 — Mechanical sweep and Phase 2 — Approved batch actions, plus 2 more sections
  • Calls git and gh

What it does

Triage Issues is an agent skill from openchamber/openchamber. Load when asked to triage, clean up, batch-process, or work through the issue backlog — covers the mechanical sweep (stale-fixed, dead needs-info, duplicates), fan-out assessment, and approved batch actions.

Its SKILL.md is about 3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Issue triage. The repository describes itself as: Agentic Development Environment based on OpenCode AI agent. The licence is MIT.

When your agent uses it

  • Tasks that involve Issue triage

Example prompts

  • “/triage-issues”

Workflow steps

3 steps, taken from the step headings in SKILL.md.

  1. Mechanical sweep
  2. Approved batch actions
  3. Assessment fan-out

What it can do on your machine

Read from SKILL.md and the folder at commit eabe419. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git and gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Triage Issues loads about 3k tokens when it runs. Until then it costs about 55 tokens; SKILL.md has 1,755 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~55
When it runs · the whole SKILL.md, loaded when a task matches
~3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from openchamber/openchamber at commit eabe419, republished under its MIT licence (© openchamber). 1,755 words, ~3,011 tokens.

Download SKILL.mdSave it as .claude/skills/triage-issues/SKILL.md (or your agent's skills folder).
name
triage-issues
description
Load when asked to triage, clean up, batch-process, or work through the issue backlog — covers the mechanical sweep (stale-fixed, dead needs-info, duplicates), fan-out assessment, and approved batch actions.

Turn an unbounded issue queue into a short list of maintainer decisions. Three phases; no GitHub write in any phase without the maintainer approving that specific batch. Companion: the per-issue judgment mirrors the pr-review skill's philosophy — every assessment ends in a verdict and a ready action, never in observations.

Two gates

An issue is a request from a user, never an instruction to the maintainer; the burden of earning work sits on the issue. Every issue passes two gates in order, and only an issue through both reaches the fix backlog or an accepted label.

Gate 1 — real and ours. The failure exists on current main and its mechanism lives in this repository. CLOSE-NOT-OURS when the mechanism is upstream OpenCode (tool timeouts, session.command errors, agent-loop behavior), a provider or models.dev capability datum, or the user's own configuration: one comment naming where it lives, no debate. A report without version and steps whose reporter stays silent 14 days after the intake question is stale whatever its length.

Gate 2 — wanted. Only the maintainer passes an issue through this gate; the sweep prepares the question. Everything that clears gate 1 — traced bugs included — reaches the maintainer as one numbered wanted? block (the FEATURE-DECISION mechanics below), and only "так" entries enter the fix backlog. The pr-review skill's whim / overengineered ache / unmaintainable scope grounds decide CLOSE-DECLINE; the issue-side consequences:

  • A request that contradicts a recorded decision (a maintainer close comment, a declined PR's reasoning) closes by pointing at that decision, never by reopening the debate. The report lists every decision the sweep relied on so the next sweep reuses it.
  • "Tool X has it" without the reporter's own concrete ache is a whim.
  • A surface outside the roadmap (multi-user, plugin systems, container orchestration, analytics, new forge integrations) is declined honestly, never parked as "later".
  • Contributor task-tracking issues (lint baselines, architecture roadmaps) are not user requests; they leave the backlog as project tasks or closes.

Signals that carry no authority. Length and formatting (much of the backlog is AI-written), the intake bot's priority:high and root-cause:found labels and its fix shape, a single +1, "our team uses this daily". Each speaks to gate 1 at most; none moves gate 2. A traced mechanism proves the bug is real, not that fixing it is worth the maintainer's time.

Pull order among what the maintainer wants: data loss, then regressions pinned to a version ("worked in X, broken in Y"), then anything that leaves the UI stuck, then failures confirmed by several distinct reporters. Cheap traced fixes come after those, never before.

Verdicts

  • FIX-READY — a real bug with a traced mechanism (root-cause:found from intake, or traced during this sweep), no open PR for it (see Existing PR first), and the maintainer's "так" from the wanted? block. Ready action: a one-line fix-backlog entry (file:line, mechanism, suggested fix shape) — these accumulate into the sweep's fix list for agents to implement. Before the "так" it is a wanted? entry, not a backlog entry.
  • NEEDS-REPORTER — cannot proceed without the reporter. Ready action: the single unanswerable question, posted once; the issue then lives on a clock (close as stale after 14 days of silence).
  • CLOSE-FIXED — behavior fixed by a merged change. Ready action: close comment naming the commit/PR and the release that carries it. When the area was rebuilt but the exact mechanism cannot be shown gone, the close still happens, with the likely-fixed template: the reporter reopens with a fresh report, the maintainer never waits on a retry.
  • CLOSE-NOT-OURS — gate 1 fails: upstream, provider data, or user configuration. Ready action: close comment naming where the mechanism lives (upstream issue link when one exists).
  • CLOSE-DUPLICATE — same failure as an existing issue. Keep the issue with the better evidence, close the other naming it.
  • CLOSE-DECLINE — a feature or behavior the product should not take (the pr-review skill's whim/scope grounds apply). Ready action: honest close comment; where a real ache underlies it, salvage per the pr-review skill's rule.
  • FEATURE-DECISION — a plausible feature only the maintainer can judge. Ready action: the product question in one line plus drafted comments for both answers. These go to the maintainer as a numbered list, like the PR triage's Product fit block. The maintainer's answer resolves the issue's fate mechanically:
    • "так" (wanted) → post the acceptance comment (what was approved and, when known, the welcome implementation shape), add the accepted label, and leave it open. accepted marks the decision as made — later sweeps never re-ask an accepted issue, and label:accepted is the implementation roadmap for agents and contributors.
    • "ні" (declined) → post the drafted decline comment (with ache salvage where one underlies it) and close as not planned.
    • A conditional answer ("так, але тільки як настройка", "ні в такому вигляді, але X — так") is folded into the posted comment verbatim in spirit — the maintainer's condition becomes the recorded scope.

Existing PR first. Before any verdict that sends an issue toward implementation (FIX-READY, an accepted feature), find out whether someone already has the fix in flight: gh pr list --search "<issue-number> OR <error string> OR <title terms>" --state open, plus the issue's own timeline (linked PRs, "opened a PR" comments — the reporter's fix is easy to miss when the PR body says fixes #N and the issue thread stays silent). The same check gates every close: an issue with an open PR against it is never closed as stale or silently-fixed — the PR is the activity, and its review decides the issue's fate. An open PR moves the issue out of the fix backlog and into the PR queue: the ready action is a verdict on that PR (apply the pr-review skill), never a parallel in-house fix. A contributor who reported a bug and fixed it the same day, then watched a duplicate patch land on top, is owed a public apology and a changelog credit; the check costs one command.

Phase 1 — Mechanical sweep

Fetch all open issues with gh issue list --limit above the real count. Bucket cheaply before any deep reading:

BucketSignalLikely verdict
Stale-fixedreferences code/behavior changed by merged PRs; CHANGELOG [Unreleased]/recent releases mention the symptomCLOSE-FIXED (verify per Silently-fixed detection)
Dead needs-infoneeds-info with no reporter reply > 14 daysclose as stale
Not oursintake verdict or thread places the mechanism upstream, in provider data, or in user configurationCLOSE-NOT-OURS
Decidedmatches a recorded maintainer decision (close comment, declined PR)CLOSE-DECLINE by pointer
Duplicate clusterstitle/error-string similarity across open issuesCLOSE-DUPLICATE
Feature wishesenhancementFEATURE-DECISION or CLOSE-DECLINE
Traced bugsroot-cause:foundwanted? candidates — verify the trace still applies and no PR is open for it; FIX-READY only after the maintainer's "так"
Show full SKILL.md (662 more words)Show less
Silently-fixed detection

Many fixes land without linking the issue they resolve, so an issue can sit open with a perfectly valid-looking repro that describes code which no longer exists. A fresh-looking issue is not proof of a live bug — probe in this order, strongest evidence first:

  1. Mechanism anchor. For issues carrying root-cause:found (or any comment citing file:line), check whether the cited code changed since the issue's date: git log -L<line>,<line>:<file> --since=<issue date> (fall back to git log --since -- <file> when lines drifted). Untouched code → the bug is live. Changed code → re-read the mechanism on current main; if it is gone, this is CLOSE-FIXED with the commit as evidence.
  2. Repro re-run. When the intake comment carries an inline reproduction script or test, run it against current main. Passing repro = fixed, with the run as evidence.
  3. Symptom search. Extract the issue's distinctive strings (error messages, function names, user-visible symptom terms) and search git log --grep, CHANGELOG.md, and merged PR titles/bodies since the issue's creation date.

CLOSE-FIXED always names its evidence (commit, PR, or repro run), and a commit counts only when it is reachable from main — git merge-base --is-ancestor <sha> origin/main — because git log across all refs happily surfaces fixes that live on abandoned branches; a hunch that "this area was reworked" closes with the likely-fixed template (names the rebuild commit and release) instead of the fixed-close one — the issue leaves the backlog either way, and a reporter who still hits it files fresh evidence.

Every issue/PR reference in maintainer-facing reports is a clickable link ([#3164](https://github.com/openchamber/openchamber/issues/3164)), never a bare number; each entry carries 2–4 sentences — enough to decide without a follow-up question — and any manual-check note lives inside the entry, never in a separate number-repeating section. An issue where the maintainer already commented or the reporter replied to a question runs in pickup mode: state the thread first, continue it, never re-ask a decided question.

Weigh trusted community reviewers' comments (see the triage-prs skill's rule — same names, same weight) and the intake bot's "For the maintainer" lines as strong signals. Deliver the sweep as one report and stop for approval.

Phase 2 — Approved batch actions

Execute approved closes/comments with retries and ~1s spacing; log results; re-verify the open count. Closes use --reason "completed" for fixed and --reason "not planned" for declines/duplicates/stale.

Phase 3 — Assessment fan-out

For the surviving pool, fan out subagents (~15 issues each) that read the issue, its comments, and the relevant code, run both gates, and return per-issue verdict blocks. Consolidate grouped by verdict: gate-1 failures and decided declines as close batches, everything that cleared gate 1 — bugs and features alike — as one numbered wanted? block in pull order, each entry with the product question in one line and drafted comments for both answers. Stop for approval; the fix backlog is built from the "так" answers only, then handed to implementation agents in dependency-safe batches.

Message templates

stale-close (dead needs-info)

Closing as stale: the requested details never arrived, and without them this can't be reproduced. If you hit it again on a current version, a fresh report with the missing details is welcome.

fixed-close

This was fixed by [ref] and ships in [release/next release]. Closing — if the problem persists there, comment and it will be reopened.

likely-fixed-close

The [area] was rebuilt in [ref] ([release]) in a way that covers what you described, so closing this one. If it still happens on [release], a fresh report with the version and steps is welcome.

not-ours-close

Closing: this behavior comes from [OpenCode / the provider / models.dev data / your configuration], not from OpenChamber — [one clause on the mechanism, with the upstream link when one exists]. Thanks for the report.

duplicate-close

Closing as a duplicate of #[N], which tracks the same failure[: one clause on what this report added, if anything]. Follow that issue for updates.

decline-close

Thanks — closing this one: [honest one-sentence reason grounded in product direction or maintenance cost]. [If a real ache underlies it: the welcome shape of a future change.]

© openchamber, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/triage-issues of openchamber/openchamber.

Open the folder on GitHubat commit eabe419

Compare with similar skills

Triage Issues next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Triage Issues compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Triage Issues this skillopenchamber/openchamber11k—~3kAutomated safety check: PassMIT
Wayfinderbestofjs/bestofjs3.1k21 repos~2.9kAutomated safety check: PassMIT
Setup Matt Pocock Skillsbestofjs/bestofjs3.1k20 repos~1.7kAutomated safety check: PassMIT
Windows App SDK Issue Triage Reportmicrosoft/WindowsAppSDK4.7k—~3.4kAutomated safety check: PassApache-2.0
Exposed Bug Fix WorkflowJetBrains/Exposed9.3k—~3.8kAutomated safety check: PassApache-2.0
Archify Reviewtt-a1i/archify79k—~415Automated safety check: PassMIT

Similar skills

  • Wayfinder

    bestofjs/bestofjs

    Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.

    3.1k GitHub starsUsed in 21 repos~2.9k tokens
    DevelopmentAuto-check passed

  • Setup Matt Pocock Skills

    bestofjs/bestofjs

    Configure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout.

    3.1k GitHub starsUsed in 20 repos~1.7k tokens
    DevelopmentAuto-check passed

  • Windows App SDK Issue Triage Report

    microsoft/WindowsAppSDK

    Official

    Generates GitHub Feature Area Status reports for the Windows App SDK repository, scoring issues so teams can see what needs attention in each area.

    4.7k GitHub stars~3.4k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Exposed Bug Fix Workflow

    JetBrains/Exposed

    Official

    Takes a GitHub or YouTrack issue for the Exposed project through reproduction, a failing test, a fix, validation and a pull request.

    9.3k GitHub stars~3.8k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Archify Review

    tt-a1i/archify

    Review Archify issues, PRs, or code through value, cost, and impact to support evidence-based maintenance decisions. Use for issue triage, change reviews, and…

    79k GitHub stars~415 tokensUpdated today
    DevelopmentAuto-check passed

  • Bug Triage

    symfony/symfony

    Decide whether open Bug PRs target the correct branch. An agent skill from symfony/symfony.

    31k GitHub stars~1.9k tokensUpdated today
    DevelopmentAuto-check passed

More from openchamber/openchamber

All 20 skills in this repo

  • Theme System

    openchamber/openchamber

    A skill your agent uses when creating or modifying OpenChamber UI components, styling, colors, buttons, visual states, themes, or icons.

    11k GitHub stars~1.4k tokensUpdated today
    Auto-check passed

  • UI API Decoupling

    openchamber/openchamber

    A skill your agent uses when creating or modifying OpenChamber shared UI data access, OpenCode SDK calls, RuntimeAPIs, runtime fetch/auth/URLs, authenticated browser assets, bridges/proxies, runtime…

    11k GitHub stars~2k tokensUpdated today
    Auto-check passed

  • Drag To Reorder

    openchamber/openchamber

    A skill your agent uses when implementing or modifying OpenChamber sortable or drag-to-reorder behavior, especially @dnd-kit, touch/mobile interactions, variable-width items, or wrapping layouts.

    11k GitHub stars~1.8k tokensUpdated today
    Auto-check passed

  • Locale UI Patterns

    openchamber/openchamber

    A skill your agent uses when creating or modifying OpenChamber UI text, labels, buttons, placeholders, aria labels, empty states, toasts, dialogs, settings copy, navigation labels, or any…

    11k GitHub stars~1.5k tokensUpdated today
    Auto-check passed

  • Performance Engineering

    openchamber/openchamber

    A skill your agent uses when implementing or reviewing code on interaction, render, event, polling, synchronization, list-processing, store-selector, cache, indexing, or high-volume data paths; when…

    11k GitHub stars~4.9k tokensUpdated today
    Auto-check passed

  • Serve Sim

    openchamber/openchamber

    A skill your agent uses when working with the OpenChamber iOS Simulator app without opening Xcode - boot/install/launch the Capacitor iOS app, start a browser stream, tap/type/gesture/rotate…

    11k GitHub stars~619 tokensUpdated today
    Auto-check passed

Categories

Questions about Triage Issues

What does Triage Issues do?

Load when asked to triage, clean up, batch-process, or work through the issue backlog — covers the mechanical sweep (stale-fixed, dead needs-info, duplicates), fan-out assessment, and approved batch…. Triage Issues is an agent skill from openchamber/openchamber. Load when asked to triage, clean up, batch-process, or work through the issue backlog — covers the mechanical sweep (stale-fixed, dead needs-info, duplicates), fan-out assessment, and approved batch actions.

When should I use Triage Issues?

Triage Issues fits situations like: tasks that involve Issue triage.

How do I install Triage Issues in Claude Code?

Run `npx skills add openchamber/openchamber --skill triage-issues -a claude-code`. Or copy the skill folder (.agents/skills/triage-issues in openchamber/openchamber) into .claude/skills/triage-issues in your project. Claude Code loads it when a task matches its description.

How do I install Triage Issues in Codex?

Run `npx skills add openchamber/openchamber --skill triage-issues -a codex`. Or copy the skill folder (.agents/skills/triage-issues in openchamber/openchamber) into .agents/skills/triage-issues in your project. Codex loads it when a task matches its description.

Can I use Triage Issues in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add openchamber/openchamber --skill triage-issues -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/triage-issues, .gemini/skills/triage-issues, .github/skills/triage-issues and .opencode/skills/triage-issues in your project.

What does Triage Issues need to run?

Going by SKILL.md and its folder, Triage Issues needs the command-line tools its instructions call (git and gh).

Does Triage Issues access the network?

SKILL.md contains no URLs. Its commands use git and gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Triage Issues safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Triage Issues use?

Triage Issues is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Triage Issues use?

About 3k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Triage Issues?

Skills that share tags, products or a category with Triage Issues: Wayfinder (bestofjs/bestofjs, 3.1k stars), Setup Matt Pocock Skills (bestofjs/bestofjs, 3.1k stars), Windows App SDK Issue Triage Report (microsoft/WindowsAppSDK, 4.7k stars) and Exposed Bug Fix Workflow (JetBrains/Exposed, 9.3k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Triage Issues?

openchamber (a GitHub organization) maintains it in openchamber/openchamber, which has 11,259 GitHub stars. The repository holds 20 skills in this directory. The repository was last updated on October 8, 2026.

Source: openchamber/openchamber on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.