Discussion Response Playbook

This playbook turns GitHub Discussions into the same operating queue as PRs, issues, Linear work, and release evidence. It is an operator guide, not a promise that every informational thread needs a public reply.

Audit Loop

Run these checks before a release, after a major merge batch, and when Linear ITO-59 is refreshed:

npm run discussion:audit -- --json
node scripts/platform-audit.js --json

The queue is current only when:

discussion fetch errors are explained or fixed;
needsMaintainerTouch is zero for support-like discussion categories;
answerable Q&A discussions either have an accepted answer or a clear routing note; and
any product-scope thread is linked to a GitHub issue, Linear issue, roadmap row, or explicit deferral.

Informational threads such as announcements, references, show-and-tell, or maintainer-authored updates can remain visible without becoming response debt.

Categories

Category	Route	Required readback
Product support or install confusion	Reply with the exact command/doc path; mark accepted answer for Q&A when the fix is complete	Discussion URL plus accepted-answer URL when applicable
Bug report	Ask for a minimal repro, version, harness, and logs; create or link a GitHub issue when reproducible	Issue URL or deferral reason
Feature request	Acknowledge the desired outcome and link the closest roadmap issue; do not imply commitment unless scoped	Linear/GitHub roadmap link
Security concern	Move exploit details and secrets to a private channel; keep the public reply short and non-operational	Private escalation note plus public safety reply
Release or billing question	Answer from the release URL ledger and publication-readiness gates; do not claim unpublished URLs, billing readiness, or plugin availability	Evidence artifact or blocker link
Show-and-tell, reference, or announcement	Leave as informational unless there is a direct question or a product-scope signal	Optional roadmap link if useful
Stale or concluded thread	Summarize the current state and link the durable doc/issue; avoid reviving low-signal threads	Closure note or explicit no-action rationale

Templates

Public Support

Thanks for the report. The current supported path is:

<command>

The relevant doc is <doc path or URL>. If this does not match your setup, please reply with the harness, OS, package manager, and the exact error text.

Maintainer Coordination

I am routing this into <issue or Linear key> so it does not get lost in the discussion queue. The next decision is <specific decision>. Until that lands, the supported workaround is <workaround or "none">.

Stale Or Concluded

This thread looks resolved or superseded by <doc/issue/release>. I am leaving it visible for history, but it is no longer an active support queue item. New repro details should go to <issue/discussion path>.

Release Announcement

The current release status is <rc/beta/GA state>. Live URLs are recorded in docs/releases/2.0.0-rc.1/release-url-ledger-2026-05-18.md. Anything marked pending there should not be announced as shipped yet.

Security Escalation

Thanks for flagging this. Please do not post exploit steps, tokens, customer data, or secret values in the public thread. I am routing this through the security response path and will keep the public thread limited to safe status updates.

Recording Outcomes

For each high-signal discussion, record one of these outcomes:

replied publicly and accepted answer read back;
linked to a GitHub issue or Linear issue;
routed to the security response path;
classified as informational; or
explicitly deferred with a reason.

Mirror the summary into ITO-59 when the batch closes, and include the counts in the next operator dashboard or publication evidence refresh.

3.8 KiB Raw Blame History