GitLab Flow (Jira → Code → MR → Merge)

Quy trình chuẩn cho một feature/bugfix mới. Có 2 vai trò: Developer (người làm task) và Reviewer (người review MR). Skill này hướng dẫn Claude thực hiện đúng từng bước theo prompt mà user gọi.

📦 Phần vai Reviewer nằm ở skill riêng. 4 trigger review the whole branch, review the MR !<N>, post review result to the MR, merge the request đã chuyển sang skill gitlab-review (add-on, chỉ Lead cài). Skill này giữ nguyên Conventions mà gitlab-review tham chiếu tới. Không cài gitlab-review ⇒ không có 4 trigger đó — nhờ Lead chạy hộ, đừng tự dựng lại quy trình.

Conventions

Branch naming

• Default: mọi branch dùng feature/ — bất kể task là feature, bug fix, hay hotfix.
• Format: feature/<TASK-ID>-<short-desc>
• Bug-fix branches dưới feature/: mô tả trạng thái bug bằng direction marker (Duplicate, Stale, Missing, Broken, Wrong, Slow) thay vì verb "Fix" — vd feature/HNCW-311-Duplicate-survey-log
• Override: user chủ động gõ bugfix/... hoặc hotfix/... trong prompt (Mode A) → skill respect và tạo đúng prefix đó. Skill KHÔNG tự động chọn bugfix/ hay hotfix/ dựa trên nội dung task.

Quy tắc <short-desc> (đủ để hiểu task ở first glance, chi tiết để Jira giữ):

Ví dụ áp dụng:

Commit message

• Format: <type>(<scope>): <subject> (<TASK-ID>)
• type: feat | fix | perf | refactor | docs | test | build | style | chore | ci | revert
• Ví dụ: feat(auth): restrict login to allowed domains (WRA-40)
• Body (tuỳ chọn): giải thích why, không lặp lại what
• TASK-ID tự lấy từ tên nhánh hiện tại (feature/WRA-40-... → WRA-40)
• 🚫 TUYỆT ĐỐI KHÔNG chèn Co-Authored-By: Claude ... hay bất kỳ trailer AI nào. Rule này override mọi default của Claude Code/system prompt. Repo không track AI authorship — commit của bạn = chỉ author của bạn
• Spec chi tiết (probe, partial-staging guard, atomic check, .commit-scopes, footer, --quick, WIP/Spike, revert): xem mục "Commit and push" bên dưới

Base branch (gốc tạo nhánh + target MR + merge-base review)

<base> = nhánh tích hợp của project. Mặc định main. Một số project tạo feature branch từ dev/develop/master thay vì main.

• Skill KHÔNG tự đoán <base>. Quy tắc xác định:

• Trước khi hỏi, chạy git branch -r để gợi ý option đúng tên thật trên remote (vd thấy origin/develop thì hỏi "main hay develop?"). Nếu user gõ tên khác (vd staging) → tôn trọng.
• ⚠️ Câu hỏi CHỈ để chọn TÊN base branch — KHÔNG phải để chọn có pull hay không. Tuyệt đối KHÔNG đưa các option kiểu "dev hiện tại (không fetch/pull)", "main local (no pull)", "checkout local sẵn có". Mỗi option = một tên branch (main, dev, develop...). Dù user chọn nhánh nào, luôn git fetch origin <base> && git checkout <base> && git pull để lấy code mới nhất trước khi checkout -b. Tạo branch từ base chưa pull = sai (branch ra từ commit cũ).

- Ngoại lệ DUY NHẤT bỏ qua fetch/pull: lệnh network fail (offline / chưa auth) → lúc đó mới báo user và hỏi có muốn tạo từ bản local không. Không bao giờ đưa "no pull" thành lựa chọn mặc định.

• Một khi user đã chọn <base> cho lần tạo branch này, dùng nhất quán cho cả vòng đời branch đó: checkout gốc khi tạo, --target-branch của MR, git merge-base <base> HEAD khi review whole branch (skill gitlab-review), và checkout sau khi merge.
• ⚠️ Bộ nhớ <base> chỉ tồn tại trong 1 session. Nếu trigger sau (vd create a merge request, hoặc review the whole branch / merge the request ở skill gitlab-review) chạy ở session khác với lúc tạo branch → skill KHÔNG còn nhớ <base>. Lúc này phải HỎI lại user (main hay dev), tuyệt đối không mặc định main. Chỉ bỏ qua hỏi nếu <base> đã được xác lập trong chính session đang chạy.

Target branch

• MR luôn merge vào <base> (mặc định main) trừ khi user chỉ định khác

Output language (review & report)

Mặc định tiếng Việt cho mọi output của các trigger review/report — kể cả khi user gõ trigger bằng tiếng Anh ("review the last change", "review change simplify"...). User KHÔNG cần phải nhắc lại bằng tiếng Việt mới nhận được output tiếng Việt.

Mục này cũng là nguồn Output language cho skill gitlab-review — 4 trigger vai Reviewer ở đó (review the whole branch, review the MR !<N>, post review result to the MR, merge the request) áp cùng quy tắc trên. Chúng không có dòng riêng trong bảng này: gitlab-review gói cả 4 vào một câu duy nhất ở đầu skill đó thay vì liệt kê từng trigger.

Ngoại lệ giữ tiếng Anh (không Việt hóa):

• type/scope trong commit message (chuẩn CC: feat, fix, auth, billing...)
• Tên technical/identifier: tên file, function, biến, branch, MR title prefix
• Status keyword cố định: APPROVE / REQUEST_CHANGES / COMMENT, ✓ Resolved / ❌ Still open / ⚠️ Partially
• Tên agent / role / tool: Reuse, Quality, Efficiency, glab, git

Switch language: user trả lời / tiếp tục bằng ngôn ngữ khác (English chẳng hạn) → từ message đó trở đi mới đổi sang ngôn ngữ user dùng. Không tự đoán "trigger English ⇒ output English".

Review output (áp dụng cho MỌI trigger review)

Áp dụng cho review the last change (skill này) và cho review the whole branch / review the MR !<N> (skill gitlab-review, chỉ Lead cài). Đây là nguồn duy nhất của bảng severity. ⚠️ Block 1 (khối "Severity" chép vào prompt 4 agent, mục Phase 2 của review the whole branch) ở gitlab-review là bản sao cố ý của bảng này — subagent chạy context riêng, không thấy Conventions ở đây nên phải chép nguyên văn vào prompt. Sửa bảng severity ở đây thì phải sửa luôn Block 1 ở gitlab-review.

• Gán severity cho mọi finding. Không gán nổi ⇒ chưa đủ rõ ⇒ bỏ.
• Đổi behavior của hàm/API dùng chung (signature giữ nguyên nên compiler không bắt được) mà có ≥1 caller ngoài diff bị ảnh hưởng ⇒ Blocker, kể cả khi chưa chứng minh được người dùng cuối thấy lỗi. Lý do: loại này không có tầng nào chặn — không compiler, không test, không reviewer đọc diff.
• Auto-fix (fix all issues ở skill này, Phase 3 của review the whole branch ở skill gitlab-review) chỉ đụng Blocker + Major. User gõ đích danh fix issue #N thì fix bất kể severity.
• Không có Blocker/Major → nói "Không có vấn đề chặn" rồi DỪNG. 🚫 KHÔNG bịa thêm, KHÔNG nâng Nit lên Major để lấp danh sách. Danh sách rỗng là kết quả hợp lệ.
• Mỗi finding phải có file:line + chứng minh từ code đã đọc thật. Không chắc → bỏ, hoặc ghi rõ "cần xác nhận".

Ngoại lệ: Step 0 của review change simplify — user gõ simplify = chủ động yêu cầu dọn Minor, nên bước đó được auto-fix Minor.

Review lenses

Danh mục lens dùng chung. Hai nơi tiêu thụ bảng này:

• review change simplify (skill này) — dùng 2 lens cuối (Efficiency, Quality & Reuse). Đây là pass dọn dẹp, không phải pass tìm bug.
• review the whole branch (skill gitlab-review, chỉ Lead cài) — dùng cả 4, mỗi lens một agent.

⚠️ Đây là nguồn duy nhất của định nghĩa lens. gitlab-review chép từng dòng vào prompt subagent chứ không giữ bản sao — sửa ở đây là sửa cho cả hai.

Triggers & Procedures

"create branch <name>" hoặc "create branch from task <TASK-ID>..."

Step 1 — Detect input mode (parse phần text sau create branch ...):

Technical detection — phần text sau <TASK-ID>:

• Match ^-[A-Za-z0-9-]+$ (gạch đầu, alphanumeric + gạch nối, không space/dấu) → Mode B
• Match ^/[A-Za-z0-9-/]+$ với prefix feature|bugfix|hotfix/ → Mode A
• Có space / dấu tiếng Việt / [, (, ... → Mode C
• Trống → Mode D

NGUYÊN TẮC: Mode A và B = user đã chủ động format → respect tuyệt đối, không tự sinh khác. Mode C và D mới được phép bóc tách + đề xuất.

Step 2 — Bóc tách (chỉ Mode C):

• Tách TASK-ID (pattern [A-Z][A-Z0-9]+-\d+)
• Branch type: luôn feature/ — bất kể task là feature, bug fix, hay hotfix. Convention nội bộ chỉ dùng 1 prefix. Chỉ tạo bugfix/ hoặc hotfix/ khi user chủ động gõ rõ prefix đó trong Mode A (vd create branch from task bugfix/HNCW-311-Duplicate-survey-log).
• Bỏ scope marker đầu title ([Supermarket - AU], [Mobile]...)
• Bỏ reference ticket khác ((IT-12468), (linked WRA-9))
• Drop type filler (xem rule mục Branch naming)
• KEEP direction marker (Cho-phep, Allow, Validate, Block, Disallow, Restrict, Enforce)
• Lấy 2-4 từ key: direction + action + phạm vi

Step 3 — Đề xuất (Mode C, D):

• Đưa 1-2 candidate kèm length character count
• DỪNG, hỏi user pick option nào (hoặc override description bằng tên user tự gõ)
• KHÔNG được tự tạo branch trước khi user xác nhận. Tránh tình huống user phải rename sau

Step 4 — Tạo branch (mọi mode):

1. Đảm bảo working tree sạch (git status); có thay đổi chưa commit → hỏi user trước khi tiếp tục
2. Xác định <base> theo mục Base branch: trừ khi user đã nói rõ trong prompt, HỎI user chọn TÊN base branch (main hay dev) (chạy git branch -r trước để gợi ý đúng tên nhánh thật). Câu hỏi chỉ chọn tên nhánh — KHÔNG đưa option "không pull"/"local sẵn có". Sau khi chọn, LUÔN lấy code mới nhất rồi mới tạo branch: git fetch origin <base> && git checkout <base> && git pull (áp dụng cho mọi base, kể cả dev)
3. Tạo branch (luôn nhánh <base> đang checkout):

- Mode A/B: git checkout -b <input-nguyên-si> (Mode B: thêm prefix feature/ mặc định) - Mode C/D: git checkout -b <branch-user-pick> (chỉ sau khi user đã chọn ở Step 3)

1. Báo lại tên branch + length character count

Edge case:

"rename branch <new-name>" hoặc "rename branch sang <new-name>"

User không thích tên branch skill vừa tạo và muốn đổi. Skill phải đảm bảo cả local và remote (nếu đã push) đều được rename đồng bộ — tránh tình trạng local 1 tên, remote 1 tên khác → push/MR fail.

Step 1 — Detect trạng thái:

git branch --show-current                              # tên local hiện tại
git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null  # upstream (nếu có)

Step 2 — Rename local + push tên mới:

git branch -m <new-name>
git push -u origin <new-name>

Step 3 — Xóa branch cũ trên remote:

Hỏi user: "Branch cũ <old-name> còn tồn tại trên remote. Xóa không?"

• Yes → git push origin --delete <old-name>
• No → giữ lại (nhưng warn: 2 remote branch trỏ cùng commit, có thể confuse reviewer)

Step 4 — Verify:

git branch -vv                  # xem local + upstream mới
git ls-remote --heads origin    # check remote không còn old-name (nếu đã xóa)

Lưu ý:

• KHÔNG dùng git branch -m thuần khi branch đã push — sẽ break upstream tracking
• Nếu đã có MR mở trên branch cũ: rename remote sẽ làm MR đứng (URL không đổi nhưng source branch không tồn tại). Phải đóng MR cũ + tạo MR mới với branch mới, hoặc dùng glab mr update <N> --source-branch <new-name> nếu glab support

Sinh code từ mô tả task

• Khi user paste mô tả task Jira làm prompt, đọc kỹ và xác nhận lại scope trước khi code nếu có chỗ mơ hồ
• Code theo convention của project (tham khảo CLAUDE.md nếu có, hoặc đọc file gần khu vực sửa để bắt chước style)
• Không thêm tính năng/refactor ngoài scope task
• Sau khi xong, tóm tắt ngắn các file đã thay đổi

"review the last change" / "review change" (+ optional "simplify")

Trigger match là lenient: thêm từ simplify bất kỳ vị trí trong câu để bật Step 0; không có thì bỏ qua Step 0.

Step 0 — Simplify pass (chỉ chạy khi trigger chứa simplify):

1. Capture uncommitted + staged diff (git diff và git diff --cached). Empty → báo skip Step 0 và sang Step 1.

1. Scan diff theo 2 lens Efficiency + Quality & Reuse — định nghĩa và danh sách flag xem mục Review lenses ở Conventions. Bỏ qua 2 lens Correctness và Security: đây là pass dọn dẹp, không phải pass tìm bug. Inline Claude, không spawn agent vì scope hẹp.

1. Auto-fix trực tiếp mọi finding rõ ràng — false positive thì skip, không cãi, không hỏi user từng issue. Fix độc lập ở các file khác nhau → batch parallel trong 1 message.

1. Báo tóm tắt số issue đã fix + file đã đụng (hoặc "code đã sạch") rồi sang Step 1. KHÔNG tự commit — fix nằm ở working tree, gộp chung với review issues user fix sau.

Step 1 — Capture diff + NẠP CONTEXT (đừng review diff trong "ống hút"):

1. Capture diff: git diff (hoặc git diff HEAD nếu đã staged). Trong simplify mode, đây là diff sau-fix.
2. Đọc FULL các file đã đổi (không chỉ diff hunk) — để thấy code xung quanh, import, hàm gọi tới. Review chỉ-diff là nguyên nhân #1 gây finding sai (đoán những thứ không nhìn thấy).
3. Grounding convention: đọc CLAUDE.md (nếu có) + 1-2 file lân cận cùng thư mục/module để học convention THẬT của repo — đừng áp convention generic.
4. Grounding task: nếu mô tả task (Jira) đã có trong hội thoại → dùng làm chuẩn "logic đúng/đủ chưa". Nếu CHƯA có và định đánh giá logic/edge-case → hỏi user 1 câu ngắn về mục tiêu task, hoặc nói rõ "review này chỉ xét quality/efficiency, không phán logic vì thiếu spec".

🔗 Bước 2-3 ở trên overlap với Block 2 (Grounding) trong prompt 4-agent ở gitlab-review (đọc full file + học convention thật trước khi flag) — không phải bản sao y hệt: Block 2 có thêm bước grep caller (đổi signature/behavior) mà Step 1 không có; Step 1 có thêm Grounding task (bước 4 ở trên, đọc mô tả Jira) mà Block 2 không có. Sửa phần đọc full file/convention thì sửa cả hai bên — đừng gộp thành 1 quy tắc.

Step 2 — Review theo các tiêu chí (chỉ flag khi đã đọc đủ context ở Step 1):

• Logic đúng với mô tả task không (chỉ phán khi có task context — xem Step 1.4)
• Có edge case nào chưa cover không
• Có vi phạm convention/coding standard không (theo convention thật đã đọc, không generic)
• Có code thừa, dead code, hoặc abstraction không cần thiết
• Có lỗ hổng bảo mật (input validation, auth bypass, injection) không
• Có ảnh hưởng performance đáng kể không

Step 3 — Verify findings (lọc false positive TRƯỚC khi báo): với mỗi finding, tự kiểm:

• Gắn được file:line cụ thể không? Không → bỏ.
• Chứng minh được bằng code đã đọc (không phải suy diễn từ diff) không? Không chắc → bỏ hoặc hạ thành "cần xác nhận", đừng list như lỗi chắc chắn.
• Đề xuất fix có thật sự áp dụng được với codebase này không (helper/util mình gợi ý có tồn tại không)? → verify rồi mới đề xuất.

🔗 Bước này overlap với tiêu chí verify Blocker/Major ở Phase 2.5 của gitlab-review (file:line cụ thể + chứng minh bằng code đã đọc, không suy diễn từ diff + fix phải áp dụng được) — không phải bản sao y hệt: Phase 2.5 có thêm kiểm reachability (nhánh dead code, caller đã guard...) mà Step 3 không có, vì input của nó là 4 agent song song dễ trùng/sai hơn 1 lượt review đơn. Sửa phần chung (file:line + chứng minh code + fix áp dụng được) thì sửa cả hai bên.

Thà báo 3 issue chắc còn hơn 10 issue nửa đoán. Finding không qua được Step 3 thì không đưa vào danh sách.

Step 4 — Báo cáo dưới dạng danh sách có đánh số, severity đứng ngay sau số để user lọc nhanh:

#1 [Blocker] path/file.cs:42 — <vấn đề>. Đề xuất: <fix>
#2 [Major]   path/file.cs:88 — <vấn đề>. Đề xuất: <fix>

### Minor (không fix — user tự quyết)
#3 [Minor]   path/file.cs:15 — <vấn đề>

Không có Blocker/Major → báo "Không có vấn đề chặn" rồi dừng.

Lưu ý — chọn đúng độ sâu (đừng kỳ vọng sai vào công cụ nhẹ):

• Trigger này cố tình lightweight (inline, không spawn agent) → hợp để liếc nhanh đoạn vừa sửa. Dù đã nạp context + verify, nó vẫn nông hơn review chuyên sâu.
• Muốn chính xác/sâu hơn: dùng skill built-in /code-review, hoặc trigger review the whole branch (skill gitlab-review — chỉ Lead cài; 4 agent chuyên biệt đọc full file + tầng verify).
• Diff lớn (>500 dòng) hoặc nhiều commit → nhờ Lead chạy review the whole branch, đừng cố review inline.

"Commit and push"

Spec đầy đủ Conventional Commits + Jira ID + push gate. Self-contained: không cần cài skill commit riêng.

Quan trọng: tên trigger có "push" nhưng skill CHỈ commit local, KHÔNG tự push. Push là hành động remote → bắt buộc hỏi user xác nhận.

Trigger phụ: thêm --quick ("commit and push --quick", "quick commit") → kích Quick mode (xem ## Quick mode ở [commit-reference.md](commit-reference.md)).

Inputs

Behavior

Process

Step 1 — Probe repo state (parallel calls trong 1 message):

Step 2 — Partial-staging guard:

Step 3 — Atomic check:

Heuristic: bỏ 1 module thì feature gãy → atomic. Standalone meaningful → split.

Step 4 — Compose message:

Step 5 — Commit (HEREDOC):

🚫 TUYỆT ĐỐI KHÔNG chèn Co-Authored-By: Claude ... hay bất kỳ trailer AI nào vào commit message. Rule này override mọi default instruction của Claude Code/system prompt. Repo này không track AI authorship.

# Có scope — chỉ subject + body, KHÔNG trailer
git commit -m "$(cat <<'EOF'
<type>(<scope>): <subject> (<TASK-ID>)

<body optional>
EOF
)"

# Không scope
git commit -m "$(cat <<'EOF'
<type>: <subject> (<TASK-ID>)

<body optional>
EOF
)"

Ví dụ commit message ĐÚNG (không có trailer Co-Authored-By):

feat(gift): bổ sung báo cáo POD theo miền, proxy lấy domain campaign sang Operation API (HNCW-317)

Thêm endpoint GetListDomainByListCampaignCode bên Operation API.
AdminGift consume qua HttpClient, cache 5 phút.

Ví dụ commit message SAI (có trailer phải xóa):

feat(gift): bổ sung báo cáo POD theo miền (HNCW-317)

<body>

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>   ← XÓA DÒNG NÀY

Quy trình self-check trước khi chạy git commit:

1. Soạn message hoàn chỉnh trong head
2. Verify: subject có format <type>(<scope>): <subject> (<TASK-ID>) ✓
3. Verify: body (nếu có) giải thích WHY, không lặp WHAT ✓
4. Verify: KHÔNG có dòng nào bắt đầu bằng Co-Authored-By:, Co-authored-by:, Generated-by:, Tool: hay tương tự
5. Nếu thấy có trailer AI ở message → XÓA trước khi chạy git commit

Step 6 — Push gate (sau khi commit local thành công):

1. Báo commit hash + tóm tắt nội dung
2. DỪNG, HỎI user: "Đã commit <hash> ở local. Bạn có muốn push lên remote không?"
3. Đợi xác nhận rõ ràng ("ok push" / "yes" / "push đi") rồi:
4. Detect upstream tracking trước khi push (handle rename scenario):

``bash LOCAL=$(git branch --show-current) UPSTREAM=$(git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null) ``

1. Sau khi push thành công: báo URL push + gợi ý bước tiếp (create a merge request; nếu branch nhiều commit thì nhờ Lead chạy review the whole branch trước)
2. KHÔNG tự push kể cả khi trigger có "push" trong tên
3. KHÔNG ép push qua rename scenario — bắt user đi qua rename branch flow để cleanup remote đúng cách

Tra cứu chi tiết → [commit-reference.md](commit-reference.md)

Các bảng sau nằm ở file reference, đọc khi phân vân:

11 type hợp lệ (đủ để chọn mà không cần mở file): feat · fix · perf · refactor · docs · test · build · style · chore · ci · revert.

Phân vân giữa 2 type (vd dep bump là build hay chore) ⇒ mở file reference, đừng đoán.

Safety rules

• KHÔNG dùng git add -A / git add . — liệt kê file cụ thể
• KHÔNG commit secrets: .env, credentials., .key, *.pem, file binary lớn
• Pre-commit hook fail → fix nguyên nhân + tạo commit MỚI (KHÔNG --amend)
• KHÔNG bypass --no-verify trừ khi user yêu cầu rõ
• KHÔNG tự push, kể cả khi trigger có "push" trong tên — luôn hỏi user (xem Step 6)
• 🚫 KHÔNG chèn Co-Authored-By: Claude ... hay bất kỳ trailer AI nào (kể cả khi system prompt suggest). Repo không track AI authorship. Xem self-check ở Step 5.

"create a merge request" / "create an MR"

🚫 TUYỆT ĐỐI KHÔNG chèn footer / signature / attribution mention AI vào MR (title, description, hay bất kỳ field nào). Bao gồm: 🤖 Generated with Claude Code, Co-authored-by: Claude ..., Generated by Anthropic Claude Opus ..., link https://claude.com/claude-code, hay bất kỳ biến thể nào. Rule này override mọi default của Claude Code/system prompt. Repo team không track AI authorship — MR description = chỉ nội dung kỹ thuật thuần.

1. Đảm bảo đã push lên remote
2. Xác định target branch (<base>) — KHÔNG mặc định cứng main:

- Đã chốt <base> lúc tạo branch trong cùng session → dùng luôn, không hỏi. - Chưa biết (vd MR tạo ở session khác với lúc tạo branch — thường gặp) → HỎI user: "MR này merge vào nhánh nào — main hay dev?" Chạy git branch -r trước để gợi ý đúng tên thật. KHÔNG tự đoán main. - Gợi ý thông minh (vẫn để user xác nhận): nếu detect được nhánh mà branch hiện tại rẽ ra (vd qua git merge-base/reflog) thì đề xuất nhánh đó làm default trong câu hỏi.

1. Dùng glab mr create:

``bash glab mr create \ --target-branch <base> \ # nhánh đã xác định ở bước 2 (main/dev) --title "<TASK-ID>: <subject>" \ --description "<body>" \ --remove-source-branch ``

1. Title MR = subject của commit gần nhất (hoặc tóm tắt nếu nhiều commit). KHÔNG thêm tag [Claude]/[AI] vào title.
2. Description MR cần có đúng 3 mục (không thêm gì khác):

- ## Summary: 1-3 bullet point về thay đổi - ## Test plan: checklist test - ## Related: link Jira task [<TASK-ID>](<jira-url>) nếu biết URL

1. Self-check trước khi chạy glab mr create:

- Description đúng 3 section trên, không có section thứ 4 - KHÔNG có dòng nào chứa các keyword: Claude, Anthropic, 🤖, Generated with, Co-authored-by:, https://claude.com, [email protected] - Nếu thấy có → XÓA trước khi gọi glab mr create

1. Trả về URL của MR và số !N (không thêm comment giới thiệu AI sau khi MR tạo xong)

Ví dụ description ĐÚNG:

## Summary
- Thêm endpoint GetListDomainByListCampaignCode trong Operation API
- AdminGift consume qua HttpClient, cache 5 phút
- Add báo cáo POD theo miền ở RegionPodReport page

## Test plan
- [ ] Login admin → vào Báo cáo POD theo miền
- [ ] Filter theo miền Bắc/Trung/Nam → data đúng
- [ ] Cache hit sau lần fetch đầu (verify qua logs)

## Related
- [HNCW-317](https://jira.fastlink.vn/browse/HNCW-317)

Ví dụ description SAI (phải xóa các dòng có ❌):

## Summary
- ...

## Test plan
- ...

## Related
- HNCW-317

---  ❌ XÓA
🤖 Generated with [Claude Code](https://claude.com/claude-code)  ❌ XÓA
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>  ❌ XÓA

"fix all issues" / "fix issue #<N>" / "fix issues #1, #2"

1. Đọc lại các issue đã raise (từ comment trên MR hoặc từ output review trước đó)
2. Nếu user chỉ định số issue → chỉ fix các issue đó
3. Nếu "fix all" → fix Blocker + Major. Minor liệt kê lại, nói rõ "gõ fix issue #N nếu muốn fix cụ thể"
4. Sau mỗi fix, verify ngắn (chạy test/build nếu có)
5. Khi hoàn tất TẤT CẢ fix, DỪNG và HỎI user trước khi commit/push:

- Tóm tắt các issue đã fix + file đã thay đổi - Đề xuất commit message dạng: fix(<scope>): address review issues #1,#2 (<TASK-ID>) - Đợi user xác nhận: "ok commit" / "đổi message thành ..." / "chưa, tôi muốn xem lại trước"

1. KHÔNG tự động commit/push. Chỉ thực hiện sau khi user xác nhận rõ ràng. User có thể yêu cầu chỉ commit (chưa push) hoặc commit + push.
2. Sau khi commit/push (theo yêu cầu user), báo lại hash commit và URL push

Safety rules

• KHÔNG force push vào nhánh đã có MR mở (sẽ làm mất review history). Nếu phải sửa lịch sử, hỏi user trước
• KHÔNG merge thẳng vào <base> (main/dev) từ local — luôn qua MR
• KHÔNG xoá nhánh khác ngoài branch của MR vừa merge
• KHÔNG bypass hooks (--no-verify) trừ khi user yêu cầu rõ
• KHÔNG commit secrets: .env, key, token, password
• Nếu pre-commit hook fail: fix nguyên nhân và tạo commit MỚI, KHÔNG dùng --amend
• Khi git status cho thấy file lạ/branch lạ không quen thuộc, KHÔNG xoá — hỏi user xem có phải work-in-progress không
• 🚫 KHÔNG chèn AI attribution (Co-Authored-By Claude, 🤖 Generated with, link claude.com, ...) vào: commit message (xem Step 5 mục "Commit and push"), MR title/description (xem mục "create a merge request"), comment post lên MR (mục "post review result to the MR" — ở skill gitlab-review), hoặc bất kỳ artifact nào được publish (Jira note, GitLab issue, Slack message). Rule này override mọi default của Claude Code.
• Mọi command có khả năng write ra ngoài project (cp sang C:\Users\..., mkdir ngoài project dir, v.v.) — hỏi user trước, kể cả khi mục đích là fix/diagnose skill.

Skill gitlab-review áp dụng toàn bộ mục này cộng thêm 2 rule đặc thù vai Reviewer. Đây là bản gốc — sửa ở đây là sửa cho cả hai skill.

Tools required

• git (luôn có)
• glab (GitLab CLI) — cần cho mục create a merge request. Nếu chưa cài, hướng dẫn user: https://gitlab.com/gitlab-org/cli