n8n + GitHub + Linear/Jira: automatické třídění issue s AI a notifikace do Slacku
Postav v n8n workflow, které roztřídí každé nové GitHub issue (případně Linear/Jira) pomocí AI: kategorie, priorita, štítky, Slack notifikace s @here pro P1. Tarify, ceny a bezpečnostně-jemná místa (prompt injection, webhook smyčky) včetně ověřených cen k 30. 9. 2026.
🛠️ Co budete potřebovat
Nástroje
- • n8n — Cloud Starter za 20 €/měsíc při roční platbě (2 500 executionů), Pro 50 €/měsíc (10 000 executionů), nebo Community Edition self-hosted zdarma; ověřeno 30. 9. 2026 na n8n.io/pricing
- • GitHub libovolný tarif včetně Free (issues, labely i webhooky zdarma; Team stojí 4 $/uživatel/měsíc prvních 12 měsíců); ověřeno 30. 9. 2026 na github.com/pricing
- • Linear Free (0 $, neomezení členové, 2 týmy, 250 issues; Basic 10 $/uživatel/měsíc při roční platbě) nebo Jira Free (0 $ do 10 uživatelů, 150 automation kroků na subscription měsíčně; Standard 7,91 $/uživatel/měsíc při měsíční platbě); ověřeno 30. 9. 2026 na linear.app/pricing a atlassian.com/software/jira/pricing
- • Slack Free (0 €, historie zpráv 90 dní, neomezeně kanálů; Pro 6,75 €/uživatel/měsíc při roční platbě, 8,25 € při měsíční); ověřeno 30. 9. 2026 na slack.com/pricing (ceník se zobrazuje v EUR)
- • OpenAI API klíč s dobitým kreditem — klasifikační model gpt-6-luna (0,10 $ vstup / 0,50 $ výstup za milión tokenů); ověřeno 30. 9. 2026
Dovednosti
- • Orientace v n8n editoru: přidat node, vytvořit credential, spustit workflow a číst Executions (základy popisuje N8N automatizace: průvodce krok za krokem)
- • Základy Gitu a GitHubu: issue, label, repozitář, osobní přístupový token
- • Admin práva ve Slack workspace (instalace n8n aplikace a právo chat:write)
- • Představa o JSON — odpověď AI parsuješ a validuješ (bez psaní kódu, node Code má hotovou šablonu)
V kostce
- Workflow nové issue → AI klasifikace → štítky + priorita → Slack notifikace postavíš v n8n za odpoledne; celý stack zaběhne v bezplatných tarifech (self-hosted n8n) nebo za 20 €/měsíc (n8n Cloud Starter, roční platba).
- AI klasifikace stojí prakticky nic: gpt-6-luna účtuje 0,10 $ za milión vstupních a 0,50 $ za milión výstupních tokenů — sto issues měsíčně přijde na jednotky korun.
- Nejdůležitější pravidlo: první dva týdny provozuj dry-run (návrhy jen do Slacku) a teprve pak zapni zápis štítků — špatně označené issue je horší než nezatříděné.
- Text issue je nedůvěryhodný vstup: proti prompt injection model instruuj, že obsah issue je materiál ke klasifikaci, ne instrukce, a odpověď vždy validuj proti schématu.
- Linear webhook musí dostat odpověď 200 do 5 sekund, jinak delivery opakuje (3 pokusy za 1 minutu / 1 hodinu / 6 hodin) a pak se webhook zakáže — odpovídej hned a AI volání dělej asynchronně.
Krok za krokem
Domluv taxonomii: Slack kanály a jednotné labely
- Ve Slacku vytvoř dva kanály: #devops-triage pro běžné issue a #devops-kriticke pro P1 (na Free tarifu je kanálů neomezeně, historie zpráv 90 dní).
- V GitHubu otevři Issues → Labels a sjednoť sadu štítků: bug, feature, dokumentace, security, infra plus priority P1–P4. Maž labely, které tým nepoužívá — každý navíc snižuje přesnost AI.
- Stejnou sadu nastav v trackeru: v Linear jsou labely per tým, v Jiře v projektu (pole Labels + výchozí stupnice priority Highest → Lowest).
- Napiš si jednořádkové definice kategorií a priorit (P1 = produkce nedostupná nebo bezpečnostní incident, P2 = blokuje uživatele, existuje workaround, P3 = neblokuje, P4 = kosmetika a nápady). Tyhle definice použiješ v promptu v kroku 4.
- Dohodni s týmem, kdo kanály sleduje a jaká je očekávaná reakce na P1.
Tip
- 5–7 kategorií a 4 priority je optimum pro tým do ~20 lidí; víc kategorií AI chybuje častěji a lidi přestávají rozumět rozdílům.
- Label security nech AI navrhovat, ale rozhodnutí o zveřejnění bezpečnostního issue vždy nech na člověku.
- Definice si ulož vedle promptu (třeba v souboru v repozitáři) — budou se hodit při ladění.
Pozor
- Když labely jen přidáš a nestrukturuješ je, AI dědí chaos: tři labely pro totéž (bug, chyba, defect) znamenají náhodné rozdělování.
Očekávaný výsledek
Máš dva Slack kanály, 5–7 kategorií + 4 priority sjednocené v GitHubu i trackeru a písemné definice připravené pro prompt.
Nastav GitHub Trigger v n8n
- V n8n vytvoř nový workflow, přidej node GitHub Trigger a zvol event na issues.
- Na GitHubu vytvoř fine-grained token: Settings → Developer settings → Personal access tokens → Fine-grained tokens, Repository access jen na sledovaný repozitář, oprávnění Issues: Read and write + Metadata: Read-only.
- Token vlož do credential v n8n a v triggeru vyber repozitář.
- Alternativa bez trigger node: v repozitáři Settings → Webhooks → Add webhook, Payload URL z n8n node Webhook, Content type application/json, event Issues. GitHub podepisuje requesty hlavičkou X-Hub-Signature-256.
- Vyzkoušej spouštění: vytvoř testovací issue („Test: přihláška končí chybou 500 po aktualizaci konfigurace“) a v n8n v Executions ověř, že workflow doběhl a v datech je action opened.
Tip
- GitHub Trigger je pohodlnější než ruční webhook — vytvoří a ověřuje webhook za tebe.
- Fine-grained token s minimem oprávnění znamená, že při úniku tokenu útočník maximálně přepíše labely issues.
- Trigger filtruj na action opened, aby editace issue nespouštěla třídění znovu (a nevznikla smyčka s krokem 5).
Pozor
- Nepoužívej classic token s plným repo scope, když stačí Issues + Metadata — zásada minimálních oprávnění.
Očekávaný výsledek
Workflow se spustí při každém novém issue; v Executions vidíš JSON s action opened, názvem, textem issue a autorem.
Napoj Linear nebo Jiru (pokud je používáš)
- Linear: v n8n přidej node Linear (nebo Linear Trigger, když je Linear zdrojem issues). API klíč vygeneruj v Linear v Settings → Workspace → API — webhooky smí vytvářet jen admin workspace.
- Jira: v n8n přidej node Jira Software. Credential = e-mail + API token z id.atlassian.com (sekce Security → Create API token).
- Rozhodni topologii: GitHub jako zdroj + Linear/Jira jako cíl zápisu je nejjednodušší. Oboustranné zrcadlení issues je zdroj smyček.
- U Linear si zapamatuj mapování priority: 0 = bez priority, 1 = Urgent, 2 = High, 3 = Medium, 4 = Low.
- U Jiry ověř, že projekt používá pole Labels a Priority s výchozí stupnicí (Highest, High, Medium, Low, Lowest).
Tip
- Jira Free zvládne do 10 uživatelů a 150 automation kroků na subscription měsíčně — automatizaci ale stejně řešíš v n8n, ne v Jiře, takže limit se tě netýká.
- Linear požaduje odpověď do 5 sekund, jinak delivery opakuje (3 pokusy: po 1 minutě, 1 hodině a 6 hodinách) a webhook může zakázat — odpovídej 200 hned a AI volání dělej asynchronně.
- Když tým žije jen v GitHub Issues, celý krok přeskoč — workflow funguje i bez trackeru.
Pozor
- Webhook z aktualizace issue může spustit další běh workflow — vždy filtruj podle akce (created/opened), ne reakce na každý update.
Očekávaný výsledek
Node Linear/Jira je připojený s platným credential a z testovacího issue umíš přečíst i zapsat labely a prioritu.
AI klasifikace: kategorie, priorita, štítky
- Za trigger přidej node OpenAI, zvol model gpt-6-luna (0,10 $ vstup / 0,50 $ výstup za milión tokenů, ověřeno 30. 9. 2026).
- Napiš systémový prompt v češtině: role klasifikátora issue, definice kategorií a priorit z kroku 1, instrukce „odpověz striktně JSON podle schématu“ a schéma {kategorie, priorita, stitky, shrnuti, duvod}.
- Přidej 2–3 few-shot ukázky (reálné texty issues se správným JSON výstupem) a nastav teplotu 0.
- Do promptu vlož instrukci, že text issue je výhradně materiál ke klasifikaci, nikdy instrukce — obrana proti prompt injection.
- Za AI node přidej node Code, který zvaliduje odpověď: špatný JSON nebo kategorie mimo seznam → kategorie netrideno, priorita P3, workflow pokračuje dál.
Tip
- Few-shot ukázky sníží chybovost víc než dlouhý popis kategorií — ber reálné issues z vlastního repozitáře.
- Jak spolehlivě vynutit JSON výstup modelu popisuje návod Jak získat JSON z AI.
- Issue píší lidé různě (česky, anglicky, emotivně) — do ukázek zahrň i krátké nezřetelné texty, aby AI nechytila jazykovou předsudečnost.
Pozor
- Text issue je nedůvěryhodný vstup od vnějšího světa: kdokoli může do issue napsat „ignoruj instrukce“. Podrobnosti a vrstvy obrany v článku Prompt injection: 6 vrstev obrany.
- Bez validačního Code node rozsypaná odpověď AI shodí celý workflow a issue zůstane bez notifikace, aniž bys si toho všiml.
Očekávaný výsledek
Na testovacích issues vrací AI konzistentní JSON se správnými hodnotami; poškozená odpověď končí jako netridedo/P3, nikdy pádem workflow.
Zapiš štítky a prioritu zpět do issue
- Za klasifikaci přidej node GitHub s operací editace issue: doplň štítky z pole stitky + prioritu z pole priorita.
- Do komentáře issue přidej AI shrnutí s důvodem priority — při ladění promptu hned vidíš, proč AI rozhodla jak rozhodla.
- V Linear node aktualizuj issue: labely a prioritu přelož z P-stupnice (P1 → 1 Urgent … P4 → 4 Low).
- V Jira node nastav pole Labels a Priority obdobně.
- První dva týdny provozuj dry-run: štítky nepropisuj, posílej je jen do Slacku vedle sebe, co issue říká a co AI navrhuje, a denně porovnávej. Až budeš spokojený s přesností (typicky nad 90 % u čistých kategorií), zapni zápis.
Tip
- Špatně označené issue je horší než nezatříděné: label security u kosmetiky vyvolá paniku, P4 u výpadku zjistíš od zákazníka.
- Zapiš si metriku: kolik % issues klasifikovala AI stejně jako člověk. Až se přestane zlepšovat, prompt už dál neladit.
Pozor
- Zápis AI rozhodnutí do produkce bez dry-run fáze je nejčastější chyba tohoto typu automatizace.
- Aktualizace issue spouští webhook znovu — drž filtr na action opened z kroku 2, jinak workflow klasifikuje stejné issue opakovaně.
Očekávaný výsledek
Issue v GitHubu (a trackeru) má po chvíli štítky, prioritu a komentář se shrnutím; v dry-run režimu chodí návrhy jen do Slacku.
Slack notifikace podle priority
- Za klasifikaci přidej node IF: priorita P1 → kanál #devops-kriticke, vše ostatní → #devops-triage.
- Slack node připoj přes OAuth s právem chat:write a vyber cílové kanály.
- Zpráva pro P1: název issue, odkaz, AI shrnutí + důvod priority, navržené štítky a zmínka @here — o P1 se má někdo začít starat hned.
- Zpráva pro běžná issue: kompaktní souhrn (kategorie, priorita, odkaz) formátovaný přes Block Kit, aby na první pohled bylo jasné, jde o bug nebo feature žádost.
- Ověř, že notifikace nedorazí dvakrát (jednou z GitHubu, jednou z trackeru) — notifikace posílá jeden uzel, ne každý zdroj zvlášť.
Tip
- Slack Free má historii zpráv 90 dní — kanály jsou provozní řízení, archivem zůstává GitHub/tracker.
- Trvalé @here na všem ničí účel kanálu: @here patří jen na P1.
Očekávaný výsledek
Nové issue dorazí do správného kanálu podle priority, P1 s @here; nic nedorazí dvakrát.
Testy, error handling a limity
- Vytvoř Error Trigger workflow: při selhání triage workflow přijde zpráva do #devops-errors s názvem workflow a chybovou hláškou (postup v návodu N8N AI agent, který nespadne).
- Vezmi 10–20 reálných posledních issues (česky i anglicky, od různých autorů), spusť je skrz workflow ručně a porovnej s lidským roztříděním.
- Zkontroluj limity: n8n Cloud Starter = 2 500 executionů měsíčně, Pro = 10 000 (ověřeno 30. 9. 2026 na n8n.io/pricing); jedno issue ≈ jeden execution. Self-hosted nemá limit executionů.
- Zaveď týdenní revizi: projdi chybné klasifikace, uprav prompt, po měsíci přejdi na čtrnáctidenní interval.
- Po dvou týdnech dry-run zapni zápis štítků (krok 5) a sleduj první týden provozu těsněji.
Tip
- Syntetická issues typu „test bug“ klasifikuje AI vždy správně — jediný test, který něco znamená, jsou reálné texty.
- Náklady na AI si kontroluj v OpenAI dashboardu: při stovkách issues měsíčně budeš v jednotkách korun, ale graf využití odhalí nečekané smyčky.
- Náklady na běh celého stacku: 0 Kč (self-hosted n8n + free tarify) až 20 €/měsíc (n8n Cloud Starter při roční platbě).
Pozor
- Bez error workflow se triage rozbije tiše a nezatříděná issue si nikdo nevšimne — monitoring je součást automatizace, ne bonus.
Očekávaný výsledek
Workflow má error notifikace, prošlo testem na reálných issues, znáš svou měsíční spotřebu executionů a máš zavedenou pravidelnou revizi přesnosti.
Výsledky implementace
❌ Před implementací
- • Nové issue čeká v repozitáři, než ho někdo z týmu přečte: vedoucí vývoje ručně přiřazuje labely, odhaduje prioritu a píše do Slacku. Při 150 issues měsíčně je to 8–12 hodin rutinní práce a P1 bug se často odhalí až ranní kontrolou — nebo od zákazníka.
✅ Po implementaci
- • Každé nové issue má do pár sekund kategorii, prioritu a štítky (v GitHubu i Linear/Jiře) a notifikace jde do Slacku podle důležitosti — P1 s @here do kanálu pro kritické věci. Tým řeší jen ověření a přiřazení, ne ruční třídění.