Issue Triage Brief Before You Dump a GitHub Issue into a Blank Chat
Maintainers often paste a raw GitHub issue into a blank chat. A triage ritual: type, severity, repro gaps, and one next action.
By AgentOps Lab
You already paste GitHub issues into an agent. What still fails is starting the reply, the label, or the “fix this” prompt before anyone agrees what the report is. A raw issue body, a screenshot, and a pile of comments go into a blank chat; a confident answer comes out; and only then do you notice the severity was assumed, the repro was invented, and the next action was a mass-comment draft you should never post.
This post is an issue-triage-brief ritual for maintainers who already use AI agents on repositories they have rights to. It is not a star-growth guide, not an income promise, and not a license to auto-comment or mass-close issues.
You will leave with a brief shape, a 15-minute drill, and a pointer to other live AgentOps Lab brief rituals. The maintainer-ops store listing is not up yet, so this post does not send you to a checkout page that is still unpublished.
The symptom: the blank-chat tax
Typical week:
- Monday — you dump a messy issue into chat and ask for “what should we do.”
- Tuesday — the agent invents a reproduction you cannot stand behind.
- Wednesday — severity is “blocker” because the reporter used urgent language, not because impact was in the text.
- Thursday — a comment draft appears that would close three other tickets the agent guessed were duplicates.
- Friday — you redo the triage because nobody wrote down type, gaps, or one next action.
That is not “the model being dumb.” It is missing maintainer-ops. Triage needs a job description the agent can follow: restate the report → classify type → propose severity only from the text (or UNKNOWN) → name the affected surface → capture repro steps, environment, and gaps → split reported facts from assumptions → note related issues only if you cited them → recommend one next action → ask ≤5 questions the reporter could actually answer → flag whether the note is public-safe.
Skip that ritual and every later step — labeling, packing a good-first issue, or drafting a close — is guessing.
Brief shape you can paste into a skill
Restated report (1 sentence):
Type:
Severity (from text / UNKNOWN):
Affected surface:
Repro (steps / environment / gaps):
Reported facts:
Assumptions (labeled):
Related / duplicates (only if cited):
Next action:
Clarifying questions (≤5):
Public-safe? yes / no (if no: private handling note)
Suggested labels (optional, from your taxonomy):
Rule: the agent must fill type, severity or UNKNOWN, and repro gaps before it offers to comment or close. If those are empty, the brief is theater. If the paste looks like an undisclosed security issue, stop public drafting and handle it privately.
Five fields people skip (and why they matter)
Type, from the text. Bug, feature, docs, question, support, security-sensitive, or other. “It feels like a bug” is an assumption until the report says what broke. If it looks security-sensitive, the brief’s job is to stop, not to write a public advisory.
Severity, or UNKNOWN. Blocker / high / medium / low only from what the reporter actually said. Do not invent production impact, star counts, or “this is taking down the community.” An honest UNKNOWN is better than a fake blocker.
Repro gaps. Steps mentioned, environment mentioned, and what is missing. Mark UNKNOWN rather than inventing a reproduction the maintainer cannot run. Clarifying questions should be ones the reporter could actually answer.
Facts vs assumptions. A quoted error message is a fact. “They probably use the same setup as us” is an assumption and should be labeled. Related issue numbers belong in the brief only if you cited them or pasted search results — the agent should not scrape private repos or invent ids.
One next action. Ask-clarifying, needs-repro, accept-and-label, pack-as-good-first (only if the work is real and scoped), park, close-with-reason (a proposal), or escalate-privately. One issue, one next action. The agent drafts; you own labels, comments, and closes. No mass-comment bots.
A public-safe check sits beside these. Secrets, tokens, private emails, and undisclosed security reports do not belong in a public tracker note.
15-minute drill (use a sanitized issue)
- Pick one issue from a repository you maintain or are authorized to help with. Strip tokens, secrets, and private emails.
- If it looks like an undisclosed security report, stop this public drill and handle it privately.
- Paste the brief shape (or an
issue-triage-briefskill file, if you have one loaded) and the sanitized issue into your agent. - Require type, severity-or-UNKNOWN, and repro gaps before any comment draft.
- Accept one next action. If the agent wants to close a batch, invent a duplicate, or write a “good first issue” that is not real work, reject that output.
Success looks like a one-screen brief you could hand to another maintainer — not a comment the agent posted for you.
Hard rules worth keeping in the skill
- Only for repositories and communities you maintain or are authorized to help with
- Never publish or describe undisclosed security issues in public notes
- Do not invent reproductions, impact, star counts, or issue numbers
- Do not draft mass-comment or spam replies; do not scrape private repos
- Not a Code of Conduct tribunal, doxxing, or harassment toolkit
- Sanitize secrets, tokens, and private emails before they land in the brief
- You advise; the maintainer owns labels, comments, and closes
- No star, fame, or earnings promises — files and rituals do not grow a project for you
These rules are the difference between a reusable brief and a confident, unusable reply.
What this ritual is not
It will not get your project more stars, contributors, or sponsorships. Files and rituals do not promise that.
It is not a license to mass-close issues, invent “good first issues” to farm contributors, or work in repositories you do not have rights to.
It is not a substitute for judgment. A clear brief still needs you to decide what to label, what to ask, and when to take a report private.
Where to go next
The same brief-before-blank-chat idea shows up in other AgentOps Lab rituals that are already listed. If you review pull requests more often than issues, the live Coding Agent Ops teaser walks a PR-review brief (intent, blast radius, risks, test gaps) — that is a merge-safety ritual, not a maintainer issue-triage pack:
→ Coding Agent Ops free teaser on itch
Catalog and other live packs:
A full Open Source Maintainer Ops pack (issue triage plus first-issue packing, onboarding, community release notes, RFC logs, a humane stale sweep, and weekly status) is being prepared. This article does not link a store or product page that is not live yet. When that listing exists, it will appear on the AgentOps Lab hub.
No star, fame, or earnings promises. Authorized repos only. No mass-comment bots. Never publish undisclosed security issues. Files only; you remain the maintainer.
AgentOps Lab builds installable ops skills for AI agents. Deep links only — we do not ask you to trust anonymous store roots.
About the author
- AgentOps Lab ships ready-to-run skills, prompts, and workflows. Browse free teasers → paid packs: https://agentops-lab.netlify.app/ · No fake earnings claims.
Comments
Join the discussionNo comments yet. Be the first to comment.