Gitlab Flow

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.

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

Target branch

• MR luôn merge vào 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", "review the whole branch", "review the MR !N", "post review result to the MR"...). 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.

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".

Triggers & Procedures

"create branch " hoặc "create branch from task ..."

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. Checkout main, pull về bản mới nhất: git fetch origin main && git checkout main && git pull
3. Tạo branch:
   • 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)
4. Báo lại tên branch + length character count

Edge case:

"rename branch " hoặc "rename branch sang "

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.

2. Scan diff theo 3 góc nhìn Reuse / Quality / Efficiency — danh sách flag chi tiết dùng chung với bảng Phase 2 của review the whole branch (xem section bên dưới). Inline Claude, không spawn agent vì scope hẹp.

3. 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.

4. 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 cho review: git diff (hoặc git diff HEAD nếu đã staged). Trong simplify mode, đây là diff sau-fix.

Step 2 — Review theo các tiêu chí:

• Logic đúng với mô tả task không
• Có edge case nào chưa cover không
• Có vi phạm convention/coding standard không
• 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 — Báo cáo dưới dạng danh sách có đánh số: #1, #2, ... để user dễ tham chiếu khi fix.

Lưu ý: Simplify mode scope hẹp (chỉ uncommitted diff) + inline review. Diff lớn (>500 dòng) → dùng review the whole branch (3 agent song song) thay thế.

"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 cuối section).

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) <noreply@anthropic.com>   ← 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):

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

   Trạng thái	Lệnh push
   Không có upstream (UPSTREAM rỗng)	git push -u origin <LOCAL> (lần đầu push branch này)
   UPSTREAM = origin/<LOCAL> (tên local match remote)	git push (bình thường)
   UPSTREAM = origin/<old-name> (tên local KHÁC upstream)	Rename scenario detected. STOP, báo user: "Local branch <LOCAL> đang track <UPSTREAM> — có vẻ branch đã được rename. Cần dùng trigger rename branch <LOCAL> để sync remote, KHÔNG nên push trực tiếp"

5. Sau khi push thành công: báo URL push + gợi ý bước tiếp (vd review the whole branch hoặc create a merge request)

6. KHÔNG tự push kể cả khi trigger có "push" trong tên

7. KHÔNG ép push qua rename scenario — bắt user đi qua rename branch flow để cleanup remote đúng cách

Allowed types

Breaking change là modifier, không phải type riêng. Suffix ! hoặc footer BREAKING CHANGE: → MAJOR bump (X.0.0).

Footer

Vị trí: sau body, ngăn bằng dòng trắng. Format: Token: value (CC) hoặc Token #issue (GitHub-style).

Scope

Lookup: đọc .commit-scopes ở repo root → fallback git log --pretty=format:%s | grep -oE '\([^)]+\):' | sort -u.

🚫 Đừng invent generic scope (core, misc) để fill format. No-scope flags "needs categorization"; invented scope masks the gap.

.commit-scopes file: plain text — 1 scope/dòng, dòng # là comment, blank/whitespace trimmed.

Quick mode

Trigger: thêm --quick ("commit and push --quick" / "quick commit").

Use for: hotfix · dep bump · typo fix · internal tool · small chore Don't use for: feat/refactor cần why-body · breaking change · multi-module change (drop --quick, dùng no-scope normal)

Dep bump → build (build system / packaging) per CC spec, không chore. chore chỉ cho housekeeping không fit type khác.

WIP / Spike

chore: wip refactor luồng auth (WRA-123)
chore: spike test kết nối Redis (WRA-999)

Pair tự nhiên với --quick: "commit and push --quick" (no scope, no body, lightweight).

Examples

feat with body:

feat(auth): thêm JWT refresh token rotation (WRA-201)

Implement sliding expiration cho refresh token, revoke
token cũ khi phát hiện reuse.

fix one-liner:

fix(billing): tính sai VAT cho đơn hàng có discount (WRA-334)

refactor with body:

refactor(order): tách OrderService thành các handler nhỏ (WRA-412)

Không đổi behavior, chuẩn bị cho việc thêm payment provider.

breaking change:

feat(api)!: đổi response format endpoint /users (WRA-450)

BREAKING CHANGE: field `user_id` đổi thành `id`. Clients
phải cập nhật trước khi deploy.

revert:

revert: feat(auth): thêm JWT refresh token rotation (WRA-501)

This reverts commit 7cd2ed6693da5f5d70751084d20c915c54b9f37d.

Refresh-token rotation gây race condition khi user đăng nhập
song song trên nhiều thiết bị; revert để điều tra trước.

Refs WRA-201

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.

"review the whole branch" (review cumulative trước khi mở MR)

Review TOÀN BỘ thay đổi của branch hiện tại so với main — committed + uncommitted — qua 3 agent song song, rồi tự fix issues. Khác review the last change ở điểm: nhìn cumulative diff (nhiều commit), 3 góc nhìn chuyên sâu, auto-fix các issue rõ ràng.

Khi nào dùng: sau khi đã có nhiều commit và push chính, trước khi create a merge request. Output có thể tạo thêm changes → cần thêm 1 lượt commit and push nữa rồi mới mở MR. Bỏ qua bước này nếu branch chỉ 1 commit nhỏ — review the last change là đủ.

Phase 1 — Identify changes:

1. Resolve merge base: git merge-base main HEAD
2. Nếu branch hiện tại IS main (hoặc base = HEAD) → báo "không có gì để review" và STOP
3. Capture cumulative diff (commit + working tree) vào temp file để các agent đọc mà không flood context:

   BASE=$(git merge-base main HEAD)
   git diff --no-color "$BASE" > /tmp/review_branch.diff
   wc -l /tmp/review_branch.diff
   

4. Capture danh sách file untracked (diff không bao gồm):

   git ls-files --others --exclude-standard > /tmp/review_branch_new.txt
   

5. Stat tóm tắt để spot-check:

   git diff --stat "$BASE"
   

Phase 2 — Launch 3 agent SONG SONG (1 message, 3 Agent tool calls):

Mỗi agent nhận: đường dẫn diff + đường dẫn new-files + context "cumulative diff branch against main".

Phase 3 — Aggregate + fix:

1. Đợi cả 3 agent xong, gộp findings lại
2. Fix trực tiếp từng issue trong working tree. False positive thì skip, không cãi.
3. KHÔNG tự commit/push — để user review changes rồi tự commit and push (sẽ hỏi xác nhận push như thường lệ)
4. Tóm tắt: số issue đã fix, file đã đụng, status test/typecheck (nếu chạy)
5. Gợi ý bước tiếp: nếu có fix → commit and push rồi create a merge request; nếu không có gì cần sửa → create a merge request luôn

Lưu ý:

• Diff > 2000 dòng → review có thể coarse-grained. Khuyến cáo user lần sau chạy sớm hơn (sau mỗi vài commit) thay vì để dồn cuối.
• Repo dùng master/develop thay main → hỏi user 1 lần rồi dùng tên đó (skill mặc định main).
• Trigger này chuyên review macro. Để review chỉ thay đổi gần nhất → dùng review the last change. Để review MR đã push (vai Reviewer) → dùng review the MR !<N>.

"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. Dùng glab mr create:

   glab mr create \
     --target-branch main \
     --title "<TASK-ID>: <subject>" \
     --description "<body>" \
     --remove-source-branch
   

3. 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.
4. 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
5. 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, noreply@anthropic.com
   • Nếu thấy có → XÓA trước khi gọi glab mr create
6. 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) <noreply@anthropic.com>  ❌ XÓA

"review the MR !" (vai trò Reviewer)

1. Yêu cầu glab CLI đã cài: kiểm tra glab --version

2. Lấy thông tin MR + comment đã có:

   • glab mr view <N> --comments (hiển thị cả note/discussion đã có)

3. BẮT BUỘC lấy diff từ remote bằng glab mr diff <N>. KHÔNG thay thế bằng git diff <base>...<source> so với branch local — main (hoặc base) ở local có thể stale, dẫn tới review nhầm hàng trăm commits đã có sẵn trên remote. Nếu thực sự cần dùng git diff (vd để lấy stat), phải git fetch origin <base-branch> trước rồi so với origin/<base-branch>, không phải branch local.

4. Phân nhánh theo trạng thái comment:

   (A) MR CHƯA có comment review nào → review mới hoàn toàn:

   • Review toàn bộ diff theo tiêu chí ở mục "review the last change"
   • Liệt kê issues #1, #2, ... mỗi issue có: file + dòng, vấn đề, đề xuất fix
   • Đánh giá tổng thể: APPROVE / REQUEST_CHANGES / COMMENT

   (B) MR ĐÃ có comment review trước đó → review tiếp nối, KHÔNG review lại từ đầu:

   • Đọc kỹ comment cũ, trích xuất danh sách issue đã raise (#1, #2, ...) kèm verdict gần nhất
   • Xác định mốc thời gian / commit của lần review trước (lấy created_at của note review cuối, hoặc commit SHA mà reviewer reference)
   • Lấy commit mới push từ sau mốc đó: glab mr view <N> → xem commits hoặc git log <last-reviewed-sha>..origin/<source-branch>
   • Đối chiếu issue cũ: với mỗi issue #N đã raise, kiểm tra trong commit/diff mới xem đã được fix chưa. Đánh dấu:
     • ✓ Resolved #N — đã fix đúng
     • ❌ Still open #N — chưa fix, hoặc fix sai/chưa đủ — kèm lý do
     • ⚠️ Partially #N — fix một phần, kèm điều còn thiếu
   • Issue mới phát sinh từ commit mới: đánh số tiếp theo (#N+1, #N+2, ...), không tái sử dụng số cũ
   • KHÔNG review lại các phần code không thay đổi từ lần review trước (trừ khi liên quan trực tiếp tới issue cũ)
   • Đánh giá tổng thể dựa trên trạng thái mới: APPROVE nếu mọi issue cũ đã ✓ Resolved và không có issue mới nghiêm trọng; REQUEST_CHANGES nếu còn ❌ Still open hoặc có issue mới blocking; COMMENT cho các trường hợp còn lại

5. Output format thống nhất:

   ## Review !<N> (lần thứ <K>)
   
   **Verdict:** APPROVE | REQUEST_CHANGES | COMMENT
   
   ### Trạng thái issue cũ        ← chỉ có ở mode (B)
   - ✓ Resolved #1
   - ❌ Still open #2 — <lý do>
   - ⚠️ Partially #3 — <còn thiếu>
   
   ### Issue mới
   - #N+1 `path/to/file.js:42` — <vấn đề>. Đề xuất: <fix>
   

"post review result to the MR"

🚫 KHÔNG chèn AI attribution vào comment (Co-Authored-By Claude, 🤖 Generated with, link claude.com, ...). Comment = chỉ nội dung review thuần, KHÔNG signature/footer.

1. Lấy chính output Markdown từ bước "review the MR" trước đó (đã đúng format, không cần soạn lại). Nếu là review tiếp nối (mode B), giữ nguyên cả phần "Trạng thái issue cũ" — đó là context quan trọng cho dev.
2. Self-check trước khi glab mr note: scan output Markdown, đảm bảo không có keyword Claude, Anthropic, 🤖, Generated with, Co-authored-by:, claude.com. Có → xóa.
3. Đăng comment: glab mr note <N> --message "<markdown>"
4. Nếu APPROVE: glab mr approve <N>
5. Nếu REQUEST_CHANGES với toàn bộ issue cũ đã ✓ Resolved (chỉ còn issue mới): nói rõ trong comment để dev biết phần fix trước đã OK

"fix all issues" / "fix issue #" / "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 tất cả
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"
6. 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.
7. Sau khi commit/push (theo yêu cầu user), báo lại hash commit và URL push

"merge the request"

1. Kiểm tra MR đã có:
   • At least 1 approve
   • CI pipeline pass: glab mr view <N> (hoặc glab ci status)
   • Không có conflict
2. Nếu thiếu điều kiện, BÁO CHO USER và hỏi có override không (KHÔNG tự ý merge)
3. Merge: glab mr merge <N> --remove-source-branch --squash
4. Checkout về main, pull về bản mới nhất
5. Báo merge thành công + commit hash trên main

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 main 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 (xem mục "post review result to the MR"), 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.

Tools required

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

Skill installation hygiene

Rule này áp dụng cho Claude khi diagnose/fix vấn đề skill (stale, missing behavior, sync issue) — không liên quan workflow GitLab.

🚫 **KHÔNG tự copy/sync skill file vào C:\Users\admin\.claude\skills\ (global skill location) trừ khi user yêu cầu rõ ràng.** Cùng nguyên tắc cho mọi system-level location: ~/.claude/, %APPDATA%/Claude/, v.v.

Default action khi user báo skill bị stale/sai:

1. Verify trong source repo my-skills đã có version đúng
2. Gợi ý user chạy npx skills update trong project bị ảnh hưởng (KHÔNG -g)
3. Gợi ý user restart Claude session để load skill mới
4. Chỉ copy thủ công tới global IF user explicitly request (vd "sync luôn global đi")

Lý do:

• Dual-location (global + project) dễ tạo state lệch nhau — global stale trong khi local đã update, hoặc ngược lại
• Project-only = single source of truth, predictable, dễ debug
• User có quyền chọn nơi cài; auto-touch global bypass quyền đó

Khi user thực sự muốn cài global: họ sẽ chủ động thêm -g flag:

npx skills add nguyenvanchiens/my-skills -s gitlab-flow -y -g -a claude-code --copy

Cùng rule cho mọi command có khả năng write ra ngoài project (cp to C:\Users\..., mkdir ngoài project dir, etc.) — hỏi user trước.