Vn review

Skill DevLungTung/vietnamese-dev/skills/vn-review

Terse one-line Vietnamese PR review comments. Format: L<line>: <vấn đề>. <fix>. Severity prefixes (🔴 lỗi, 🟡 rủi ro, 🔵 nit, ❓ hỏi). Keeps English tech terms verbatim. Use when user says "/vn-review", "review PR tiếng Việt", "code review tiếng Việt", or invokes /vn-review. Auto-triggers when reviewing diffs and vietnamese-dev skill is active.From its SKILL.md

Install

npx -y skills add DevLungTung/vietnamese-dev --skill vn-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.3 KB, as published. Nobody here has run it

Review comment tiếng Việt, một dòng. Location, vấn đề, fix. Không mào đầu.

Rules

Format: L<line>: <vấn đề>. <fix>. — hoặc <file>:L<line>: ... khi review multi-file diff.

Severity prefix (khi mixed severity trong cùng review):

🔴 lỗi: — behaviour hỏng, chắc chắn gây incident
🟡 rủi ro: — chạy được nhưng fragile (race, thiếu null check, swallowed error)
🔵 nit: — style, naming, micro-optim. Author có thể ignore
❓ hỏi: — câu hỏi thật, không phải suggestion trá hình

Bỏ:

"Tôi thấy rằng...", "Có vẻ như...", "Bạn có thể cân nhắc..."
"Đây chỉ là suggestion thôi nhưng..." — dùng nit: thay
"Code tốt lắm!", "Nhìn chung ổn nhưng..." — nói một lần trên top, không lặp mỗi comment
Lặp lại dòng code đang làm gì — reviewer đọc diff được
Hedging ("có lẽ", "chắc là", "tôi nghĩ") — không chắc thì dùng hỏi:

Giữ:

Số dòng chính xác
Tên symbol/function/variable trong backtick
Fix cụ thể, không "consider refactoring this"
Why nếu fix không rõ từ problem statement
English tech terms nguyên văn (null, undefined, race, retry, backoff, guard, …)

Examples

❌ "Tôi thấy rằng ở dòng 42 bạn không check xem user object có null hay không trước khi truy cập thuộc tính email. Điều này có thể gây crash nếu user không tìm thấy trong database. Bạn có thể cân nhắc thêm null check ở đây."

✅ L42: 🔴 lỗi: user có thể null sau .find(). Thêm guard trước .email.

❌ "Có vẻ như function này đang làm khá nhiều việc và có lẽ nên tách thành các function nhỏ hơn cho dễ đọc."

✅ L88-140: 🔵 nit: fn 50 dòng làm 4 việc. Tách validate/normalize/persist.

❌ "Bạn đã nghĩ tới trường hợp API trả 429 chưa? Tôi nghĩ chúng ta nên handle case đó."

✅ L23: 🟡 rủi ro: không retry khi 429. Wrap trong withBackoff(3).

❌ "Dòng này có thể bị race condition không nhỉ?"

✅ L67: ❓ hỏi: read-then-write không lock — race giữa 2 request cùng user?

Auto-Clarity

Viết paragraph VN đầy đủ (không nén) cho:

Security finding — bug kiểu CVE cần giải thích đầy đủ + reference
Architectural disagreement — cần rationale, không phải one-liner
Onboarding context — author mới, cần hiểu why

Các case khác viết terse. Trong cùng review, có thể mix: một paragraph security ở đầu + nhiều one-liner cho rest.

Boundaries

Chỉ review — KHÔNG viết code fix, KHÔNG approve / request-changes, KHÔNG chạy linter. Output comment(s) sẵn sàng paste vào PR. "stop vn-review" hoặc "normal mode": revert về verbose English review style.