Job issue-triage-suggestions-tuned-on-your-past-issues · revised 12 October 2026
Label new issues, link duplicates and ask for missing details; people still decide
A workflow suggests labels from your list, up to three possible duplicates and one missing-detail question on each new issue. It never closes or edits anything, and it is tested on 100 past issues.
You might be seeing
- Issues wait for a human to add labels before anyone looks at them
- Duplicates are noticed only when two people start the same fix
No passwords, keys, card details or admin invites needed to start.
What usually happened
Sorting new issues by hand is slow and uneven. Free triage workflows exist, but they are tested on nobody's issues, and an automatic triage step reads text written by strangers, which can carry instructions meant for the model.
Who it’s for: A maintainer or lead whose new issues arrive unlabelled, with duplicates and missing details that someone has to sort by hand.
Usually starts when: New issues sit unsorted for days, or the same question is filed again and again.
The result: Each new issue gets labels chosen only from your list, up to three possible duplicates and at most one question asking for missing details. The workflow never closes, edits or assigns anything. A replay on 100 of your past issues with labels hidden shows how often it agrees with you.
Check whether this job fits
Answer these without sending code, tickets or logins. Nothing is submitted unless you choose to contact us.
What you get
- The workflow as a pull request you merge
- The label guide
- The replay report with a link to every issue
- The planted-instruction test results
- The off-switch steps
Included
- One repository on GitHub Issues and a list of up to 30 labels that you own
- A workflow in your Actions, using your own model key, in two parts: a read-only part that reads the issue and a second part that applies only validated labels and one comment
- A replay on 100 past issues with their labels hidden, scored against your labels
- Twenty live issues checked by your named person after a week
- A label guide and an off switch
Not included
- Closing, editing, assigning or locking any issue, and merging any duplicate
- Triage of private tickets that hold customer personal data
- Answering issue authors beyond the one question
- Changing labels you already applied
- A promise that live issues will be triaged as well as the replay
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
On 100 past issues with labels hidden from the build and the replay, the workflow's main label matches yours on at least 85 of 100 (the true rate is then at least 77% with 95% confidence) and beats always choosing your most common label, shown beside it. Your person checks up to 20 of the possible-duplicate suggestions, chosen by script, and confirms at least 16 of 20 (the true rate is then at least 59% with 95% confidence); if the replay makes fewer than 20, the report shows the count and says it is too few to show a rate. A suggestion to close, edit or assign an issue fails the whole test, and a pass mark chosen after the run does not count.
Evidence: The 100-row replay table with links, the most-common-label baseline, and the pass marks written beforehand.
The reading part holds only read permission and the model key, and a planted instruction to close, edit or assign an issue results in no such action in five runs of each of 20 planted-instruction cases. This is a smoke test we plant.
Evidence: The permission list and the test run log; a baseline, not a claim of immunity.
Every label applied is on your list and every comment is a single question of the agreed length, checked by script on the replay and on 20 live issues.
Evidence: The script output and the 20-issue sheet.
Your named person rates 20 live issues after a week, and the sheet shows the ratings.
Evidence: The rated live sample.
Sign-off. Your named person reads the replay and the live sample and signs off in writing. You merge the workflow pull request. Payment follows sign-off.
If it fails. If the agreed checks do not pass, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- At least 100 past issues with labels your team applied and trusts
- A label list of no more than 30 labels, with a one-line meaning each
- GitHub Actions and your own model key stored by you
- A named person who checks 20 live issues after a week
We stop and tell you if
- Two of your people disagree on more than 15% of a 50-issue labelling check, so no pass mark would mean anything
- The workflow would need a secret beyond your model key
- You will not accept the written warning that issue text from strangers can carry instructions meant for the model
What could go wrong
The workflow arrives as a pull request. Close it and nothing changes. After a merge, delete the workflow file or switch it off; labels it applied stay and your team can remove them.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Text in an issue steers the model into leaking data or acting. | Issue and pull request text is treated as data, never as instructions. The reading job holds no secrets except your model key, which should be a restricted key with a spend cap, and its GitHub token is read-only; the second part can only write the labels and the one comment this page lists, and a script rejects labels outside your list. |
| Wrong duplicate links send people to the wrong issue. | Duplicates are shown as "possible" with the matching text, and nothing is closed or merged. |
| Labels trigger other automation in your repository. | We list every workflow that reacts to labels before we start, and agree which labels may be applied. |
A separate automated reviewer checks the work before hand-over. A named person on your side checks 20 live issues after a week and approves the label guide. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree labels, pass marks and the actions the workflow may never take
- Receive 100 past issues, labels hidden from the build and the replay
- Build the read-only reader and the validated label-and-comment step
- Replay all 100 issues and run planted-instruction tests, repeated runs
- Separate automated reviewer checks permissions, replay and test results
- Hand over the pull request; your person checks 20 live issues
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, price, start window and delivery date before you accept, and work starts only after agreed inputs, secure access and permissions are in place. Model usage up to a cap we state in writing is in the price, and an enquiry creates no charge or booking.
Need to keep it working?
To keep agreement with your labels from drifting, a monthly check is offered separately.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Install GitHub's free triage workflow yourself and check its output by hand for a few weeks. github.github.com
- Rotate a person on triage duty each week; slower, but no model reads your issues.
Questions
Will it close duplicate issues?
No. It suggests up to three possible duplicates with the matching text. A person closes.
Do you need our model key?
Yes, stored by you in your repository secrets. We never hold it.
What if strangers file issues on a public repository?
Their text can carry instructions meant for the model. The reading part is read-only and a script validates what it returns. You accept a written warning before we start.
Send an enquiry
Send us
- How many issues you receive a month and your label names
- Whether strangers can open issues on the repository
- No issue text, tokens or logins in the first enquiry
Later, once you agree
- An export of 100 past issues with their labels, or a Read-only bot account
- The label list with meanings
- The name of the person who checks the live sample
You keep the repository, the model key and every setting; the reading part of the workflow holds read permission and the model key only, and a second part applies labels and one comment, nothing else. The workflow runs in your account with your key; for the replay we receive the 100 issues you export, or read them through a Read-only account, and our automated agents read them in a sandbox. We make no "no training" or "no storage" promise here, and the agreement names the model provider, country, retention and training status before anything is shared.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “issue-triage-suggestions-tuned-on-your-past-issues” as the subject.