Rough report in, ready-to-file issue out — the gaps written down, never invented.
Checked live against the title standards from the source skill: sentence case, no Bug: or [Feature] prefixes (GitHub carries the type in its own field), imperative mood for work items, and specific enough to be worth reading in a list of two hundred. A generated title lands here and stays editable.
Nothing to paste? — a support forward about a CSV export that only breaks when the table is filtered. Or , rendered from a saved reply with no run and no charge.
No cleanup first. The keyword guess and the title linter run in your browser as you type — free, no sign-in, nothing sent anywhere.
Repo, version, environment, links. Anything missing stays missing: it comes back as a numbered open question rather than a plausible-sounding invention.
A plain-language paragraph saying what the issue was understood to be, plus a confidence line. If the interpretation is wrong you find out now, not after someone builds the wrong thing.
Open in GitHub sends the title, labels and body into your repo’s new-issue form. If a critical question is unanswered, send the drafted reply to the reporter first — that draft is free.
The standards below come from @tldraw/write-issue, the skill this app is derived from. They are what the model is held to, and what the free linter checks mechanically.
A good issue title is sentence case, carries no type prefix, and is specific enough to be read alone in a list of two hundred issues. Write Filtered CSV export produces misaligned columns, not Export broken. Use the imperative mood for features and tasks — Add keyboard shortcuts for the shape tools, not Adding keyboard shortcuts and not Keyboard shortcuts would be nice. Keep it under about 80 characters and leave off the trailing period.
No. GitHub stores the issue type in a dedicated field and displays it separately, so
Bug: or [Feature] at the front of a
title duplicates what the interface already shows and eats characters that could have made
the title specific. The free linter here detects bracketed tags, bare words with a colon,
and words followed by a spaced dash, and strips them in one click.
Write down only the steps the report actually supports, and record the missing reproduction
as an explicit open question rather than guessing. Inventing plausible steps, a browser
version or an environment is worse than admitting the gap, because a maintainer will trust
the invented detail and debug the wrong thing. Anything not present in your report or
context becomes a numbered open question here, and the gaps that block work from starting
are marked Critical:.
A readback is a short paragraph, in plain product-facing language with no file paths and no implementation detail, stating how the report was understood: the problem, the expected behavior and the scope. It exists so the person who filed the report can say “no, that is not what I meant” before anyone writes code. Catching a misread requirement at the readback stage costs a sentence; catching it after implementation costs a sprint.
No. There is no OAuth flow, no installed app, no token and no repository access of any
kind. Open in GitHub navigates your browser to
github.com/OWNER/REPO/issues/new with the title, labels and body
supplied as ordinary query parameters, and GitHub’s own new-issue form opens already
filled in. Nothing is filed on your behalf — you review it and press Submit yourself.
That is one of the main cases it is built for. Support staff, product managers, designers and solutions engineers often understand a problem precisely but not a given repository’s house style, and their issues get bounced for being vague. The structure — title standards, the right sections for the type, an explicit readback, honest open questions — is applied for them, so the report arrives in the shape a maintainer expects.
It is an honest read of whether the issue carries enough intent and context to be worked on as written, followed by a short clause saying what drives the number. A detailed report with reproduction steps, a version and a clear expected behavior scores high. A vague report with no reproduction and no version scores around 30 percent, not 85 — the number exists to tell a maintainer whether to start or to go back to the reporter first.