Triage GitHub issues to a Notion board with Qwen via OpenRouter

WHAT IT DOES When a new issue is opened on a GitHub repository, this workflow uses an AI model to classify it by type (bug, feature, question, documentation, other), assign a priority level (high, medium, low), and generate a one-sentence summary. Results are written to a Notion database and posted as a triage comment on the GitHub issue. No external triage service. No SaaS subscription. Runs on your own n8n instance. HOW IT WORKS 1. GitHub Webhook Trigger Listens for the "issues" event with action "opened" on the configured repository. Fires only when a new issue is created. Does not trigger on comments, edits, or closes. 2. Extract Issue Data Parses the webhook payload. GitHub Trigger wraps the full payload as a JSON string in the "body" field, so this node extracts the actual issue object, then pulls out the fields the workflow needs: issue number, title, body text (truncated to 2000 characters to stay within LLM token limits), URL, author, labels, and repository full name. Falls back to parsing the repositoryurl field if the repository object is missing from the payload. 3. Duplicate Check (Notion) Queries the Notion database for an existing entry with the same Issue URL. If a match is found, the workflow stops — this issue was already triaged. If the Notion API fails (timeout, rate limit, invalid token), the error branch fires and the workflow continues anyway. A failed duplicate check should not block triage. 4. AI Triage (Qwen 3 via OpenRouter) Sends the issue title and body to the model with a structured prompt that asks for: category, priority, summary, and suggested labels. The prompt includes clear definitions for each category and priority level so the model classifies consistently. If the LLM call fails, a fallback node assigns default values (category: other, priority: medium) so the issue is still tracked in Notion. 5. Create Notion Entry Writes a new row to the Notion database with all triage fields populated: title, issue URL, author, category, priority, summary, suggested labels, status (Open), source (ai or fallback), and creation date. 6. Post GitHub Comment Adds a formatted comment on the GitHub issue showing the triage result: category, priority, summary, and suggested labels. If the triage used fallback values because the LLM was unavailable, a warning is included in the comment so the team knows to review it manually. WHY THIS APPROACH - Most issue triage tools push results back into GitHub as labels. This workflow pushes to Notion instead. The reason: teams already use Notion as their project management hub. Having issues auto-classified and waiting in a Notion database means you can filter, sort, and assign without switching tools. The Notion database becomes the single view where all incoming issues are triaged and prioritized before anyone touches them. - The AI model does classification, not decision-making. It does not close issues or assign people - it categorizes and summarizes. A human reviews the Notion board and decides what to act on. This keeps the human in the loop while removing the 30-60 seconds of manual sorting per issue that adds up fast when you are getting 10+ issues a week. - The duplicate check prevents wasted API calls. If an issue was already triaged (maybe someone triggered the webhook twice, or re-opened a closed issue), the workflow skips it instead of creating a duplicate Notion entry. If the duplicate check itself fails (Notion API timeout), the workflow continues to triage anyway — better to over-triage than to miss an issue because of a transient error. - The fallback mechanism means the workflow never silently drops an issue. If the LLM is down, rate-limited, or returns garbage, the issue still gets a Notion entry with default values and a "fallback" source indicator. The GitHub comment warns the team that AI was unavailable. - Self-hosted means your issue data never leaves your infrastructure. The only external call is to the LLM provider (OpenRouter by default), and yo