Files
OmniRoute/.agents/workflows/review-discussions-ag.md
diegosouzapw 918a539baf docs(release): v3.8.0 documentation overhaul (FIX 1-9)
Root docs
- GEMINI.md: remove plaintext credential (Hard Rule 1) and refresh references
- CLAUDE.md: update coverage gate to 75/75/75/70, add module counts for v3.8.0
- SECURITY.md: add Supported Versions section
- AGENTS.md: refresh counts (177 providers, 37 MCP tools, 14 strategies, 5 A2A skills, 3 cloud agents) and module map
- CONTRIBUTING.md: align coverage gate, Node range, conventional-commit scopes
- CODE_OF_CONDUCT.md: refresh contact
- llm.txt: refresh Node range, provider/tool/strategy counts, add v3.8.0 highlights and documentation index
- Tuto_Qdrant.MD -> Tuto_Qdrant.md (rename + dormant-integration status banner)

i18n strict mirrors
- docs/i18n/<40 locales>/llm.txt: refresh body to match root (preserving locale header + flags line + --- separator)

Cross-references
- docs/MEMORY.md, docs/REPOSITORY_MAP.md: update Tuto_Qdrant.md path and note dormant status
- Cleanup: remove .issues/feat-batch-delete-provider-accounts.md and docs/archive/RFC-AUTO-ASSESSMENT-DRAFT.md (already absent)

Agent workflows / skills / commands
- .claude/commands/*-cc.md, .agents/workflows/*-ag.md, .agents/skills/*/SKILL.md:
  - Replace ghost tools: search_web -> WebSearch, read_url_content -> WebFetch,
    view_file -> Read, write_to_file -> Write
  - notify_user -> mandatory stop checkpoints
  - version-bump / generate-release: 2.x.y -> 3.x.y, expand docs table to 28 entries,
    mark /update-docs and /update-i18n as deprecated
  - capture-release-evidences / review-discussions: tool-mapping notes for
    browser_subagent (mcp__claude-in-chrome__* and gh CLI)
  - review-prs: align coverage thresholds (>=75/>=70, ~82% measured)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-13 08:23:02 -03:00

5.6 KiB

description
description
Read all open GitHub Discussions, summarize them, respond to pending ones, and create issues from actionable feature requests

/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, in modern Claude Code substitute with the gh CLI via Bash — 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.

// 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:

# Category Title Author Date Status
#N Ideas Title @user Mar 23 ⚠️ Needs response
#N Q&A Title @user Mar 9 Answered
#N General Title @user Mar 19 ⚠️ Needs response

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:

Discussion Action Taken
#N — Title Responded with workarounds
#N — Title Responded + created Issue #N
#N — Title Already answered, no action needed
#N — Title Responded to follow-up comment

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