codehava-agent-kit 1.0.1 → 2.0.0

package/templates/.agent/skills/tdd-workflow/SKILL.md

@@ -1,149 +0,0 @@
----
-name: tdd-workflow
-description: Test-Driven Development workflow principles. RED-GREEN-REFACTOR cycle.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
----
-
-# TDD Workflow
-
-> Write tests first, code second.
-
----
-
-## 1. The TDD Cycle
-
-```
-🔴 RED → Write failing test
-    ↓
-🟢 GREEN → Write minimal code to pass
-    ↓
-🔵 REFACTOR → Improve code quality
-    ↓
-   Repeat...
-```
-
----
-
-## 2. The Three Laws of TDD
-
-1. Write production code only to make a failing test pass
-2. Write only enough test to demonstrate failure
-3. Write only enough code to make the test pass
-
----
-
-## 3. RED Phase Principles
-
-### What to Write
-
-| Focus | Example |
-|-------|---------|
-| Behavior | "should add two numbers" |
-| Edge cases | "should handle empty input" |
-| Error states | "should throw for invalid data" |
-
-### RED Phase Rules
-
-- Test must fail first
-- Test name describes expected behavior
-- One assertion per test (ideally)
-
----
-
-## 4. GREEN Phase Principles
-
-### Minimum Code
-
-| Principle | Meaning |
-|-----------|---------|
-| **YAGNI** | You Aren't Gonna Need It |
-| **Simplest thing** | Write the minimum to pass |
-| **No optimization** | Just make it work |
-
-### GREEN Phase Rules
-
-- Don't write unneeded code
-- Don't optimize yet
-- Pass the test, nothing more
-
----
-
-## 5. REFACTOR Phase Principles
-
-### What to Improve
-
-| Area | Action |
-|------|--------|
-| Duplication | Extract common code |
-| Naming | Make intent clear |
-| Structure | Improve organization |
-| Complexity | Simplify logic |
-
-### REFACTOR Rules
-
-- All tests must stay green
-- Small incremental changes
-- Commit after each refactor
-
----
-
-## 6. AAA Pattern
-
-Every test follows:
-
-| Step | Purpose |
-|------|---------|
-| **Arrange** | Set up test data |
-| **Act** | Execute code under test |
-| **Assert** | Verify expected outcome |
-
----
-
-## 7. When to Use TDD
-
-| Scenario | TDD Value |
-|----------|-----------|
-| New feature | High |
-| Bug fix | High (write test first) |
-| Complex logic | High |
-| Exploratory | Low (spike, then TDD) |
-| UI layout | Low |
-
----
-
-## 8. Test Prioritization
-
-| Priority | Test Type |
-|----------|-----------|
-| 1 | Happy path |
-| 2 | Error cases |
-| 3 | Edge cases |
-| 4 | Performance |
-
----
-
-## 9. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Skip the RED phase | Watch test fail first |
-| Write tests after | Write tests before |
-| Over-engineer initial | Keep it simple |
-| Multiple asserts | One behavior per test |
-| Test implementation | Test behavior |
-
----
-
-## 10. AI-Augmented TDD
-
-### Multi-Agent Pattern
-
-| Agent | Role |
-|-------|------|
-| Agent A | Write failing tests (RED) |
-| Agent B | Implement to pass (GREEN) |
-| Agent C | Optimize (REFACTOR) |
-
----
-
-> **Remember:** The test is the specification. If you can't write a test, you don't understand the requirement.

package/templates/.agent/skills/uu-pdp-feature-check/SKILL.md

@@ -1,116 +0,0 @@
----
-name: uu-pdp-feature-check
-description: |
-  Use when building any feature that collects, stores, displays, or processes
-  user personal data. Triggers on "user data", "personal info", "profile",
-  "upload", "store user", "collect", "privacy", "consent", or when creating
-  new database models with user-related fields. Do NOT use for pure UI/styling tasks.
----
-
-# UU PDP Compliance — Checklist Fitur Baru
-
-Setiap fitur yang menyentuh data pribadi pengguna WAJIB melewati checklist ini.
-
-## 1. Identifikasi Data
-
-Sebelum coding, tentukan:
-- **Data apa** yang dikumpulkan fitur ini?
-- **Kategori mana**: Data Umum (nama, email, HP, alamat) atau Data Spesifik/Sensitif (NIK, rekening, kesehatan, biometrik, data anak)?
-- **Tujuan**: untuk apa data ini dipakai?
-- **Retensi**: berapa lama data disimpan?
-
-## 2. Checklist Implementasi
-
-```
-□ Consent tersedia sebelum data dikumpulkan
-  → Jika data baru yang belum ada consent-nya, update consent flow
-
-□ Data minimization — hanya kumpulkan yang benar-benar dibutuhkan
-  → Hapus field yang "nice to have" tapi tidak essential
-
-□ Data sensitif dienkripsi di kolom database
-  → NIK, nomor rekening, data kesehatan: gunakan pgcrypto
-
-□ Audit log tersedia untuk akses ke data ini
-  → Siapa mengakses, kapan, dari IP mana
-
-□ User bisa lihat/edit/hapus data ini dari settings
-  → Terhubung ke fitur "Unduh Data" dan "Hapus Akun"
-
-□ Data TIDAK dikirim ke layanan luar negeri dalam bentuk raw
-  → Cloudflare/Firebase/Resend: pastikan hanya metadata, bukan data sensitif
-
-□ Log tidak mengandung data PII
-  → console.log TIDAK boleh print NIK, password, nomor rekening, token
-```
-
-## 3. Pola Enkripsi Kolom Sensitif (PostgreSQL)
-
-```sql
--- Aktifkan pgcrypto (sekali saja)
-CREATE EXTENSION IF NOT EXISTS pgcrypto;
-
--- Simpan data terenkripsi
-UPDATE users
-SET nik_encrypted = pgp_sym_encrypt(nik_plaintext, current_setting('app.encryption_key'))
-WHERE id = $1;
-
--- Baca data terenkripsi
-SELECT pgp_sym_decrypt(nik_encrypted::bytea, current_setting('app.encryption_key'))
-FROM users WHERE id = $1;
-```
-
-```prisma
-// Di schema.prisma: simpan sebagai Bytes untuk data terenkripsi
-model User {
-  nikEncrypted Bytes?   // Terenkripsi via pgcrypto
-  // JANGAN buat field nikPlaintext
-}
-```
-
-## 4. Audit Log Pattern
-
-```typescript
-// lib/audit/index.ts
-export async function logDataAccess(params: {
-  actorId: string
-  action: 'VIEW' | 'EDIT' | 'DELETE' | 'EXPORT'
-  resourceType: string
-  resourceId: string
-  ipAddress: string
-}) {
-  await prisma.auditLog.create({
-    data: {
-      ...params,
-      createdAt: new Date(),
-      // Audit log: append-only, tidak ada updatedAt
-    },
-  })
-}
-```
-
-## 5. Yang TIDAK BOLEH Dilakukan
-
-```typescript
-// ❌ Log data sensitif
-console.log('User NIK:', user.nik)
-console.log('Payment token:', token)
-
-// ❌ Kirim data sensitif ke Resend sebagai email content
-await resend.emails.send({ html: `NIK kamu: ${user.nik}` })
-
-// ❌ Simpan PII di URL/query params
-router.push(`/verify?nik=${nik}`)
-
-// ❌ Hard-code data sensitif di kode
-const adminNIK = '3201...'
-```
-
-## 6. Layanan Luar Negeri — Batasan
-
-| Layanan | Boleh Kirim | JANGAN Kirim |
-|---------|-------------|--------------|
-| Cloudflare | Headers, IP (sudah ada DPA) | Konten body yang terenkripsi |
-| Firebase FCM | Device token, notif payload | NIK, data rekening, data kesehatan |
-| Resend | Alamat email, teks notifikasi umum | NIK, nomor rekening, data medis |
-| Sentry | Error message, stack trace | Password, token auth, NIK |

package/templates/.agent/skills/vulnerability-scanner/SKILL.md

@@ -1,276 +0,0 @@
----
-name: vulnerability-scanner
-description: Advanced vulnerability analysis principles. OWASP 2025, Supply Chain Security, attack surface mapping, risk prioritization.
-allowed-tools: Read, Glob, Grep, Bash
----
-
-# Vulnerability Scanner
-
-> Think like an attacker, defend like an expert. 2025 threat landscape awareness.
-
-## 🔧 Runtime Scripts
-
-**Execute for automated validation:**
-
-| Script | Purpose | Usage |
-|--------|---------|-------|
-| `scripts/security_scan.py` | Validate security principles applied | `python scripts/security_scan.py <project_path>` |
-
-## 📋 Reference Files
-
-| File | Purpose |
-|------|---------|
-| [checklists.md](checklists.md) | OWASP Top 10, Auth, API, Data protection checklists |
-
----
-
-## 1. Security Expert Mindset
-
-### Core Principles
-
-| Principle | Application |
-|-----------|-------------|
-| **Assume Breach** | Design as if attacker already inside |
-| **Zero Trust** | Never trust, always verify |
-| **Defense in Depth** | Multiple layers, no single point |
-| **Least Privilege** | Minimum required access only |
-| **Fail Secure** | On error, deny access |
-
-### Threat Modeling Questions
-
-Before scanning, ask:
-1. What are we protecting? (Assets)
-2. Who would attack? (Threat actors)
-3. How would they attack? (Attack vectors)
-4. What's the impact? (Business risk)
-
----
-
-## 2. OWASP Top 10:2025
-
-### Risk Categories
-
-| Rank | Category | Think About |
-|------|----------|-------------|
-| **A01** | Broken Access Control | Who can access what? IDOR, SSRF |
-| **A02** | Security Misconfiguration | Defaults, headers, exposed services |
-| **A03** | Software Supply Chain 🆕 | Dependencies, CI/CD, build integrity |
-| **A04** | Cryptographic Failures | Weak crypto, exposed secrets |
-| **A05** | Injection | User input → system commands |
-| **A06** | Insecure Design | Flawed architecture |
-| **A07** | Authentication Failures | Session, credential management |
-| **A08** | Integrity Failures | Unsigned updates, tampered data |
-| **A09** | Logging & Alerting | Blind spots, no monitoring |
-| **A10** | Exceptional Conditions 🆕 | Error handling, fail-open states |
-
-### 2025 Key Changes
-
-```
-2021 → 2025 Shifts:
-├── SSRF merged into A01 (Access Control)
-├── A02 elevated (Cloud/Container configs)
-├── A03 NEW: Supply Chain (major focus)
-├── A10 NEW: Exceptional Conditions
-└── Focus shift: Root causes > Symptoms
-```
-
----
-
-## 3. Supply Chain Security (A03)
-
-### Attack Surface
-
-| Vector | Risk | Question to Ask |
-|--------|------|-----------------|
-| **Dependencies** | Malicious packages | Do we audit new deps? |
-| **Lock files** | Integrity attacks | Are they committed? |
-| **Build pipeline** | CI/CD compromise | Who can modify? |
-| **Registry** | Typosquatting | Verified sources? |
-
-### Defense Principles
-
-- Verify package integrity (checksums)
-- Pin versions, audit updates
-- Use private registries for critical deps
-- Sign and verify artifacts
-
----
-
-## 4. Attack Surface Mapping
-
-### What to Map
-
-| Category | Elements |
-|----------|----------|
-| **Entry Points** | APIs, forms, file uploads |
-| **Data Flows** | Input → Process → Output |
-| **Trust Boundaries** | Where auth/authz checked |
-| **Assets** | Secrets, PII, business data |
-
-### Prioritization Matrix
-
-```
-Risk = Likelihood × Impact
-
-High Impact + High Likelihood → CRITICAL
-High Impact + Low Likelihood  → HIGH
-Low Impact + High Likelihood  → MEDIUM
-Low Impact + Low Likelihood   → LOW
-```
-
----
-
-## 5. Risk Prioritization
-
-### CVSS + Context
-
-| Factor | Weight | Question |
-|--------|--------|----------|
-| **CVSS Score** | Base severity | How severe is the vuln? |
-| **EPSS Score** | Exploit likelihood | Is it being exploited? |
-| **Asset Value** | Business context | What's at risk? |
-| **Exposure** | Attack surface | Internet-facing? |
-
-### Prioritization Decision Tree
-
-```
-Is it actively exploited (EPSS >0.5)?
-├── YES → CRITICAL: Immediate action
-└── NO → Check CVSS
-         ├── CVSS ≥9.0 → HIGH
-         ├── CVSS 7.0-8.9 → Consider asset value
-         └── CVSS <7.0 → Schedule for later
-```
-
----
-
-## 6. Exceptional Conditions (A10 - New)
-
-### Fail-Open vs Fail-Closed
-
-| Scenario | Fail-Open (BAD) | Fail-Closed (GOOD) |
-|----------|-----------------|---------------------|
-| Auth error | Allow access | Deny access |
-| Parsing fails | Accept input | Reject input |
-| Timeout | Retry forever | Limit + abort |
-
-### What to Check
-
-- Exception handlers that catch-all and ignore
-- Missing error handling on security operations
-- Race conditions in auth/authz
-- Resource exhaustion scenarios
-
----
-
-## 7. Scanning Methodology
-
-### Phase-Based Approach
-
-```
-1. RECONNAISSANCE
-   └── Understand the target
-       ├── Technology stack
-       ├── Entry points
-       └── Data flows
-
-2. DISCOVERY
-   └── Identify potential issues
-       ├── Configuration review
-       ├── Dependency analysis
-       └── Code pattern search
-
-3. ANALYSIS
-   └── Validate and prioritize
-       ├── False positive elimination
-       ├── Risk scoring
-       └── Attack chain mapping
-
-4. REPORTING
-   └── Actionable findings
-       ├── Clear reproduction steps
-       ├── Business impact
-       └── Remediation guidance
-```
-
----
-
-## 8. Code Pattern Analysis
-
-### High-Risk Patterns
-
-| Pattern | Risk | Look For |
-|---------|------|----------|
-| **String concat in queries** | Injection | `"SELECT * FROM " + user_input` |
-| **Dynamic code execution** | RCE | `eval()`, `exec()`, `Function()` |
-| **Unsafe deserialization** | RCE | `pickle.loads()`, `unserialize()` |
-| **Path manipulation** | Traversal | User input in file paths |
-| **Disabled security** | Various | `verify=False`, `--insecure` |
-
-### Secret Patterns
-
-| Type | Indicators |
-|------|-----------|
-| API Keys | `api_key`, `apikey`, high entropy |
-| Tokens | `token`, `bearer`, `jwt` |
-| Credentials | `password`, `secret`, `key` |
-| Cloud | `AWS_`, `AZURE_`, `GCP_` prefixes |
-
----
-
-## 9. Cloud Security Considerations
-
-### Shared Responsibility
-
-| Layer | You Own | Provider Owns |
-|-------|---------|---------------|
-| Data | ✅ | ❌ |
-| Application | ✅ | ❌ |
-| OS/Runtime | Depends | Depends |
-| Infrastructure | ❌ | ✅ |
-
-### Cloud-Specific Checks
-
-- IAM: Least privilege applied?
-- Storage: Public buckets?
-- Network: Security groups tightened?
-- Secrets: Using secrets manager?
-
----
-
-## 10. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Scan without understanding | Map attack surface first |
-| Alert on every CVE | Prioritize by exploitability + asset |
-| Ignore false positives | Maintain verified baseline |
-| Fix symptoms only | Address root causes |
-| Scan once before deploy | Continuous scanning |
-| Trust third-party deps blindly | Verify integrity, audit code |
-
----
-
-## 11. Reporting Principles
-
-### Finding Structure
-
-Each finding should answer:
-1. **What?** - Clear vulnerability description
-2. **Where?** - Exact location (file, line, endpoint)
-3. **Why?** - Root cause explanation
-4. **Impact?** - Business consequence
-5. **How to fix?** - Specific remediation
-
-### Severity Classification
-
-| Severity | Criteria |
-|----------|----------|
-| **Critical** | RCE, auth bypass, mass data exposure |
-| **High** | Data exposure, privilege escalation |
-| **Medium** | Limited scope, requires conditions |
-| **Low** | Informational, best practice |
-
----
-
-> **Remember:** Vulnerability scanning finds issues. Expert thinking prioritizes what matters. Always ask: "What would an attacker do with this?"

package/templates/.agent/skills/vulnerability-scanner/checklists.md

@@ -1,121 +0,0 @@
-# Security Checklists
-
-> Quick reference checklists for security audits. Use alongside vulnerability-scanner principles.
-
----
-
-## OWASP Top 10 Audit Checklist
-
-### A01: Broken Access Control
-- [ ] Authorization on all protected routes
-- [ ] Deny by default
-- [ ] Rate limiting implemented
-- [ ] CORS properly configured
-
-### A02: Cryptographic Failures
-- [ ] Passwords hashed (bcrypt/argon2, cost 12+)
-- [ ] Sensitive data encrypted at rest
-- [ ] TLS 1.2+ for all connections
-- [ ] No secrets in code/logs
-
-### A03: Injection
-- [ ] Parameterized queries
-- [ ] Input validation on all user data
-- [ ] Output encoding for XSS
-- [ ] No eval() or dynamic code execution
-
-### A04: Insecure Design
-- [ ] Threat modeling done
-- [ ] Security requirements defined
-- [ ] Business logic validated
-
-### A05: Security Misconfiguration
-- [ ] Unnecessary features disabled
-- [ ] Error messages sanitized
-- [ ] Security headers configured
-- [ ] Default credentials changed
-
-### A06: Vulnerable Components
-- [ ] Dependencies up to date
-- [ ] No known vulnerabilities
-- [ ] Unused dependencies removed
-
-### A07: Authentication Failures
-- [ ] MFA available
-- [ ] Session invalidation on logout
-- [ ] Session timeout implemented
-- [ ] Brute force protection
-
-### A08: Integrity Failures
-- [ ] Dependency integrity verified
-- [ ] CI/CD pipeline secured
-- [ ] Update mechanism secured
-
-### A09: Logging Failures
-- [ ] Security events logged
-- [ ] Logs protected
-- [ ] No sensitive data in logs
-- [ ] Alerting configured
-
-### A10: SSRF
-- [ ] URL validation implemented
-- [ ] Allow-list for external calls
-- [ ] Network segmentation
-
----
-
-## Authentication Checklist
-
-- [ ] Strong password policy
-- [ ] Account lockout
-- [ ] Secure password reset
-- [ ] Session management
-- [ ] Token expiration
-- [ ] Logout invalidation
-
----
-
-## API Security Checklist
-
-- [ ] Authentication required
-- [ ] Authorization per endpoint
-- [ ] Input validation
-- [ ] Rate limiting
-- [ ] Output sanitization
-- [ ] Error handling
-
----
-
-## Data Protection Checklist
-
-- [ ] Encryption at rest
-- [ ] Encryption in transit
-- [ ] Key management
-- [ ] Data minimization
-- [ ] Secure deletion
-
----
-
-## Security Headers
-
-| Header | Purpose |
-|--------|---------|
-| **Content-Security-Policy** | XSS prevention |
-| **X-Content-Type-Options** | MIME sniffing |
-| **X-Frame-Options** | Clickjacking |
-| **Strict-Transport-Security** | Force HTTPS |
-| **Referrer-Policy** | Referrer control |
-
----
-
-## Quick Audit Commands
-
-| Check | What to Look For |
-|-------|------------------|
-| Secrets in code | password, api_key, secret |
-| Dangerous patterns | eval, innerHTML, SQL concat |
-| Dependency issues | npm audit, snyk |
-
----
-
-> **Usage:** Copy relevant checklists into your PLAN.md or security report.