AI Skill Report Card
Reviewing Enterprise Security Architecture
Mengevaluasi desain sistem, kode, dan keputusan teknis-bisnis menggunakan lensa analisis konkret (bukan persona kosong), dengan output yang proporsional terhadap kompleksitas pertanyaan.
Quick Start12 / 15
Untuk setiap permintaan, klasifikasikan dulu:
- Pertanyaan sederhana/faktual ("apa itu JWT?") → jawab singkat, langsung, tanpa analisis multi-lensa.
- Keputusan arsitektur/desain sistem → gunakan checklist lensa analisis di bawah, terapkan hanya yang relevan (2-4 lensa, bukan semua 6).
- Evaluasi kelayakan bisnis/fitur → gunakan kerangka Strategic Assessment.
Sesuaikan bahasa dengan konteks input user — jangan paksakan formalitas berlebih pada pertanyaan casual.
Recommendation▾
The skill body is written entirely in Indonesian while the frontmatter description is in English — inconsistent language usage could confuse invocation matching and reduce accessibility; consider aligning language throughout or clarifying that Indonesian output is intentional.
Lensa Analisis (pilih yang relevan)
Security & Threat Modeling — Terapkan STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) untuk komponen yang menerima input eksternal. Format: vektor serangan → dampak → mitigasi konkret.
Zero-Trust Validation — Checklist:
- Tidak ada trust implisit berdasarkan lokasi jaringan
- Setiap request diverifikasi (identity + device posture)
- Least-privilege access per komponen
- Segmentasi/microperimeter jelas
Infrastructure & Resilience
- Immutability: komponen diganti, bukan di-patch in-place?
- Read-only filesystem di runtime — state disimpan di luar filesystem lokal?
- Air-gap: apakah komponen kritikal butuh koneksi eksternal terus-menerus?
Error Handling & Data Integrity — Setiap saran kode/logika HARUS mencakup:
- Error terstruktur (
{code, message, context}), bukan exception mentah - Idempotency untuk operasi yang bisa di-retry
- Transaction boundary jelas (commit/rollback eksplisit)
Scalability & Performance
- Identifikasi bottleneck: I/O-bound, CPU-bound, atau network-bound?
- Horizontal vs vertical scaling — mana yang cocok?
- Ada single point of failure?
Strategic Assessment (untuk keputusan bisnis/produk):
- Nilai strategis: masalah apa yang diselesaikan, untuk siapa?
- Risiko teknis: kompleksitas implementasi, dependency baru
- ROI kasar: effort vs dampak (skala 1-5)
- Rekomendasi: Go / No-Go / Perlu riset lanjutan, dengan alasan konkret
Workflow13 / 15
Progress checklist untuk permintaan arsitektur/kode kompleks:
- Klasifikasikan permintaan: faktual sederhana / desain sistem / keputusan bisnis
- Pilih 2-4 lensa analisis paling relevan (jangan paksa semua 6)
- Untuk setiap komponen teknis, terapkan alur: Input → Validation → Processing → Output
- Sertakan error handling nyata (bukan
// TODO: handle error) - Tandai asumsi default (Zero-Trust, immutable infra) HANYA jika relevan
- Tutup dengan rekomendasi actionable, bukan daftar pertanyaan terbuka
Recommendation▾
Description is solid (third person, includes triggers and negative case), but could be tightened to avoid redundancy between 'authentication/authorization design' and 'system architecture decisions' which overlap conceptually.
Examples16 / 20
Contoh 1 — Desain Autentikasi (kompleks, multi-lensa):
Input: "Bagaimana desain autentikasi yang aman untuk sistem internal dengan akses terbatas?"
Output:
ANALISIS: Autentikasi Sistem Internal
1. Threat Model (STRIDE)
- Spoofing: credential stuffing → mitigasi: rate limiting per IP+akun,
MFA wajib untuk role admin.
- Elevation of Privilege: token di-decode ulang untuk role lain
→ mitigasi: signature verification server-side, jangan percaya
claim role dari client.
2. Desain Konkret
- Short-lived access token (JWT, exp 15 menit) + refresh token
rotasi (disimpan hashed di DB, single-use).
- Struktur error saat login gagal:
{ "code": "AUTH_INVALID_CREDENTIALS", "retry_after": 30 }
(jangan bedakan "user tidak ada" vs "password salah")
- Rollback otomatis jika refresh token dipakai dua kali (indikasi
token theft) → invalidate seluruh sesi user tersebut.
3. Zero-Trust Check
- [x] Setiap request API tervalidasi ulang tokennya
- [x] Least privilege: token membawa scope, bukan role penuh
Rekomendasi: implementasikan token rotation + audit log terpisah
untuk setiap kegagalan auth.
Contoh 2 — Pertanyaan sederhana (tanpa analisis penuh):
Input: "Apa bedanya access token dan refresh token?"
Output:
Access token: kredensial berumur pendek untuk mengakses resource
(5-15 menit), dikirim di setiap request.
Refresh token: kredensial berumur lebih panjang, digunakan untuk
menukar access token baru tanpa login ulang. Disimpan lebih ketat
karena dampak kebocorannya lebih besar.
Contoh 3 — Evaluasi Kelayakan Fitur:
Input: "Apakah fitur sinkronisasi offline-first layak dikembangkan?"
Output:
STRATEGIC ASSESSMENT: Offline-First Sync
Nilai strategis: Signifikan jika target user punya konektivitas
tidak stabil. Rendah jika mayoritas user selalu online.
Risiko teknis: Tinggi — butuh conflict resolution (CRDT/vector
clock), storage lokal terenkripsi, strategi sync idempotent.
ROI kasar: Effort 4/5, Dampak 3/5.
Rekomendasi: Perlu riset lanjutan — validasi persentase user
yang terdampak masalah konektivitas. Jika >20%, Go.
Recommendation▾
Add at least one example showing a 'bad outcome' (e.g., an over-engineered response to a simple question, or a flawed analysis) to satisfy the 'both good and bad outcomes' criterion more explicitly.
Best Practices
- Sesuaikan kedalaman jawaban dengan kompleksitas pertanyaan.
- Selalu sertakan logika eksekusi nyata untuk kode (validasi input, error terstruktur, transaction boundary).
- Kaitkan rekomendasi teknis dengan dampak bisnis saat relevan, tanpa memaksakan narasi strategis pada pertanyaan teknis murni.
- Nyatakan asumsi arsitektural secara eksplisit hanya ketika relevan dengan konteks yang dibahas.
Common Pitfalls
- Jangan memberi kode skeleton, placeholder, atau
// TODOkosong. - Jangan memaksakan seluruh 6 lensa analisis untuk setiap pertanyaan.
- Jangan menyamakan kedalaman jawaban pertanyaan trivial dengan keputusan arsitektur besar.
- Jangan menambahkan branding, tanda tangan, atau elemen non-substantif di luar konten analisis.
- Jangan membedakan pesan error yang membocorkan informasi sensitif (contoh: user enumeration pada login).