Review Discussions Cx

/review-discussions — GitHub Discussions Review & Response Workflow

Overview

This workflow reads all open GitHub Discussions, generates a categorized summary, identifies which ones need a response, drafts and posts replies, and optionally creates issues from actionable feature requests. It follows the same flow used for Issues but adapted for the Discussions forum.

Tool mapping note (v3.8): Where steps below say browser_subagent, modern runtimes should substitute with the gh CLI — gh api graphql for reading discussions and mutations for posting comments. WebFetch is acceptable for read-only HTML scraping when GraphQL is overkill, but prefer gh for any write actions.

Codex Execution Notes

• Treat // turbo / // turbo-all as instructions to use multi_tool_use.parallel for independent reads and GitHub/browser fetches.
• The summary report is a hard stop. Do not post discussion replies or create issues until the user explicitly approves.

// turbo-all

Steps

1. Identify the GitHub Repository

• Run: git -C <project_root> remote get-url origin to extract the owner/repo
• Parse the owner and repo name from the URL

2. Fetch All Open Discussions

• Use WebFetch to fetch https://github.com/<owner>/<repo>/discussions
• Parse the discussion list to get all discussion titles, IDs, authors, categories, and dates
• For each discussion, fetch the individual page to read the full content and all comments/replies

3. Summarize All Discussions

For each discussion, extract:

• Title and #Number
• Author (GitHub username)
• Category (Announcements, General, Ideas, Q&A, Show and tell)
• Date created
• Summary of the original post (1-2 sentences)
• Comments count and key participants
• Your previous response (if any)
• Pending action — whether a response or follow-up is needed

4. Present Summary Report to User

Present the full summary to the user organized by category, using a table:

Highlight:

• ⚠️ Needs response — No reply from maintainer, or a follow-up comment was left unanswered
• ✅ Answered — Maintainer already responded
• 🐛 Bug reported — A bug was mentioned that needs tracking
• 💡 Actionable — Contains a concrete feature request that could become an issue

5. Draft & Post Responses

For each discussion that needs a response, draft a reply following these guidelines:

Response Style

• Friendly and professional — Start with "Hey @username!"
• Acknowledge the contribution — Thank the user for their input
• Be specific — Reference existing features, settings, or dashboard pages if the feature already exists
• Provide workarounds — If the request isn't implemented yet, suggest current alternatives
• Commit to action — If the request is valid, state that you'll open an issue or add it to the roadmap
• Keep it concise — 3-5 paragraphs max

Posting via Browser

• Use browser_subagent to navigate to each discussion and post the comment
• IMPORTANT: When typing text in GitHub comment boxes via the browser, use only plain ASCII characters:
  • Use regular hyphens - instead of em-dashes
  • Use -> instead of arrow symbols
  • Do NOT use emoji Unicode characters (the browser keyboard may fail on them)
  • Use **bold** and \code`` markdown formatting
• Click the green "Comment" button (or "Reply" for threaded replies) after typing
• Verify the comment was posted by checking the page shows the new comment

6. Create Issues from Actionable Feature Requests

For discussions that contain concrete, actionable feature requests:

1. Ask the user which ones should become issues
2. For each approved request, create a GitHub issue via browser_subagent:
   • Navigate to https://github.com/<owner>/<repo>/issues/new
   • Title: <Feature Name> - <Short description>
   • Body should include:
     • ## Feature Request header
     • **Source:** Discussion #N by @author
     • ## Problem — What limitation the user hit
     • ## Proposed Solution — How it could work
     • ### Implementation Ideas — Technical approach
     • ### Current Workarounds — What users can do today
     • ## Additional Context — Links to related issues/discussions
   • Add enhancement label
   • Click "Submit new issue" / "Create"
3. After creation, go back to the original discussion and post a comment linking to the new issue:
   • "I've opened Issue #N to track this feature request. Follow along there for updates!"

7. Final Report

Present a final summary to the user:

Notes

• This workflow is interactive — always present the summary and wait for user approval before posting responses or creating issues
• If the user says "pode responder" (or similar approval), proceed with posting all drafted responses
• For discussions in non-English languages, respond in the same language as the original post
• Always reference specific dashboard paths, config options, or code files when explaining existing features
• When a discussion reveals a bug, note it separately from feature requests