AI Class

AI Agent Workflow Automation untuk Triage Bug Report di GitHub dengan n8n: Auto-Label, Repro Step, dan Prioritas dalam 30 Menit

· 7 menit baca

AI Agent Workflow Automation untuk Triage Bug Report di GitHub dengan n8n: Auto-Label, Repro Step, dan Prioritas dalam 30 Menit

AI Agent workflow automation itu kerasa “wah” bukan saat kamu bikin chatbot, tapi saat issue GitHub kamu tiba-tiba rapi sendiri: bug report masuk, langsung diklasifikasi, diminta info yang kurang, dibuatkan langkah reproduksi, dan diprioritaskan—tanpa kamu jadi “admin” repo tiap malam.

Kalau kamu maintain produk (SaaS, library, atau app internal), kamu pasti kenal pain point ini:

  • Issue masuk random: judul nggak jelas, versi nggak ada, environment kosong.
  • Label berantakan → backlog nggak bisa dibaca.
  • Orang nanya bug yang sama berulang → duplikasi.
  • Prioritas ngandelin “yang paling berisik” di komentar.

Di artikel ini kita akan bikin AI Agent workflow automation yang jalan di n8n automation untuk triage bug report di GitHub. Targetnya bukan demo, tapi workflow yang bisa kamu pakai di repo beneran.

Kenapa AI Agent Workflow Automation buat GitHub Issue itu game changer (bukan sekadar “otomatis”)

Bedanya automasi biasa vs AI agent:

  • Automasi biasa: “kalau ada issue baru → kasih label X”. Aturan kaku, cepat buntu.
  • AI Agent workflow automation: “baca issue → pahami konteks → putuskan label yang pas → cek duplikasi → minta data yang kurang → bikin ringkasan yang siap dikerjakan dev”.

Analogi praktis: automasi biasa itu “filter email”, AI agent itu “asisten PM yang ngerti produk”.

Konsep ringkas: AI Agent Workflow Automation = LLM + Policy + Tools

Supaya nggak jadi AI yang halu, kamu butuh 3 komponen:

  • LLM untuk reasoning: memahami teks issue dan menarik struktur (kategori, severity, kebutuhan info).
  • Policy (aturan main): batasan label yang boleh, definisi severity, kapan escalate, kapan close.
  • Tools (aksi nyata): GitHub API (label/comment/assign), search issue, buat draft reproduction steps, kirim ke Slack, dll.

n8n enak karena dia memang orchestrator: gampang bikin pipeline, logging, retry, dan integrasi API. Kamu bisa vibe coding di prompt + sedikit JavaScript node, tanpa bikin service backend dulu.

AI Agent Workflow Automation: Breakdown teknis workflow di n8n

Workflow yang kita bangun:

  • Trigger: issue baru atau issue di-edit (GitHub webhook).
  • Pre-processing: normalisasi teks, ambil metadata (repo, author, labels existing).
  • Dedup check: cari issue mirip (GitHub search + embedding opsional).
  • LLM triage: klasifikasi + minta info yang kurang + usulan prioritas.
  • Actions: apply label, comment template, assign/mention, optional create checklist.
  • Notify: kirim ringkasan ke Slack/Discord/Telegram (opsional).

1) Trigger: GitHub Webhook di n8n

Pakai node GitHub Trigger atau Webhook (kalau kamu mau verifikasi signature sendiri). Event minimal:

  • issues.opened (issue baru)
  • issues.edited (update setelah diminta info)

Pro tip produksi: trigger edited penting supaya agent bisa “melanjutkan percakapan” setelah user ngisi template.

2) Normalisasi input (biar LLM nggak kebanjiran noise)

Bikin node Set / Code untuk menghasilkan objek ringkas:

  • title, body
  • user, url, repo
  • existingLabels
  • createdAt

Optional: strip markdown yang nggak perlu, potong body maksimal N karakter (misal 6–10k) untuk kontrol biaya token.

3) Dedup check (menghemat waktu paling brutal)

Step dedup sederhana tapi efektif:

  • Ambil 5–10 keyword dari judul + body (boleh via LLM kecil atau regex).
  • Panggil GitHub Search API: GET /search/issues?q=repo:ORG/REPO is:issue "keyword"
  • Ambil top 5 hasil → kirim ke LLM untuk menilai “mirip banget / agak mirip / tidak mirip”.

Kalau kamu mau lebih canggih, kamu bisa simpan embedding issue ke vector DB (Supabase/PGVector, Qdrant) dan lakukan similarity search. Tapi untuk 30 menit first version, GitHub search + LLM scoring sudah cukup.

4) LLM Triage: prompt yang “operasional”, bukan puitis

Ini bagian inti AI Agent workflow automation. Kamu butuh output terstruktur (JSON) supaya gampang dipakai node berikutnya.

Contoh schema output (yang akan dipaksa oleh prompt):

{
  "category": "bug|feature|question|docs|security",
  "areas": ["auth", "billing", "ui", "api", "performance", "other"],
  "severity": "S0|S1|S2|S3",
  "priority": "P0|P1|P2|P3",
  "confidence": 0.0,
  "missing_info": ["steps_to_reproduce", "expected", "actual", "env", "logs"],
  "suggested_labels": ["bug", "area:auth", "severity:S2"],
  "suggested_comment": "...",
  "suggested_repro_steps": ["..."],
  "duplicate_candidates": [
    {"url":"...","reason":"...","is_likely_duplicate":true}
  ],
  "next_action": "ask_for_info|label_and_queue|escalate_security|close_as_duplicate"
}

Prompt inti (ringkas tapi tajam):

You are an AI triage agent for GitHub issues.
Rules:
- Only use allowed labels list.
- Do not invent facts; if info missing, ask for it.
- If security-related, set next_action=escalate_security and avoid requesting sensitive data.
- Prefer closing as duplicate only when highly confident and cite candidate URLs.

Allowed labels:
bug, feature, question, docs,
area:auth, area:billing, area:ui, area:api, area:performance, area:other,
severity:S0, severity:S1, severity:S2, severity:S3,
priority:P0, priority:P1, priority:P2, priority:P3,
needs:info, needs:repro, duplicate

Input:
- title: {{title}}
- body: {{body}}
- existingLabels: {{existingLabels}}
- searchCandidates: {{topSearchResults}}

Return ONLY valid JSON using the schema.

Di n8n kamu bisa pakai node OpenAI/LLM provider apa pun. Kalau kamu self-host model lokal, tetap sama polanya: integrasi API via HTTP Request node.

5) Labeling & commenting via GitHub API

Setelah dapat JSON, lakukan tindakan:

  • Apply labels: gabungkan label existing + suggested_labels (hindari duplikat).
  • Add comment: pakai suggested_comment.

Comment yang bagus itu bukan “tolong lengkapi”, tapi mengurangi friction. Contoh format comment:

  • Ringkasan 2 baris
  • Checklist info yang kurang
  • Kalau ada kandidat duplikat → link + alasan
  • Kalau bisa: template snippet untuk env (OS, browser, version)

6) Escalation ke Slack/Discord (opsional tapi mantap)

Kalau priority=P0 atau severity=S0, kirim alert ke channel engineering:

  • Judul issue + link
  • Area + severity + confidence
  • Ringkasan + suggested repro steps

Ini membuat workflow automation kamu benar-benar “operationally useful”: tim dapat konteks tanpa buka GitHub dulu.

Use case real: SaaS kecil dengan 2 dev, issue masuk 20/minggu

Misalnya kamu punya SaaS B2B, issue sering begini:

Title: Login error
Body: nggak bisa login dari tadi, padahal password bener

Tanpa automasi: kamu balas manual minta versi app, browser, screenshot, steps. 5–10 menit habis.

Dengan AI Agent workflow automation di n8n:

  • Agent membaca pola “login error” + kata-kata umum.
  • Agent apply label: bug, area:auth, needs:info, severity:S2.
  • Agent komentar otomatis:
Terima kasih! Aku bantu triage dulu.

Ringkasan:
- User tidak bisa login, dugaan error di alur auth/session.

Agar bisa direpro cepat, bisa isi info ini?
- Steps to reproduce (urutan klik)
- Expected vs actual
- Environment: OS, browser/app version
- Jika ada: potongan error dari DevTools Console/Network (hapus data sensitif)

Kalau kamu pakai SSO, sebutkan provider (Google/Microsoft/Okta).

Begitu user edit issue dan menambahkan detail, trigger edited jalan: agent bisa menaikkan severity, menghapus needs:info, dan menambahkan repro steps yang lebih jelas untuk dev.

Insight/strategi (bagian paling penting): bikin agent yang “tahan banting” di repo beneran

1) Jangan mulai dari “agent otonom”, mulai dari “agent yang menjaga format”

Mayoritas workflow AI gagal bukan karena modelnya jelek, tapi karena outputnya nggak bisa dipakai otomatis. Kunci awal:

  • Paksa JSON schema.
  • Whitelist label (allowed labels).
  • Kalau parsing gagal → fallback: kasih label needs:info dan minta klarifikasi.

2) Severity vs Priority itu beda—dan harus kamu definisikan

Biar agent konsisten, definisikan secara internal, misalnya:

  • Severity = dampak teknis (crash, data loss, security).
  • Priority = urutan dikerjakan (tergantung customer impact, revenue, timeline).

Kalau tidak, agent akan “ngarang” P0 karena user panik. Kamu bisa tambahkan rule: P0 hanya jika ada data loss, outage, atau security.

3) Buat “needs:* labels” sebagai mekanisme state machine

Ini aha moment yang bikin triage jadi sistem, bukan chaos:

  • needs:info = input kurang
  • needs:repro = sudah jelas tapi belum bisa direpro
  • duplicate = kandidat duplikat ditemukan

Dengan state machine label, kamu bisa bikin dashboard backlog yang hidup. Bahkan tanpa AI pun, ini sudah menaikkan maturity repo—AI membuatnya otomatis.

4) Jangan kirim semuanya ke LLM besar: gunakan “gating”

Hemat biaya dan latency:

  • Kalau issue body kosong → langsung comment template tanpa LLM.
  • Kalau ada kata “security”, “token leaked”, “SQL injection” → langsung jalur escalate_security (LLM optional, tapi batasi output).
  • Kalau repo kecil → dedup pakai GitHub search. Kalau repo besar → baru pertimbangkan vector search.

5) Vibe coding yang benar: iterasi prompt berdasarkan failure log, bukan feeling

Setiap kali agent salah label atau minta info aneh, jangan langsung ganti model. Catat:

  • Input issue (anonymize)
  • Output JSON
  • Action yang terjadi

Lalu perbaiki prompt dengan menambah rule spesifik. Ini cara “prompt engineering” yang dewasa: berbasis bug report agent kamu sendiri.

6) Tambahkan human-in-the-loop untuk repo kritikal

Untuk project yang sensitif, kamu bisa buat mode “draft”:

  • Agent hanya memberi suggestion di comment (tidak apply label).
  • Atau apply label tapi tidak close duplicate otomatis.

n8n memudahkan: tinggal tambah node approval (misal via Slack button / form) sebelum eksekusi action.

Penutup: saatnya kamu build “Repo Ops Agent” versi kamu

Kalau kamu ingin repo kamu terasa seperti punya tim ops sendiri, mulai dari satu workflow ini: AI Agent workflow automation untuk triage issue GitHub. Begitu ini jalan, kamu bisa lanjutkan ke level berikutnya:

  • Auto-generate minimal reproduction repo (template + script)
  • Auto-create test case dari repro steps
  • Auto-link PR yang memperbaiki issue
  • Auto-release notes dari merged PR

Call to action: ambil repo kamu yang paling sering kebanjiran issue, lalu bangun workflow n8n dengan 6 node inti (trigger → normalize → search → LLM → label/comment → notify). Setelah itu, share hasilnya: metrik paling sederhana adalah waktu rata-rata dari issue dibuat sampai punya label + info lengkap. Itu KPI yang langsung kerasa.

Artikel terkait