Stage C of the go-live playbook: switch on the tracker bridge. The code ships in the image and stays off until these credentials exist, so none of it blocks going live.
Gates: C1 needs nothing and can be done any time. C2 and C3 wait until the bot has been answering on the real server for about a week — long enough to know the answers are good before any of them are attached to a public tracker.
C3 goes last because answering is the only step here that writes into somebody else's tracker. Widening later is adding a name to answeringRepositories and a webhook; a bad comment on a maintainer's bug report is not so easily taken back.
Already verified against the real API (2026-08-06): the issue-filing payload works, GitHub creates the from-discord label on first use so no repository needs preparing, and the duplicate-search response matches what the code reads. What has never run is the Discord half of /issue — that is what C2 proves.
A PAT acts as the person who created it — issues show their name, it expires, and it shares their rate limit. A GitHub App gives Prompter its own identity for about an hour of setup; the code sends either as a bearer token, so switching is changing one secret.
Stage C of the go-live playbook: switch on the tracker bridge. The code ships in the image and stays off until these credentials exist, so none of it blocks going live.
Gates: C1 needs nothing and can be done any time. C2 and C3 wait until the bot has been answering on the real server for about a week — long enough to know the answers are good before any of them are attached to a public tracker.
/githubappended, registered on the repositories forissuesevents. Do this one regardless of the rest — it needs nothing from Prompter and keeps working when Prompter is down.Issues: Read and write) so/issuecan file. Verify by filing something harmless and checking thefrom-discordlabel.GITHUB_WEBHOOK_SECRETplusansweringRepositories, and a webhook per opted-in repository pointing at/github/webhook. One repository first. Verify both directions: an issue the docs answer gets a cited comment, one they do not gets silence plus a maintainer-channel note.C3 goes last because answering is the only step here that writes into somebody else's tracker. Widening later is adding a name to
answeringRepositoriesand a webhook; a bad comment on a maintainer's bug report is not so easily taken back.Already verified against the real API (2026-08-06): the issue-filing payload works, GitHub creates the
from-discordlabel on first use so no repository needs preparing, and the duplicate-search response matches what the code reads. What has never run is the Discord half of/issue— that is what C2 proves.A PAT acts as the person who created it — issues show their name, it expires, and it shares their rate limit. A GitHub App gives Prompter its own identity for about an hour of setup; the code sends either as a bearer token, so switching is changing one secret.