pi-skill-search 0.1.0

package/skills/vetc-oracle-patterns/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: vetc-oracle-patterns
+description: PROACTIVELY activate khi tạo JPA entity, viết native query, hoặc thiết kế schema. Oracle naming conventions, sequences, NVARCHAR2, parameterized queries, view entities.
+---
+
+# VETC Oracle Database Patterns
+
+Oracle DB patterns cho VETC E-Wallet system.
+
+## When to Activate
+
+- Tạo JPA entity mới
+- Viết native query Oracle
+- Thiết kế schema (bảng, index, sequence)
+
+## Do NOT Activate When
+
+- Sử dụng database không phải Oracle (PostgreSQL, MySQL, etc.)
+- Chỉ làm frontend work (dùng `vetc-frontend-patterns`)
+- CRUD đơn giản không cần complex query, native query, hay schema design
+
+## Gotchas — Oracle Traps
+
+1. **Quên `allocationSize = 1`** → Default là 50, ID nhảy cóc. Luôn set `@SequenceGenerator(allocationSize = 1)`.
+
+2. **Native query không có `:param`** → String concat trong native query = SQL injection. Luôn dùng `@Param` placeholder.
+
+3. **`VARCHAR2` vs `NVARCHAR2`** → VARCHAR2 không chứa tiếng Việt. Text tiếng Việt phải dùng `NVARCHAR2` + `@Nationalized`.
+
+4. **Column name lowercase** → Oracle column name mặc định uppercase. `@Column(name = "my_column")` không match `MY_COLUMN` trong DB. Luôn UPPERCASE.
+
+5. **Oracle DATE có time** → `DATE` trong Oracle chứa cả time, khác MySQL. Dùng `TIMESTAMP` cho full datetime.
+
+6. **Pagination với native query** → `LIMIT/OFFSET` không hoạt động trong Oracle 11g. Dùng `ROWNUM` hoặc Oracle 12c+ `FETCH FIRST`.
+
+7. **CLOB vs String** → Oracle VARCHAR2 max 4000 bytes. Text dài hơn phải dùng CLOB + `@Lob`.
+
+## Oracle Naming Conventions
+
+```
+Table:    UPPER_SNAKE_CASE  — WALLET_TRANSACTION, CUSTOMER_INFOS
+Column:   UPPER_SNAKE_CASE  — CUSTOMER_ID, CREATED_DATE, AUTOID
+Sequence: {TABLE_NAME}_SEQ  — WALLET_TRANSACTION_SEQ
+Index:    IDX_{TABLE}_{COL} — IDX_WALLET_TRANS_CUST_ID
+PK:       AUTOID (Long)
+```
+
+## JPA Entity Template
+
+PASS: Complete entity with Oracle conventions:
+```java
+@Builder @AllArgsConstructor @NoArgsConstructor @Getter @Setter
+@Entity(name = "TABLE_NAME")
+public class EntityName {
+
+    // Primary Key — Oracle Sequence (allocationSize = 1 là BẮT BUỘC)
+    @Id
+    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "TABLE_NAME_SEQ")
+    @SequenceGenerator(name = "TABLE_NAME_SEQ", allocationSize = 1)
+    @Column(name = "AUTOID")
+    private Long id;
+
+## Native Query Patterns
+
+PASS: Parameterized native query — LUÔN LUÔN dùng `:param`:
+```java
+@Query(nativeQuery = true, value =
+    "SELECT t.* FROM WALLET_TRANSACTION t " +
+    "WHERE t.CUSTOMER_ID = :customerId " +
+    "AND t.STATUS = :status " +
+    "AND t.CREATED_DATE BETWEEN :fromDate AND :toDate " +
+    "ORDER BY t.CREATED_DATE DESC")
+List findByFilter(
+    @Param("customerId") Long customerId,
+    @Param("status") String status,
+    @Param("fromDate") Date fromDate,
+    @Param("toDate") Date toDate);
+
+## View Entity (Read-Only)
+
+```java
+// Entity không có sequence, không có @Id tự sinh
+@Immutable
+@Entity(name = "V_CUSTOMER_WALLET")  // Oracle View
+@Getter
+public class VCustomerWallet {
+    @Id  // dùng cột unique của view
+    @Column(name = "CUSTOMER_ID")
+    private Long customerId;
+
+    @Column(name = "WALLET_BALANCE")
+    private BigDecimal walletBalance;
+    // ...
+}
+```
+
+## Stored Procedure Integration
+
+```java
+// VETC pattern: RepositoryServiceBase.callStoresProcedure
+List results = repositoryServiceBase.callStoresProcedure(
+    "PROC_NAME",
+    List.of(
+        new ParameterDto("p_customer_id", customerId, ParameterType.IN),
+        new ParameterDto("p_status", status, ParameterType.IN)
+    ),
+    Result.class
+);
+```

package/skills/vetc-performance-testing/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: vetc-performance-testing
+description: PROACTIVELY activate khi cần load/performance test cho API mới, regression test sau optimization, hoặc capacity planning. k6/JMeter integration, SLA thresholds, VETC-specific scenarios (transfer/reconcile/OTP).
+---
+
+# VETC Performance Testing — Load & Stress Validation
+
+Viết và chạy performance tests cho VETC APIs với k6 (default) hoặc JMeter. Đảm bảo p95/p99 latency, throughput, error rate đạt SLA trước production.
+
+## When to Activate
+
+- API mới cần load test trước go-live (SLA validation)
+- Regression test sau performance optimization
+- Capacity planning — xác định breakpoint (max RPS, CPU/memory ceiling)
+- Suspect hot path issue — transfer/reconcile/eKYC endpoints
+- Pre-release smoke performance check
+- Baseline vs release comparison (p95 shift > 20% → investigate)
+
+## Do NOT Activate When
+
+- Code chưa merge — không load test on dev branch (noise)
+- Không có staging environment — performance test trên prod = bad idea
+- Không có rõ SLA target — đo gì để so sánh?
+- Unit/integration test thất bại — fix correctness trước performance
+
+## Core Concepts
+
+### SLA Thresholds (VETC default)
+
+| Tier | Endpoint Type | p95 Target | p99 Target | Error Rate |
+|------|---------------|-----------|-----------|------------|
+| **Tier 0 (critical)** | Payment/Transfer | < 300ms | < 800ms | < 0.1% |
+| **Tier 1 (core)** | Balance/OTP/KYC | < 500ms | < 1500ms | < 0.5% |
+| **Tier 2 (support)** | Report/Query | < 1500ms | < 3000ms | < 1% |
+| **Batch** | Reconcile/Settlement | < 30min/batch | N/A | < 0.5% |
+
+### Load Profiles
+
+- **Smoke**: 1 VU × 1 minute — sanity check
+- **Average**: 50 VU × 15 minutes — typical load
+- **Stress**: ramp 0 → 500 VU × 30 minutes — find breakpoint
+- **Spike**: 10 → 200 VU × 30s, hold 3 min, drop back — burst handling
+- **Soak**: 100 VU × 2 hours — memory leak / connection pool exhaustion
+
+## k6 Template Structure
+
+```
+perf-tests/
+├── config/
+│   ├── env.dev.json
+│   ├── env.staging.json
+│   └── thresholds.js
+├── scenarios/
+│   ├── transfer-smoke.js
+│   ├── transfer-load.js
+│   ├── reconcile-batch.js
+│   └── otp-spike.js
+├── helpers/
+│   ├── auth.js           (Keycloak token fetcher)
+
+## Core k6 Template — Transfer Load Test
+
+```javascript
+import http from 'k6/http';
+import { check, sleep } from 'k6';
+import { Rate, Trend } from 'k6/metrics';
+import { getToken } from '../helpers/auth.js';
+import { randomTransferRequest } from '../helpers/data-generator.js';
+
+// Custom metrics
+const transferSuccessRate = new Rate('transfer_success');
+const transferDuration = new Trend('transfer_duration', true);
+
+export const options = {
+  scenarios: {
+
+## Helpers — Auth & Data Generator
+
+```javascript
+// helpers/auth.js
+import http from 'k6/http';
+export function getToken(username, password) {
+  const res = http.post(
+    `${__ENV.KEYCLOAK_URL}/realms/vetc/protocol/openid-connect/token`,
+    {
+      grant_type: 'password',
+      client_id: 'vetc-perf-test',
+      username: username,
+      password: password,
+    }
+  );
+
+## Workflow
+
+### Step 1 — Define SLA
+
+```
+Endpoint: POST /wallet/v1/transfer
+Target SLA:
+  - p95 < 300ms (Tier 0)
+  - p99 < 800ms
+  - Error rate < 0.1%
+
+

package/skills/vetc-pr-response/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: vetc-pr-response
+description: PROACTIVELY activate khi nhận review comments trên PR — classify từng comment (fix/defer/reject), craft response thoughtfully, không agree mù quáng. Pair với vetc-receiving-review cho quy trình nhận phê bình.
+---
+
+# VETC PR Response — Thoughtful Review Handling
+
+Khi reviewer để lại comments trên PR, không rush fix-all. Classify từng comment trước: fix ngay, defer sang issue mới, hay respectfully reject với lý do.
+
+## When to Activate
+
+- PR có review comments cần process
+- Multiple reviewers disagree — cần cân nhắc
+- Reviewer blocking PR — cần hoặc fix hoặc justify
+- Long review thread — cần sắp xếp + respond có cấu trúc
+- After `vetc-receiving-review` — áp dụng nguyên tắc vào thực hành
+
+## Do NOT Activate When
+
+- No comments yet — không có gì để respond
+- Single typo fix comment — just fix and push
+- Self-review comments — rewrite before requesting review
+
+## Classification Matrix
+
+Mỗi comment classify thành 1 trong 5 loại:
+
+| Loại | Khi nào | Action | Response Template |
+|------|---------|--------|-------------------|
+| **FIX-NOW** | Correct, critical, in scope | Fix in this PR | "Good catch, fixed in {commit-sha}" |
+| **FIX-IN-FOLLOWUP** | Correct but scope-creep | Log issue, fix later | "Valid — created VETC-999 for follow-up" |
+| **DEFER** | Valid but low priority | Add to tech-debt | "Noted — added to tech-debt/issues/TD-42" |
+| **DISCUSS** | Unclear intent, ambiguous | Ask back | "Can you elaborate on {specific part}? I want to ensure I understand before changing." |
+| **REJECT** | Disagree with evidence | Politely push back | "I disagree because {data/pattern/evidence}. Happy to discuss further." |
+
+## Core Principles
+
+### 1. Never Agree Blindly
+
+If comment is unclear → ask. If you disagree → push back respectfully. Agreeing just to close PR = bad engineering. Code should be right, not popular.
+
+### 2. Separate Signal from Noise
+
+- **Nitpicks** (formatting, naming preference) → evaluate: does it improve readability?
+- **Style** (subjective) → defer to team style guide; if unwritten, ask for vote
+- **Correctness** (bug, edge case, security) → always address
+- **Architecture** (major refactor suggestion) → usually FIX-IN-FOLLOWUP, not this PR
+
+### 3. Scope Discipline
+
+This PR = this feature. Drive-by refactor suggestions → separate PR. Politely decline:
+
+> "Agreed this could be improved — but it's out of scope for VETC-123 (Smart OTP).
+>  I've created VETC-999 to track the refactor. Can we keep this PR focused?"
+
+### 4. Evidence Over Authority
+
+When reviewer says "just do X" without reasoning, ask why. Senior title ≠ automatic correctness.
+
+> "Can you share the pattern/doc this is based on? I implemented based on {reference}
+>  and want to make sure we're aligned on the reasoning."
+
+### 5. Batch Small Fixes
+
+Don't push 20 commits each addressing 1 nit. Batch into 1-2 commits:
+- `fix(review): address nits in WalletController`
+- `refactor(review): rename per feedback`
+
+## Workflow
+
+### Step 1 — Read ALL Comments First
+
+Before replying to any, read entire review thread. Understand big picture — maybe comments conflict, or reviewer has overarching concern.
+
+### Step 2 — Classify Each Comment
+
+Create local checklist (not committed):
+
+```markdown
+# PR #123 Review Triage
+
+## Reviewer: @alice (2026-04-17)
+
+### Comment 1: Line 45 - "Extract this to private method"
+Classification: FIX-NOW
+Reason: Method is 30 lines, extraction improves readability
+
+### Comment 2: Line 78 - "Why not use Stream.reduce?"
+Classification: REJECT
+Reason: Stream.reduce on 1M elements = slower than for-loop (benchmarked)
+Response: "Good question — I benchmarked both. For-loop is 3x faster at our scale.
+           Saved benchmark results in `bench/loop-vs-reduce.md`"
+
+### Comment 3: Line 120 - "Consider caching this"
+Classification: FIX-IN-FOLLOWUP
+Reason: Valid perf improvement but requires Redis setup config change
+Response: "Great idea — out of scope for this PR. Created VETC-999."
+
+### Comment 4: Line 200 - "Missing null check"
+Classification: FIX-NOW
+Reason: Real bug, caught before production
+
+### Comment 5: "General: prefer functional style"
+Classification: DISCUSS
+Response: "Can you point to specific lines? Happy to refactor toward the team's style."
+```

package/skills/vetc-ralph/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: vetc-ralph
+description: PROACTIVELY activate khi đã có approved plan từ vetc-ralplan và cần implement đến HOÀN THÀNH. Persistence loop không stop cho đến khi build pass + tests pass + coverage đạt + không OWASP HIGH.
+---
+
+# VETC Ralph — Persistence Loop
+
+Implement và không dừng cho đến khi task thực sự xong: build pass, test pass, coverage đạt, security clean.
+
+## When to Activate
+
+- Đã có approved plan (từ `vetc-ralplan` hoặc `06-task-breakdown.md`)
+- Muốn AI tự implement từng task, verify sau mỗi task, không cần confirm mỗi bước nhỏ
+- Task đủ rõ để execute (có file path, task breakdown, acceptance criteria)
+- User nói: "ralph", "cứ làm đến xong", "đừng dừng", "finish this", "keep going"
+
+## Do NOT activate when
+
+- Plan chưa có / chưa approved → dùng `vetc-ralplan` trước
+- Requirement còn mơ hồ → dùng `vetc-deep-interview` trước
+- User muốn manual control từng bước → dùng `vetc-analyze-ba` (có gates)
+- Chỉ cần implement 1 file đơn giản → implement trực tiếp
+
+## Do NOT Activate When
+
+- Task quá nhỏ, chỉ cần thay đổi < 3 files (implement trực tiếp)
+- Chỉ cần code review, không implement (dùng reviewer agents)
+- User chưa confirm plan — chưa có approved task breakdown
+
+## Bypass
+
+Prefix `force:` để bypass gate: `force: ralph implement XxxService`
+
+## Ralph Loop
+
+```
+[Pre-context Intake]
+    ↓
+[Task Breakdown] (từ plan đã approved)
+    ↓
+┌─────────────────────────────────────────────────┐
+│  RALPH WAVE EXECUTION                           │
+│                                                 │
+│  Wave 1: [T1, T2, T3] ← independent, PARALLEL  │
+│    Each task gets fresh focused context          │
+│    Build + Test + Coverage per task              │
+│                                                 │
+│  Wave 2: [T4, T5] ← depends on Wave 1          │
+
+## Phase 0 — Pre-context Intake (bắt buộc)
+
+Trước khi bắt đầu loop:
+
+1. **Tạo Story Packet** cho mỗi task (từ `templates/story-packet.md`):
+   - Lite lane: skip story packet, trực tiếp implement
+   - Standard lane: tạo story packet với status, lane, acceptance criteria, validation plan
+   - Full lane: tạo high-risk story folder (`templates/high-risk-story/`) với overview + execplan + design + validation
+2. Load hoặc tạo context snapshot:
+
+1. Load hoặc tạo context snapshot:
+   ```
+   specs/features/{feature}/ralph-context.md
+   ├── Task statement
+   ├── Approved plan path
+
+## Wave Execution
+
+Tasks được group thành waves dựa trên dependencies:
+
+**Wave grouping rules:**
+- Tasks KHÔNG phụ thuộc nhau → cùng wave (parallel)
+- Tasks phụ thuộc task ở wave trước → wave tiếp theo (sequential)
+- Mỗi wave chạy độc lập, kết quả được verify trước khi sang wave tiếp
+
+```
+Wave 1: [Entity] [Repository] [DTO]          ← independent, PARALLEL
+Wave 2: [Service]                             ← depends on Wave 1
+Wave 3: [Controller]                          ← depends on Wave 2
+Wave 4: [Unit Tests] [Integration Tests]      ← depends on Wave 3, PARALLEL
+```
+
+## Task Format
+
+See: `./(see docs)`
+
+## Per-Task Implementation Loop
+
+See: `./(see docs)` (7 bước: Build → Test → Coverage → Security → Health Check → Context → Progress Update)
+
+### Per-Task Test Matrix Update
+
+Sau mỗi task complete, cập nhật `docs/TEST_MATRIX.md` (tạo từ `templates/test-matrix.md` nếu chưa có):
+
+1. Thêm/update row cho task với task ID + spec section
+2. Set Status = "in_progress" khi bắt đầu task
+3. Sau build pass → fill Build column = yes
+4. Sau test pass → fill Unit/Integration columns = yes
+5. Sau security scan → fill Security column = yes
+6. Task DONE → set Status = "implemented", fill Evidence
+
+## Parallel Execution
+
+Task **độc lập** → run parallel:
+```
+Tốt: Entity + Repository + DTO (không phụ thuộc nhau)
+Tốt: Test viết song song với Service implementation
+Xấu: Service trước Controller (Controller phụ thuộc Service)
+```

package/skills/vetc-ralplan/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: vetc-ralplan
+description: PROACTIVELY activate khi có spec rõ nhưng cần review plan trước khi code, hoặc sau vetc-deep-interview. Planner + Architect + Critic consensus review. Đảm bảo plan được review từ nhiều góc.
+---
+
+# VETC Ralplan — Consensus Planning
+
+Review và approve plan trước khi implement. Planner + Architect + Critic đồng thuận → implementation bắt đầu.
+
+## When to Activate
+
+- Có spec hoặc requirement rõ, cần plan trước khi code
+- Task phức tạp: nhiều module, nhiều layer (Controller/Service/Repository/FE)
+- Thay đổi ảnh hưởng Oracle schema, ACS integration, security
+- Sau `vetc-deep-interview` — có spec, cần plan
+- User nói: "lên kế hoạch trước", "review plan", "ralplan", "plan trước khi làm"
+
+## Do NOT activate when
+
+- Đã có `06-task-breakdown.md` rõ ràng → implement ngay với `vetc-analyze-ba`
+- Task nhỏ (1 file, 1 function) → dùng `vetc-planner` agent hoặc implement trực tiếp
+- User muốn quick path → `vetc-spec-driven` → `vetc-api-design` → `vetc-planner`
+
+## Implementation Readiness Gate (từ BMAD)
+
+Trước khi approve plan, verify TẤT CẢ artifacts đã aligned:
+
+| Check | What to Verify | Block? |
+|-------|---------------|--------|
+| Spec completeness | All user scenarios (US-*) covered? Edge cases identified? | YES if CRITICAL gap |
+| API design aligned | Plan references correct endpoints from api-design.md? | YES if mismatch |
+| Data model consistent | Entity fields match spec requirements? | YES if conflict |
+| Security accounted | PII handling specified? Auth requirements listed? | YES if missing |
+| Test plan exists | Unit + integration scope defined per task? | WARN if missing |
+| Non-goals explicit | "X nằm ngoài scope" documented? | WARN if vague |
+
+**Readiness verdict:**
+- `READY` — all checks pass, proceed to consensus planning
+- `CONDITIONAL` — WARN items need acknowledgment before proceeding
+- `NOT READY` — block, return to spec/design phase to fill gaps
+
+## Pre-Execution Gate
+
+**Ralplan chặn các requests vague trước khi vào implementation:**
+
+| Tín hiệu PASS (đủ cụ thể) | Tín hiệu cần ralplan |
+|---------------------------|---------------------|
+| "Fix NullPointerException trong WalletService.java:45" | "Fix lỗi transfer" |
+| "Implement API POST /wallet/transfer theo spec" | "Thêm chức năng transfer" |
+| "Task list: 1. Entity 2. Repository 3. Service 4. Controller" | "Làm tính năng nạp tiền" |
+| Có file path, function name, issue number cụ thể | Không có anchor cụ thể |
+
+**Bypass gate:** prefix `force:` hoặc `!` trước prompt.
+
+## Consensus Planning Workflow
+
+### Step 1 — Planner: Draft Plan
+
+Tạo Implementation Plan gồm:
+
+# PLAN: {Feature Name}
+
+## Summary (1 câu)
+
+## VETC-DR Analysis
+### Principles (3-5)
+- [P1] Spec-First: không code khi chưa có spec
+- [P2] Oracle-Safe: parameterized queries only
+- [P3] Security: không log PII, JWT validate đúng
+- ...
+
+### Decision Drivers (top 3)
+- [D1] ...
+- [D2] ...
+- [D3] ...
+
+### Viable Options (>= 2)
+| Option | Pros | Cons | Risk |
+|--------|------|------|------|
+| A | ... | ... | ... |
+| B | ... | ... | ... |
+
+### Recommended Option
+[Option X] — vì [reason aligned với Drivers]
+
+## Implementation Plan
+
+### Phase 1: Database Layer
+- [ ] SQL Migration: CREATE TABLE / ALTER TABLE
+- [ ] JPA Entity: `src/.../entity/Xxx.java`
+- [ ] Repository: `src/.../repository/XxxRepository.java`
+
+### Phase 2: Business Layer
+- [ ] Service interface: `XxxService.java`
+- [ ] Implementation: `XxxServiceImpl.java` (với @Transactional)
+
+### Phase 3: API Layer
+- [ ] Controller: `XxxController.java` (extends ControllerBase)
+- [ ] DTOs: `XxxRequest.java`, `XxxResponse.java`
+
+### Phase 4: Tests
+- [ ] Unit: `XxxServiceImplTest.java`
+- [ ] Integration: `XxxControllerTest.java`
+
+### Phase 5: Frontend (nếu có)
+- [ ] API module: `src/api/xxxApi.ts`
+- [ ] Component/Page
+
+## Risk Assessment
+| Risk | Probability | Impact | Mitigation |
+|------|-------------|--------|------------|
+| Oracle sequence gap | LOW | LOW | allocationSize=1 |
+| ACS timeout | MEDIUM | HIGH | try-catch + ErrorCode |
+| ... | | | |
+
+

package/skills/vetc-receiving-review/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: vetc-receiving-review
+description: PROACTIVELY activate khi nhận code review feedback từ human reviewer, sau khi vetc-java-reviewer hoặc vetc-typescript-reviewer report findings, hoặc khi cần process review comments. Hướng dẫn cách nhận review đúng — không đồng ý mù quáng.
+---
+
+# VETC Receiving Code Review — How to Handle Feedback Correctly
+
+Nhận code review đúng cách. Không đồng ý performative. Verify trước khi implement. Push back khi cần.
+
+## When to Activate
+
+- Nhận review feedback từ human (PR comments, direct feedback)
+- Sau khi `vetc-java-reviewer` hoặc `vetc-typescript-reviewer` report findings
+- Sau khi `vetc-security-reviewer` report security issues
+- User nói: "review xong rồi", "fix theo feedback", "xử lý review comments"
+
+## Do NOT Activate When
+
+- Đang viết code mới (không phải xử lý feedback) → dùng skill phù hợp
+- Review feedback chỉ là style/formatting nhỏ → fix trực tiếp
+- Chưa có review findings nào → chưa cần skill này
+- Đang làm code review cho người khác → dùng `vetc-review` command
+
+## Forbidden Responses
+
+These responses indicate you are NOT properly processing feedback:
+
+| Forbidden Response | Why It's Forbidden |
+|-------------------|-------------------|
+| "You're absolutely right!" | Performative agreement without understanding |
+| "Good catch! Fixed." | Did you actually verify the fix addresses the root issue? |
+| "Makes sense, changed." | "Makes sense" ≠ "I verified this is correct" |
+| "Done!" without explanation | What did you change? Why? Does it work? |
+| Implementing every suggestion blindly | Not all suggestions are correct or necessary |
+| "I'll add that feature too" | Scope creep. Address the review, don't expand it. |
+
+## Review Processing Workflow
+
+### Step 1: Classify Each Finding
+
+From reviewer output, classify each finding:
+
+| Category | Action | Examples |
+|----------|--------|---------|
+| **Bug/Defect** | Fix immediately | Logic error, wrong condition, missing null check |
+| **Security Issue** | Fix immediately, highest priority | SQL injection, sensitive data in log, missing auth check |
+| **Design Problem** | Discuss before fixing | Wrong abstraction, missing error handling pattern |
+| **Style/Naming** | Fix if trivial, discuss if contentious | Variable naming, method naming |
+| **Suggestion** | Evaluate with YAGNI check | "What if we add...", "Could also handle..." |
+| **Question** | Answer with evidence | "Why this approach?" — show alternatives considered |
+
+### Step 2: YAGNI Check
+
+For each suggestion, ask:
+
+```
+Does this suggestion:
+1. Fix a REAL problem that exists NOW?     → Implement
+2. Prevent a LIKELY problem?               → Consider
+3. Handle a HYPOTHETICAL future scenario?   → Skip (YAGNI)
+4. Add complexity without clear benefit?    → Push back
+```
+
+### Step 3: Verify Before Implementing
+
+Before implementing any feedback:
+
+1. **Read the finding carefully** — understand the reviewer's reasoning
+2. **Check the code** — is the reviewer's observation accurate?
+3. **Consider alternatives** — is the suggested fix the best approach?
+4. **Check for ripple effects** — will this fix break something else?
+
+### Step 4: Implement or Push Back
+
+#### When to Implement
+
+- Finding is factually correct
+- The fix is straightforward
+- No design tradeoffs involved
+
+Format your response:
+```markdown
+**Finding:** {quote the finding}
+**Analysis:** {why it's correct}
+**Fix:** {what you changed}
+**Verification:** {test that confirms the fix}
+```
+
+## Source-Specific Handling
+
+### Human Reviewer Feedback
+
+- Prioritize: Critical bugs > Security > Design > Style > Suggestions
+- Ask clarifying questions if the feedback is ambiguous
+- Don't assume the reviewer knows the full context — explain your reasoning
+
+### VETC Reviewer Agent Output
+
+Agent reviewers (`vetc-java-reviewer`, `vetc-typescript-reviewer`, `vetc-security-reviewer`) produce structured findings:
+
+```markdown
+## Finding: [CRITICAL|HIGH|MEDIUM|LOW] {title}
+**File:** {path}:{line}
+**Issue:** {description}
+**Suggestion:** {how to fix}
+```