Most queues fill with missing repros, vague titles, and support requests disguised as bugs.
Triagekit generates stricter issue forms, support redirects, and a maintainer checklist so small OSS projects can cut triage time without building a whole support system first.
Most queues fill with missing repros, vague titles, and support requests disguised as bugs.
Generate a stricter issue form, a support redirect config, and a reusable triage checklist.
The shortest path to OSS impact is saving maintainers time on the first round-trip.
Start with one repository type, decide what evidence maintainers need, and the page generates the files you can drop into GitHub today.
Good for npm packages, SDKs, and framework extensions where maintainers need exact versions and integration context.
A maintainer tool is easier to ship than a whole platform, easier to explain than a generic AI product, and more likely to qualify as ecosystem-helpful even before it gets huge.
These are designed to be immediately useful. Start with one repository, improve issue quality, then package the generator or templates for other maintainers.
name: "Triagekit bug report"
description: "Report a reproducible problem in Triagekit."
title: "[bug]: "
labels: ["bug", "needs-triage"]
body:
- type: markdown
attributes:
value: "Thanks for helping improve Triagekit. Please fill out the sections below so maintainers can reproduce the issue quickly."
- type: textarea
id: summary
attributes:
label: "What happened?"
description: "A short description of the bug and the impact."
placeholder: "When I run ... I expected ... but ..."
validations:
required: true
- type: textarea
id: reproduction
attributes:
label: "How can we reproduce it?"
description: "List the smallest set of steps a maintainer can follow."
placeholder: "1. Install ...\n2. Run ...\n3. Observe ..."
validations:
required: true
- type: textarea
id: expected
attributes:
label: "What did you expect to happen?"
placeholder: "Expected ..."
validations:
required: true
- type: textarea
id: environment
attributes:
label: "Environment"
description: "OS, runtime version, package manager, framework version, and related integrations"
placeholder: "OS, runtime version, package manager, framework version, and related integrations"
validations:
required: true
- type: textarea
id: evidence
attributes:
label: "Logs, screenshots, or failing output"
description: "Paste the shortest relevant logs or attach screenshots."
render: "shell"
validations:
required: false
- type: checkboxes
id: checks
attributes:
label: "Before submitting"
options:
- label: "I searched existing issues and did not find a duplicate."
- label: "I can still reproduce this on the latest Triagekit version."
- label: "I included enough detail for a maintainer to verify the issue."
validations:
required: trueblank_issues_enabled: false
contact_links:
- name: "Triagekit usage question"
url: "https://github.com/owner/repo/discussions"
about: "Please use discussions or documentation questions for general support."
- name: "Security or sensitive report"
url: "mailto:maintainers@example.com"
about: "Use this channel for sensitive disclosures rather than a public issue."# Triagekit maintainer triage checklist Use this checklist when a new issue arrives. ## 1. Intake - Confirm the report used the issue form. - Confirm the title states the failure, not just a symptom. - Move usage questions to `https://github.com/owner/repo/discussions` instead of tracking them as bugs. ## 2. Reproduction quality - Can a maintainer reproduce it from the details in `.github/ISSUE_TEMPLATE/triagekit-bug-report.yml`? - If not, ask for the smallest repro, exact version, and environment details. - Remove noise and ask for only the logs that change the diagnosis. ## 3. Routing - Add subsystem labels immediately. - Mark confirmed regressions separately from first-time bug reports. - Link duplicates instead of carrying parallel conversations. ## 4. Exit rules - Close reports that never become reproducible after follow-up. - Convert well-scoped bugs into issues with owner, severity, and next action. - Capture recurring confusion as docs fixes or FAQ updates.
The goal is not to fake scale. The goal is to ship one obviously useful maintainer workflow, use it yourself, and make it easy for other repos to adopt.
Tune the generator for one repo and commit the templates under `.github/ISSUE_TEMPLATE`.
Publish the generated files in a small public repo with before/after screenshots of issue quality.
Turn the generator rules into a reusable GitHub Action or hosted template picker next.