Sync Bug Triage Meeting Decisions to GitHub Issues Automatically with SuperIntern MCP
Picture the end of your weekly bug triage meeting.
You just spent 30 minutes making careful calls: "this one is P1, put it in the next milestone", "label this one as needs-repro", "that one should be fixed already, close it." Then the meeting ends, and none of those decisions exist anywhere yet. Someone opens GitHub with the meeting notes on a second screen, searches for each issue, swaps labels, sets milestones, assigns owners, and (if there is time, which there never is) writes a comment explaining why. On a 20-issue day, that sync work alone eats 30 minutes. Worse, when it gets postponed, the tracker and the team's actual decisions drift apart for days, and the next triage starts with "wait, didn't we make this a P1?"
In this guide, we connect SuperIntern's MCP and GitHub's MCP server to Claude, so that applying triage decisions to GitHub issues becomes a single prompt, with real prompt examples you can copy.
⚠️ This article was independently compiled based on publicly available information and user feedback as of August 2026.
Table of Contents
- Today's Goal: Before / After
- How It Works: Three Roles
- Setup
- Demo 1: Apply Triage Decisions to Issues in One Pass
- Demo 2: File Verbally Reported Bugs with a Duplicate Check
- Demo 3: A Weekly Audit of Meeting-vs-Tracker Drift
- Tips for Day-to-Day Use
- Beyond GitHub: The Same Pattern Elsewhere
- FAQ
Today's Goal: Before / After
Before: After triage, someone toggles between the meeting notes and GitHub, opening issues one by one to apply labels, milestones, and assignees by hand. Nobody has time to record the reasoning, so three weeks later nobody remembers why an issue became P1.
After: When the meeting ends, you ask Claude once: "apply today's triage decisions to GitHub." Claude reads the decisions from the meeting summary, finds each issue, updates labels, milestones, and assignees, and leaves a comment on every issue with the reasoning and the source meeting.
For context: SuperIntern is a botless desktop app (no bot joins your calls) that captures transcripts and AI meeting notes automatically. During triage you just argue about bugs like you always do. The decisions accumulate as meeting data on their own, so the only thing left to automate is the sync to GitHub.
How It Works: Three Roles
Three participants make this work.
| Role | Player | What it does |
|---|---|---|
| Provides meeting data | SuperIntern MCP | Serves transcripts, live transcripts, AI summaries, and meeting notes, read-only |
| Judgment and drafting | Claude (the AI client) | Reads meeting data, extracts decisions, matches them to issues, drafts updates |
| Action target | GitHub (MCP) | Searches issues, updates labels and milestones, assigns users, comments, files new issues |
MCP (Model Context Protocol) is an open standard for safely connecting AI assistants to external tools. SuperIntern's MCP serves your meeting data to the AI client read-only, while GitHub's official MCP server handles searching, creating, and updating issues. In other words, it is Claude that touches your GitHub issues, not SuperIntern. Your SuperIntern data can never be modified through MCP, the AI can only see meetings you yourself can access, and all writes happen on the GitHub side. You can try this without any risk to your meeting records.
Setup
You need exactly two connections. The SuperIntern side needs no API key; an in-browser login completes it. For GitHub, depending on your client, you either sign in with OAuth in the browser or use a Personal Access Token.
1. Connect SuperIntern MCP to Claude
In Claude, go to Settings, then Connectors, choose "Add custom connector", and register the connection URL.
https://mcp.app.super-intern.com/mcp
A SuperIntern login screen opens; sign in and approve, and you are done. Plan requirements (Plus or higher for personal workspaces, admin enablement for Enterprise) and per-client steps for Claude Code, Cursor, and others are covered in our MCP setup guide.
2. Connect the GitHub MCP server to Claude
GitHub provides an official MCP server. Note that its remote server (https://api.githubcopilot.com/mcp/) relies on OAuth through a registered GitHub App, which Claude's "Add custom connector" flow does not currently support. Connect through one of the paths in the official installation guide instead:
- Claude Desktop: add the local GitHub MCP server (Docker) to
claude_desktop_config.json. On first use it opens a browser login to GitHub (OAuth), so there is no token to create - Claude Code: connect to the remote server with a Personal Access Token:
claude mcp add-json github '{"type":"http","url":"https://api.githubcopilot.com/mcp","headers":{"Authorization":"Bearer YOUR_GITHUB_PAT"}}'
The exact config JSON for Claude Desktop and the steps for Cursor and other clients are in the official installation guide.
Not sure the connections work? Ask this first:
Show me my 3 most recent SuperIntern meetings and 3 open issues in nanohuman/app
If both come back, you are ready.
Demo 1: Apply Triage Decisions to Issues in One Pass
The most frequent use is the batch sync right after triage. Triage decisions mostly change the state of existing issues, so the core skill here is identifying the right issue and updating it, not creating new ones.
Get the AI summary of today's "Bug triage" meeting and extract the decision for each issue.
Find the matching issues in nanohuman/app by number or description.
Apply the agreed priority labels and milestones, and assign the owners we decided on.
On each issue, add a comment with the reasoning and the source meeting name.
For issues we decided to close, comment the reason first, then close them.
Claude reads the summary, searches GitHub, and reports back like this:
Updated 8 issues.\
- #482 "Search results reset when switching tabs": added P1 and milestone v0.14, assigned to Sara. Prioritized because three customer accounts reproduced it\
- #475 "Garbled characters in CSV export": added P2, waiting on reproduction steps\
- #468 "Tooltip misalignment on settings page": added P3 and good first issue\
- #441 "Legacy dashboard layout break": confirmed fixed in v0.13, commented the reason and closed
Every issue now has a comment citing "Bug triage meeting (Aug 14)" as the source.
The key detail: it is not just labels and milestones, the reasoning lands as a comment. Open any issue and you can trace when and why it got its priority. Three weeks later, nobody has to ask "why is this P1?" And because SuperIntern's AI summaries structure decisions cleanly, extraction stays reliable.
Demo 2: File Verbally Reported Bugs with a Duplicate Check
Triage meetings and standups are full of verbal bug reports: "oh by the way, the export screen does this weird thing." If nobody writes an issue on the spot, the report gets buried in the notes and dies there.
Get the transcript of today's "Engineering standup" and list every verbal mention of a bug or defect.
Cross-check against existing issues in nanohuman/app.
Where an issue already exists, add the new context from the meeting as a comment.
Only for reports that exist nowhere, file new issues with reproduction steps.
Make titles describe the symptom, and note the reporter and source meeting in the body.
Note that this prompt uses the transcript, not the summary. Verbal bug reports often fall out of summaries, but the transcript preserves the throwaway remark. Asking for "reproduction steps" makes Claude reconstruct the flow the reporter described out loud into an actual repro list, which saves you from pinging them later.
Demo 3: A Weekly Audit of Meeting-vs-Tracker Drift
The meeting said "we'll fix it", but the issue never moved. Or an issue everyone agreed to close is still open. Once a week, detect this drift between what was agreed in meetings and what GitHub actually says. Referencing multiple meetings at once is exactly what MCP is good at.
Get all of this week's meetings in the "Product team" project and find every place
where a GitHub issue was mentioned or a decision was made about one.
Compare against the current state of issues in nanohuman/app.
Show me a table of issues where the meeting decision is not yet reflected,
with meeting name, decision, and current state. Do not apply anything yet.
This prompt deliberately asks for a table first, no changes. A weekly audit casts a wide net and can pick up offhand remarks, so reviewing the table and replying "apply these three" is the safe two-step. Run it every Friday and your tracker stays an honest mirror of what the team actually decided.
Tips for Day-to-Day Use
Name the repository explicitly. Putting "in nanohuman/app" in the prompt reliably prevents cross-repo mistakes in multi-repo organizations. Bake your usual repo names into a saved prompt.
Start with a dry run. For the first few sessions, append "show me the planned changes before applying." Once you have seen how well Claude maps meeting phrases ("that search bug") to actual issues, switch to direct application and enjoy the speed.
Say issue numbers out loud. Teams that say "#482" during triage get those numbers into the transcript, which makes Claude's matching close to perfect. If you share your screen with the issue list during triage, you are probably doing this already.
Pin your label scheme in the prompt. "Use P1/P2/P3 for priority and bug/enhancement for type" prevents the accidental creation of labels that do not exist in your scheme.
Improve proper nouns on the SuperIntern side. The more accurately feature and screen names are transcribed, the better the issue matching. Registering frequent feature names and teammate names in SuperIntern's custom dictionary is worth the two minutes.
Writes only happen on GitHub. Your SuperIntern data is never modified through MCP. If a sync lands wrong, fix it on the GitHub side; the original meeting record remains the source of truth. GitHub also keeps its own change history on every issue, which is reassuring for audits.
Beyond GitHub: The Same Pattern Elsewhere
The pattern of "SuperIntern MCP serves the data, Claude judges, another tool receives the action" extends well past GitHub.
- Other trackers: Teams on Linear can follow almost the same flow in our Linear integration guide
- Slack updates: Share the triage recap straight into your dev channel. See the Slack integration guide
- All the way to code: Connect SuperIntern MCP to Claude Code and go from "that P1 we triaged" to an actual fix informed by the meeting discussion. Our spec-to-code article shows how
We keep covering these combinations one at a time, always with real prompts.
FAQ
Q. Is SuperIntern MCP available on the free plan?
A. No. Personal workspaces need the Plus plan or higher. Team plan workspaces can use it as is, and on Enterprise an admin must first enable "MCP access" in workspace settings.
Q. Does SuperIntern write to my GitHub issues directly?
A. No. All issue updates, filings, and comments are performed by Claude via the GitHub MCP server. SuperIntern MCP only serves meeting data read-only; SuperIntern itself never writes to external tools.
Q. Can the AI modify my meeting notes or transcripts?
A. No. Every SuperIntern MCP tool is read-only; there are no create, edit, or delete operations. Writes only occur on the GitHub side.
Q. Does this work with private repositories?
A. Yes. The GitHub MCP server acts with the permissions of the credentials you connected with (your OAuth login or Personal Access Token), so it covers exactly the repositories those credentials can access, and nothing beyond them.
Q. What if it mass-applies wrong changes?
A. Use the dry-run habit from the tips section: "show me the planned changes before applying" gives you a human checkpoint. Even if something lands wrong, GitHub's issue history lets you revert, and your SuperIntern data is unaffected.
Q. Can I use an AI client other than Claude?
A. Both SuperIntern MCP and the GitHub MCP server work with MCP-capable clients such as Claude Code, Codex, and Cursor. Any client that can connect to both will run the prompts in this article nearly unchanged.
The value of a triage meeting is making decisions, not transcribing them into GitHub afterwards. Keep the deciding; hand off the transcribing.