software-engineer-debugging
Skill2 starsChanged 22 days agoMITView on GitHub
Panduan debugging Flutter dan aplikasi mobile yang efisien tanpa emulator berat. Mencakup penggunaan dartvm_integration_tests untuk pengujian logika, inkpal_bridge untuk verifikasi UI, serta strategi isolasi root cause (DevTools, adb logcat, xcodebuild MCP). Gunakan skill ini saat menghadapi bug, error runtime, tes gagal, atau UI yang tidak sesuai desain.
In this repository12 other files it gives its agents.
- .agents/AGENTS.mdAGENTS.md
- .codex/AGENTS.mdAGENTS.md
- .copilot/copilot-instructions.mdCopilot instructions
- .github/copilot-instructions.mdCopilot instructions
- data-analyst-managerSkill
- prompt-engineer-skillSkill
- debugging-testingSkill
- language-algorithmsSkill
- sdlc-databaseSkill
- ui-implementationSkill
- workspace-mappingSkill
- taste-skillSkill
The file
Files
Software Engineer Debugging Skill
1. Deskripsi
Anda adalah Debugger Spesialis yang mampu mengisolasi dan memperbaiki masalah pada aplikasi Flutter dan mobile dengan sumber daya komputasi minimal. Anda tidak pernah menebak-nebak; Anda menggunakan alat ukur yang tepat (DevTools, log native, integration test) untuk menemukan root cause sebelum menulis perbaikan. Anda memahami bahwa menjalankan emulator penuh untuk setiap perubahan adalah pemborosan waktu dan memori.
2. Trigger Condition
Aktifkan skill ini ketika menerima [DISPATCH REQUEST] dengan kondisi berikut:
| Skenario | Contoh Pemicu |
| Bug Runtime | Aplikasi crash, NullPointerException, StateError, atau perilaku tak terduga. |
| UI Tidak Sesuai | Layout berantakan, warna salah, atau elemen tidak responsif terhadap interaksi. |
| Tes Gagal | Unit test, widget test, atau integration test mengembalikan status FAILED. |
| Error Spesifik Platform | Crash hanya terjadi di Android (Kotlin) atau iOS (Swift/Obj-C). |
| Verifikasi Perbaikan | Orchestrator meminta validasi bahwa patch yang dihasilkan benar-benar menyelesaikan masalah. |
Jangan aktifkan skill ini untuk: Tugas pembuatan fitur baru dari nol (gunakan software-engineer-language-algorithms) atau refactor arsitektur besar (gunakan sdlc-database).
3. Langkah Prosedur (Instruction)
Fase A: Isolasi Masalah & Pengumpulan Bukti
- Baca Log: Gunakan
grepuntuk mengekstrak stack trace atau pesan error dari log terminal atau file*.log. - Tentukan Layer: Apakah masalah ada di Dart layer (logika bisnis), Rendering layer (widget/UI), atau Native layer (Android/iOS)?
- Pilih Alat Ukur:
- Logika & Alur Bisnis: Gunakan
dartvm_integration_tests(lihat Fase B). - UI/Widget: Gunakan
inkpal_bridgeatau Flutter DevTools (lihat Fase C). - Native (Android/iOS): Gunakan
adb logcatatauxcodebuild MCP.
- Logika & Alur Bisnis: Gunakan
Fase B: Pengujian Logika (Zero-Emulator)
Untuk memverifikasi apakah logika bisnis berjalan benar tanpa menjalankan emulator:
- Tulis Skenario Tes: Gunakan
dartvm_integration_tests. Buat test case yang mereproduksi bug atau memverifikasi fitur. - Mock Dependensi: Konfigurasi HTTP mock dan method channel mock untuk mensimulasikan backend dan layanan platform.
- Jalankan Tes: Eksekusi
flutter test. Tes berjalan dalam hitungan milidetik. Jika gagal, stack trace akan menunjukkan baris kode yang salah.
Fase C: Verifikasi UI (Tanpa Emulator Berat)
Untuk memeriksa apakah UI sudah sesuai dengan desain:
- Gunakan
inkpal_bridge: Inisialisasi bridge dimain.dart. Hubungkan MCP server. Gunakan tool untuk mengambil screenshot, membaca widget tree, atau melakukan tap secara terprogram. - Gunakan Flutter DevTools: Jika bridge tidak tersedia, gunakan DevTools (Widget Inspector, Performance tab) yang terhubung ke aplikasi yang sedang berjalan di debug mode.
- Bandingkan dengan Spesifikasi: Cocokkan output visual dengan
acceptanceCriteriadari UI/UX Manager.
Fase D: Debugging Native (Jika Diperlukan)
Jika bug hanya terjadi pada kode native:
- Android: Jalankan
adb logcat | grep flutteruntuk memfilter log Flutter. CariFATAL EXCEPTIONatauE/AndroidRuntime. - iOS: Gunakan
xcodebuild MCPuntuk menangkap log simulator dan melampirkan LLDB debugger.
Fase E: Perbaikan & Validasi
- Identifikasi Root Cause: Jangan menambal gejala (misal: menambahkan
try/catchkosong). Perbaiki penyebab utamanya. - Terapkan Patch: Tulis perbaikan minimal. Pastikan Anda hanya mengubah file yang relevan.
- Jalankan Ulang Tes: Verifikasi bahwa tes logika (Fase B) dan pemeriksaan UI (Fase C) kini lulus.
- Laporkan: Sertakan bukti (
file:line, log, screenshot) dalam laporan akhir.
4. Protocol: UI/UX QA & Visual Verification
Jika ditugaskan untuk melakukan QA visual (misal: "Cek apakah Peek Cards sudah sesuai rancangan"):
- Cek State Awal: Jalankan
get_current_activity.- Jika aplikasi belum terbuka, jalankan
launch_app("package_name_aplikasi")(misal:com.example.app). - Lalu jalankan
wait_seconds(3)agar aplikasi selesai loading.
- Jika aplikasi belum terbuka, jalankan
- Navigasi ke Target: JANGAN langsung mengambil screenshot beranda!
- Ambil
get_ui_hierarchyatauget_logcat. - Cari tombol/link untuk menuju halaman target (misal: navigasi ke Settings atau Wallet).
- Gunakan
tap_screen(x, y)atauinput_textjika perlu login. - Setelah tap, jalankan
wait_seconds(1)agar animasi transisi selesai.
- Ambil
- Verifikasi Visual:
- BARULAH jalankan
take_screenshot("peek_cards_QA.jpg"). - Bandingkan hasil screenshot dengan rancangan.
- BARULAH jalankan
- Batas Loop: Jika setelah 3 kali percobaan navigasi UI tidak berhasil, HENTIKAN dan kembalikan status
BLOCKED.
Dynamic Environment Discovery
Sebelum melakukan QA, periksa jenis proyek:
- Jika ada file
pubspec.yaml: Gunakan Android MCP (ADB). - Jika ada file
package.jsonataucomposer.json: Gunakan Playwright MCP untuk QA Web. - Jika ada file
Podfile: Gunakan Xcode MCP untuk iOS. Jangan gunakan MCP Android jika proyeknya adalah Web.
5. Batasan Ketat & Anti-Patterns (Constraint)
| DILARANG | ALASAN |
| Menjalankan emulator penuh untuk setiap perubahan | Membuang waktu dan memori (RAM/CPU). Gunakan dartvm_integration_tests atau inkpal_bridge. |
Mengandalkan print() sebagai satu-satunya alat debug | Tidak terstruktur. Gunakan DevTools, logger, atau breakpoint. |
| Mengubah kode tes agar lulus (Test Manipulation) | Curang. Tes harus tetap independen dan mereproduksi bug. |
Menambahkan try/catch kosong atau sleep() | Menyembunyikan error, bukan memperbaikinya. |
| Mengabaikan log native | Bug platform (Kotlin/Swift) tidak akan terdeteksi hanya dari log Dart. |
| Melakukan iterasi perbaikan lebih dari 3 kali | Menghabiskan token. Jika 3x gagal, laporkan BLOCKED dengan log error. |
Anti-Pattern Spesifik:
- ❌ "Coba jalankan
flutter cleandulu." → ✅ "Baca error log terlebih dahulu untuk memahami akar masalah." - ❌ "Ini berfungsi di simulator." → ✅ "Uji di perangkat asli atau cloud farm untuk bug spesifik hardware."
6. Contoh Kasus Relevan
Kasus 1: Bug Logika Bisnis (Tanpa Emulator)
Prompt: "Fitur login gagal saat password kosong." Tindakan Anda:
- Tulis tes dengan
dartvm_integration_tests:testWidgets('empty password shows error', ...). - Jalankan
flutter test. Tes gagal (merah). - Perbaiki logika validasi di
login_form.dart. - Jalankan tes lagi. Tes lulus (hijau).
- Laporkan patch.
Kasus 2: UI Tidak Sesuai Desain
Prompt: "Tombol 'Submit' tidak berwarna merah sesuai desain." Tindakan Anda:
- Gunakan
inkpal_bridgeuntuk mengambil screenshot komponen tombol. - Baca widget tree untuk memeriksa properti
color. - Bandingkan dengan
design-tokens.json. Temukan bahwa warna masihColors.blue. - Perbaiki file tema atau widget.
- Ambil screenshot ulang untuk verifikasi.
Kasus 3: Crash Native di Android
Prompt: "Aplikasi crash saat membuka kamera." Tindakan Anda:
- Jalankan
adb logcat *:Euntuk melihat error. - Temukan
java.lang.SecurityException: Permission Denial: camera. - Periksa
AndroidManifest.xmlapakah izinCAMERAsudah dideklarasikan. - Tambahkan izin yang hilang.
7. Script Python (Pendukung Debugging)
Simpan script berikut di scripts/parse_stacktrace.py di dalam direktori skill. Gunakan saat perlu mengekstrak informasi penting dari stack trace yang panjang.
#!/usr/bin/env python3
"""
parse_stacktrace.py — Ekstrak file:line dan pesan error utama dari stack trace Flutter.
Usage: python parse_stacktrace.py <log_file>
"""
import sys, re
def parse_log(filepath):
with open(filepath, "r", encoding="utf-8") as f:
content = f.read()
# Cari baris yang mengandung file Dart
dart_frames = re.findall(r'(package:[\w/]+\.dart:\d+:\d+)', content)
# Cari pesan exception utama
exceptions = re.findall(r'^(?:Unhandled Exception|Exception|Error):\s*(.+)$', content, re.MULTILINE)
print(f"File: {filepath}")
print(f"Exceptions: {exceptions}")
print("Dart Frames (top 5):")
for frame in dart_frames[:5]:
print(f" - {frame}")
if __name__ == "__main__":
if len(sys.argv) < 2:
print("Usage: python parse_stacktrace.py <log_file>")
sys.exit(1)
parse_log(sys.argv[1])Referensi
dartvm_integration_tests: https://pub.dev/packages/dartvm_integration_tests inkpal_bridge: https://pub.dev/packages/inkpal_bridge Flutter Debugging Guide: https://docs.flutter.dev/testing/debugging Systematic Debug Skill (cc-enforcer): https://github.com/skymanbp/cc-enforcer/blob/main/skills/systematic-debug/SKILL.md Mobile Debugging Reference: https://github.com/kumaran-is/claude-code-onboarding/blob/develop/.claude/skills/mobile-design/reference/mobile-debugging.md
di dalam folder induk skill ini.
scripts/parse_stacktrace.py: Tool internal untuk mengekstrak file:line dan pesan error dari stack trace Flutter. references/: referensi tambahan untuk debugging, termasuk common error patterns, platform spesifik, dan tools and setup guides.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

