Code Review và Git Workflow

Subagent Code Reviewer

Tại sao cần subagent riêng cho review?

Khi Claude vừa viết code xong trong một session dài, nó mang theo bias của người vừa code. Giống như tác giả tự proofreading bài viết của mình — bạn thường không thấy lỗi vì não bộ đọc những gì định viết, không phải những gì thực sự viết.

Subagent code reviewer giải quyết vấn đề này bằng cách chạy trong context window riêng — hoàn toàn fresh, không biết session code vừa làm, không có bias "tôi vừa viết cái này nên nó chắc đúng rồi."

Tạo subagent reviewer qua /agents

Gõ /agents trong Claude Code session để mở agent manager. Tạo agent mới với config như sau:

Tên: code-reviewer

Prompt:

Tools được phép (chỉ read-only):

Check subagent vào repo

Sau khi tạo, subagent config được lưu tại:

• bash — chỉ cho git diff, cat, ls (không cho write commands)
• grep / glob — search codebase
• KHÔNG có edit, KHÔNG có write

┌─────────────────────────────────────────────────────────────┐
│  MAIN AGENT SESSION                                         │
│                                                             │
│  [Explore] → [Plan] → [Code] → [Tests] → [Ready to push]   │
│                                            │                │
│                                            ▼                │
│                                    Spawn subagent           │
│                                            │                │
└────────────────────────────────────────────────────────────-┘
                                             │
                    ┌────────────────────────┘
                    ▼
┌───────────────────────────────────────────────────────────┐
│  CODE REVIEWER SUBAGENT (fresh context window)            │
│                                                           │
│  Tools: Read-only (Bash read, Grep, Glob)                 │
│  NO Write / NO Edit / NO Execute                          │
│                                                           │
│  Task:                                                    │
│  1. Đọc files thay đổi trong PR                          │
│  2. Kiểm tra: logic, security, style, test coverage      │
│  3. Flag issues với file:line reference                  │
│  4. Trả summary lên main agent (KHÔNG tự sửa)           │
│                                                           │
│  Context window bị discard sau khi xong                  │
└───────────────────────────────────────────────────────────┘
                    │
                    ▼
        Review summary → Main agent (hoặc PR comment)

Bạn là code reviewer nghiêm khắc nhưng constructive. Nhiệm vụ của bạn là review
code changes và flag issues — KHÔNG tự sửa file nào.

Khi review, kiểm tra theo thứ tự ưu tiên:

1. **Security** — injection, hardcoded secrets, auth bypass, unsafe deserialization
2. **Logic errors** — off-by-one, null pointer, race condition, edge cases không handle
3. **Test coverage** — có tests cho happy path không? Edge cases? Error paths?
4. **Style & consistency** — theo conventions trong CLAUDE.md project không?
5. **Performance** — N+1 queries, unnecessary loops, memory leaks rõ ràng

Format output:
- Mỗi issue: `[SEVERITY] file.ts:42 — Mô tả ngắn + đề xuất fix`
- SEVERITY: CRITICAL / WARNING / INFO
- Cuối cùng: 1 đoạn tóm tắt overall (3-5 câu)

Chỉ dùng read-only tools. Không write, không edit, không execute scripts.

Check subagent vào repo

Check file này vào repo (git add + commit). Đây là bước quan trọng nhất — khi file nằm trong repo, mọi engineer trong team dùng cùng một reviewer, cùng tiêu chuẩn, không có sự nhất quán phụ thuộc vào cấu hình máy cá nhân.

.claude/agents/code-reviewer.md

Subagent Code Reviewer (tiếp)

Từ đây, bất kỳ ai trong team clone repo đều có reviewer sẵn sàng.

Gọi reviewer trước khi push

Trước khi chạy /commit-push-pr, gọi reviewer:

git add .claude/agents/code-reviewer.md
git commit -m "chore: add shared code-reviewer subagent"

Gọi reviewer trước khi push

Reviewer chạy trong vài phút, trả về danh sách issues. Bạn fix những gì cần fix ngay trong session. Sau đó mới push.

Spawn subagent code-reviewer để review changes trong branch hiện tại.
So sánh với main. Focus vào security và logic errors.

Bảng so sánh: Subagent Reviewer vs Human Reviewer vs Lint/CI

Kết luận thực tiễn: Ba loại không thay thế nhau — chúng bổ sung cho nhau. Lint/CI chạy đầu tiên (fastest), subagent reviewer chạy sau CI (deeper), human reviewer chỉ làm final pass (highest value, scarcest resource).

Skill /commit-push-pr

Vấn đề với workflow thủ công

Sau khi code xong và reviewer approve, phần "plumbing" vẫn tốn thời gian:

Cả quy trình này mất 5-10 phút, và thường bị rush — commit message ngắn, PR description thiếu context, reviewer bị bỏ sót.

/commit-push-pr làm gì

Skill này wrap toàn bộ flow vào một bước:

# Cách thủ công — mỗi bước cần suy nghĩ và gõ
git add -p                          # review từng hunk
git commit -m "feat: add X feature" # viết commit message
git push origin feature/add-x       # nhớ đúng branch name
gh pr create \
  --title "feat: add X feature" \
  --body "## Summary\n..." \        # viết PR description
  --reviewer teammate               # tag reviewer

/commit-push-pr làm gì

Claude sẽ:

Tích hợp Slack tự động

Nếu bạn có Slack MCP server và khai báo channel trong CLAUDE.md project:

• Review diff — xem toàn bộ changes để hiểu scope
• Tạo commit message — theo conventional commits format (feat/fix/chore/refactor...), có body mô tả tại sao thay vì chỉ cái gì
• Stage và commit — chỉ stage files liên quan (không git add . cẩu thả)
• Push lên remote — đúng branch name, không cần nhớ
• Tạo PR — title, description đầy đủ, link issues liên quan nếu có
• Post Slack (nếu có cấu hình) — tự động post PR link vào channel team

/commit-push-pr

Tích hợp Slack tự động

Khi /commit-push-pr chạy xong, Claude post message vào channel — không cần bạn copy-paste link.

So sánh thực tế

<!-- CLAUDE.md -->
## Notifications
Sau khi tạo PR: post link vào Slack channel #engineering-prs

Session linking với --from-pr

Vấn đề: Mất context khi quay lại PR cũ

Bạn làm feature, push PR, đi ăn trưa. Teammate review và comment 8 điểm cần sửa. Sáng hôm sau bạn mở terminal, mở PR — và phải "nhớ lại" từ đầu: file nào đang sửa, decision nào đã làm, edge case nào đã thảo luận.

Nếu dùng Claude trong session cũ, session đó đã đóng. Context đã mất.

--from-pr giải quyết thế nào

Khi Claude tạo PR qua gh pr create (thông qua /commit-push-pr hoặc thủ công trong session Claude), session đó được auto-link với PR number.

Khi bạn muốn quay lại:

Claude sẽ:

Từ đây bạn có thể:

• Fetch PR #247 từ GitHub
• Load diff, description, comments
• Đọc conversation history được link với PR đó
• Resume đúng context — biết bạn đang implement gì, decision nào đã làm, reviewer comment gì

claude --from-pr 247

--from-pr giải quyết thế nào

Claude hiểu ngay — không cần explain lại từ đầu.

Use cases thực tế

Use case 1: Address review comments

Fix tất cả CRITICAL issues mà reviewer comment.
Bắt đầu với comment của @alice về null check trong auth/login.ts.

Use cases thực tế

Use case 2: Fix CI failures sau vài ngày

# Hôm qua push PR
claude --from-pr 247
> Reviewer comment 3 issues. Fix tất cả, ưu tiên CRITICAL trước.

Session linking với --from-pr (tiếp)

Use case 3: Add reviewer's requested feature

# CI fail sau khi main được merge vào branch
claude --from-pr 247
> CI đang fail ở test suite `auth.test.ts`. Đọc CI logs, identify root cause, fix.

Session linking với --from-pr (tiếp)

# Reviewer request thêm logging
claude --from-pr 247
> @bob request thêm structured logging cho tất cả error paths.
> Implement theo pattern trong logger.ts. Đừng thay đổi gì khác.

GitHub Actions Integration

Setup với /install github-action

Đây là tính năng mạnh nhất — cho phép Claude hoạt động ngay trong GitHub PR, không cần mở terminal.

Wizard sẽ hỏi:

Sau khi setup, GitHub Actions workflow được thêm vào .github/workflows/claude.yml.

Cách @Claude hoạt động trong PR comments

Sau khi setup, bất kỳ ai trong team có thể tag @claude trong PR comment:

• Repository nào? (tự detect nếu đang trong git repo)
• Trigger khi nào? (PR comments / issue assignments / PR reviews)
• Permissions? (read repo + write PRs/commits)

/install github-action

Cách @Claude hoạt động trong PR comments

Claude sẽ:

Scope capability của GitHub Actions Claude

Claude trong GitHub Actions có thể làm gì?

Claude không thể merge hay deploy — human vẫn là người approve cuối cùng.

Live demo: Quiz App từ GitHub Issues

Đây là demo thực từ Anthropic team. Họ có một Quiz app với hai issues mở:

Issue #12: "Add 50/50 power-up — remove two wrong answers" Issue #13: "Add per-question timer — 30 seconds countdown"

Thay vì assign cho engineer, họ tag @claude vào cả hai issues. Claude:

Maintainer review, chạy tests (pass), merge. Không có oversight thủ công trong quá trình implement.

Kết quả: Hai features từ zero đến merged trong dưới 1 giờ — bao gồm cả thời gian CI chạy.

• Đọc toàn bộ PR context
• Tìm UserForm.tsx và code liên quan
• Implement validation (dùng existing pattern trong codebase nếu có)
• Tạo commit thêm vào PR branch hiện tại
• Reply vào comment: "Done — added email validation using validator.js (consistent with ProfileForm.tsx line 44)"
• Đọc codebase Quiz app
• Hiểu component structure
• Tạo PR cho mỗi issue (hai PR riêng biệt, tách bạch)
• Implement FiftyFiftyPowerUp component + hook vào game state
• Implement QuestionTimer với countdown và auto-submit
• Tự viết tests cho cả hai
• Request review từ maintainer

<!-- PR comment từ teammate -->
@claude Can you add input validation to the email field in UserForm.tsx?
The field currently accepts any string, should validate proper email format.

Ví dụ thực chiến: Full code review workflow trên team 5 engineers

Setup ban đầu (một lần)

Tất cả 5 engineers từ đây đều có cùng reviewer và cùng GitHub Actions setup.

Workflow hàng ngày

Bước 1: Engineer A hoàn thành feature

# Engineer A (team lead) setup
/agents   # tạo code-reviewer subagent
git add .claude/agents/code-reviewer.md
git commit -m "chore: add shared code-reviewer subagent"
git push

/install github-action   # setup GitHub Actions
# → .github/workflows/claude.yml được tạo và push

Workflow hàng ngày

Reviewer chạy, flag 2 issues:

# Session Claude Code
> Implement user profile avatar upload
# ... code, test, iterate ...

> Spawn subagent code-reviewer để review changes trước khi push

Ví dụ thực chiến: Full code review workflow trên team 5 engineers (tiếp)

Bước 2: Engineer A fix ngay trong session

[CRITICAL] src/profile/upload.ts:34 — File size không được validate.
  User có thể upload file 100MB. Thêm MAX_FILE_SIZE check.
[WARNING] src/profile/upload.ts:67 — Content-Type chỉ check extension,
  không check actual MIME type. Risk: disguised executables.

Ví dụ thực chiến: Full code review workflow trên team 5 engineers (tiếp)

Bước 3: Push và tạo PR

> Fix cả hai issues mà reviewer flag.
> File size limit: 5MB. MIME type validation dùng `file-type` package.

Ví dụ thực chiến: Full code review workflow trên team 5 engineers (tiếp)

PR được tạo với description đầy đủ, link tới issue #89 (avatar upload request). Slack #engineering-prs nhận notification.

Bước 4: Engineer B review trên GitHub

Engineer B thấy PR, đọc description, xem diff. Comment 2 điểm:

/commit-push-pr

Ví dụ thực chiến: Full code review workflow trên team 5 engineers (tiếp)

@claude The upload progress indicator in ProgressBar.tsx should also
show percentage text "45%" not just the bar. Matches our design system.

Ví dụ thực chiến: Full code review workflow trên team 5 engineers (tiếp)

Bước 5: Claude auto-fix cả hai

Claude đọc comments, implement trong 4 phút, thêm commits vào PR branch.

Bước 6: Engineer B approve

Nhìn vào 2 commits mới, verify đúng, approve.

Kết quả:

@claude Add an analytics event `profile_avatar_upload_success` when
upload completes. Use the existing analytics.track() pattern in analytics.ts.

Ví dụ thực chiến: Full code review workflow trên team 5 engineers (tiếp)

Tổng thời gian: 2 giờ 40 phút
  - Engineer A code: 1 giờ 30 phút
  - Subagent review + fix: 10 phút
  - Engineer B review: 20 phút
  - Claude fix PR comments: 5 phút
  - Engineer B final approve: 5 phút

So với cách cũ:
  - Không có first-pass review → security issues vào production
  - Chờ Engineer B available: 1-2 ngày
  - Fix comments thủ công: 30 phút
  - Total: 3-5 ngày

Case studies theo role

Indie hacker (1 người)

Tình huống: Bạn build SaaS solo. Không có teammate review. Mỗi PR là bạn review chính mình — vừa thiếu "second pair of eyes", vừa tốn thời gian.

Cách dùng:

Kết quả thực tế: Bắt bugs mà bạn "blind" sau 3 tiếng code liên tục. Security issues được flag trước khi lên production.

Engineering team (5+ người)

Tình huống: Senior engineers là bottleneck review. Junior PR chờ 2-3 ngày.

Cách dùng:

Kết quả: Senior engineer review time giảm 60% — chỉ review những gì thực sự cần human judgment.

Open source maintainer

Tình huống: Hàng chục contributor PRs mỗi tuần. Maintainer không thể review tất cả ngay.

Cách dùng:

Kết quả: Contributor nhận feedback trong phút, không phải ngày. Maintainer không bị burnout. Project velocity tăng.

Designer ship code

Tình huống: Product designer muốn tự ship UI polish PRs mà không cần engineer review từng cái.

Cách dùng:

Kết quả: Designer ship 8-10 polish PRs/ngày độc lập. Engineer chỉ review architectural changes, không review mỗi padding fix.

DevOps / Platform team

Tình huống: Infra changes (Terraform, Kubernetes, Helm) rủi ro cao — một lỗi nhỏ có thể down production. Team không có dedicated infra reviewer.

Cách dùng:

Kết quả: Infra PRs có audit trail rõ ràng. Non-infra engineers tự tin approve sau khi Claude giải thích.

• Subagent reviewer = "second pair of eyes" thực sự — fresh context, không biết "ý định" của bạn khi code
• /commit-push-pr sau mỗi feature: ship trong 5 phút, không loay hoay với git commands
• GitHub Actions: @claude add unit tests for the payment webhook handler khi review PR của chính mình sau ngủ dậy
• Subagent reviewer là mandatory first pass trên CI — PR chỉ ready-for-human-review khi reviewer không còn CRITICAL/WARNING issues
• Human reviewer chỉ focus vào: architectural decisions, business logic correctness, code ownership questions
• @claude cho mechanical fixes (formatting, missing tests, error handling)
• GitHub Actions Claude tự động reply contributor PRs khi có @claude tag
• @claude Please review this PR against our contribution guidelines in CONTRIBUTING.md
• Claude check: style guide compliance, test coverage, breaking changes, docs update needed
• Maintainer chỉ final-approve sau khi Claude đã check
• Subagent reviewer config với focus: accessibility (a11y), color contrast, focus states, responsive breakpoints
• Prompt reviewer: "Check WCAG 2.1 AA compliance cho changes. Flag: missing aria-labels, insufficient color contrast, no focus rings"
• /commit-push-pr sau mỗi polish PR: designer không cần học git commands
• @claude cho technical questions: "Does this CSS change affect performance on mobile?"
• Subagent reviewer được train với infra-specific checklist:
• "Check Terraform changes: không hardcode sensitive values, có terraform plan output không, state file có được lock không?"
• "Check K8s manifests: resource limits có set không, liveness/readiness probes đúng không, security context có restrict privileges không?"
• GitHub Actions @claude explain what this Terraform change does in plain English — giúp non-infra engineers hiểu PR họ cần approve

Anti-patterns

Anti-pattern 1: Subagent reviewer có write tools

Triệu chứng: Config reviewer với tất cả tools (kể cả edit/write), nghĩ rằng "reviewer tự fix luôn thì nhanh hơn."

Tại sao tệ: Reviewer là role khác với implementer. Nếu reviewer tự sửa, bạn mất khả năng verify "fix có đúng không?" — vì reviewer đã trở thành một agent khác viết code trong cùng context. Vi phạm separation of concerns, làm mờ trách nhiệm.

Cách đúng: Reviewer chỉ flag. Main agent (hoặc bạn) quyết định fix gì. Sau đó reviewer chạy lại để verify.

Anti-pattern 2: Skip human review hoàn toàn

Triệu chứng: "Subagent reviewer đã approve, Claude review cũng tốt rồi, merge thôi."

Tại sao tệ: Claude review rất tốt về code quality, security patterns, style. Nhưng Claude không biết:

Human reviewer mang context không thể encode vào subagent config.

Cách đúng: Subagent reviewer = first pass. Human reviewer = final gate cho production.

Anti-pattern 3: Không check .claude/agents/ vào repo

Triệu chứng: Mỗi engineer tự config reviewer khác nhau, hoặc một số người không có reviewer.

Tại sao tệ: Team không nhất quán. Engineer A có reviewer nghiêm khắc (flag nhiều). Engineer B không có reviewer (ship nhanh hơn nhưng thiếu check). Code quality không đồng đều.

Cách đúng: .claude/agents/code-reviewer.md là team artifact, check vào repo, review như code khác.

Anti-pattern 4: Auto-merge PR sau Claude review

Triệu chứng: CI pipeline: lint pass + subagent reviewer pass → auto-merge vào main.

Tại sao tệ: Claude reviewer rất tốt nhưng không hoàn hảo. False negatives xảy ra, đặc biệt với business logic phức tạp. Auto-merge bỏ qua safety net cuối cùng.

Cách đúng: Claude review rút ngắn time-to-human-approval, không thay thế human approval. Vẫn require human approve trước khi merge vào main/production.

Anti-pattern 5: Tag @claude cho task không phải code

Triệu chứng: @claude please analyze our Q3 metrics and suggest product direction trong PR comment.

Tại sao tệ: GitHub Actions Claude được design cho code tasks trong context của PR. Analytics, product planning, strategic decisions không có đủ context trong PR. Claude sẽ trả lời nhưng response sẽ superficial — không có data access, không có product context.

Cách đúng: @claude cho: code changes, tests, bug fixes, explanations về code trong PR. Dùng Claude Code trong terminal cho: research, analysis, planning.

• Business constraint bất thành văn ("chúng ta không cache payment data vì compliance")
• Architectural direction dài hạn ("module này sắp được rewrite, không đầu tư thêm")
• Context về team ("engineer vừa join, code này họ sẽ maintain — cần readable hơn optimal")

Mẹo nâng cao

Mẹo 1: Custom reviewer prompt theo team priorities

Không có "one size fits all" cho reviewer. Customize theo domain:

<!-- .claude/agents/security-reviewer.md -->
Bạn là security engineer với 10 năm kinh nghiệm.
Focus 100% vào security issues. Bỏ qua style/naming.

Checklist bắt buộc:
- SQL injection via string concatenation
- XSS via unescaped user input
- Hardcoded secrets hoặc API keys
- Insecure direct object reference (IDOR)
- Missing authentication/authorization checks
- Unsafe deserialization
- Path traversal vulnerabilities

Mẹo 1: Custom reviewer prompt theo team priorities

Chạy cả hai song song:

<!-- .claude/agents/accessibility-reviewer.md -->
Bạn là accessibility specialist, WCAG 2.1 AA expert.

Kiểm tra:
- aria-label cho interactive elements không có text
- Color contrast ratio (minimum 4.5:1 cho normal text)
- Focus indicator visible
- Keyboard navigation flow hợp lý
- Alt text cho images
- Form labels liên kết đúng input

Mẹo nâng cao (tiếp)

Mẹo 2: Hook PostToolUse chạy ESLint trước commit

Thay vì nhớ chạy lint thủ công, dùng hook để tự động hóa (xem chi tiết Bài 2.11):

Spawn security-reviewer và accessibility-reviewer song song để review PR hiện tại.

Mẹo 2: Hook PostToolUse chạy ESLint trước commit

Mỗi lần Claude edit file, ESLint tự chạy và fix style issues — reviewer không cần flag những lỗi này nữa.

Mẹo 3: Multiple specialized reviewers chạy parallel

Thay vì một reviewer làm tất cả (và làm trung bình), có nhiều reviewer chuyên biệt:

Trước khi push:

.claude/agents/
├── code-reviewer.md        # general logic + quality
├── security-reviewer.md    # security only
├── accessibility-reviewer.md  # a11y only
└── performance-reviewer.md # perf only (N+1, memory leaks)

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx eslint --fix ${file} 2>/dev/null || true"
          }
        ]
      }
    ]
  }
}

Mẹo 3: Multiple specialized reviewers chạy parallel

Mẹo 4: --from-pr resume khi CI fail sau vài ngày

CI đôi khi fail vì lý do không liên quan đến code của bạn (flaky tests, infra issues). Sau khi CI ổn định:

Spawn tất cả 4 reviewers song song. Tổng hợp results thành 1 report:
- CRITICAL issues cần fix trước khi push
- WARNING issues nên fix nhưng không block
- INFO suggestions cho future improvement

Mẹo 4: --from-pr resume khi CI fail sau vài ngày

Claude resume đúng context của PR — biết feature này làm gì, có thể đọc CI logs và fix một cách informed thay vì mù quáng.

Mẹo 5: Combine /commit-push-pr với reviewer

Tạo một workflow hoàn chỉnh trong CLAUDE.md:

claude --from-pr 247
> CI đã recover. Chạy lại test suite. Nếu vẫn fail, debug và fix.

Mẹo 5: Combine /commit-push-pr với reviewer

Claude sẽ tự follow quy trình này mỗi khi bạn muốn push.

## PR workflow
Trước khi /commit-push-pr, luôn:
1. Spawn code-reviewer, fix CRITICAL issues
2. Spawn security-reviewer nếu changes liên quan đến auth/payment
3. Sau đó mới /commit-push-pr

Áp dụng ngay

Bài tập 1: Tạo subagent code reviewer (15 phút)

Bước 1: Trong một project đang có PR open (hoặc tạo branch test):

Bước 2: Tạo agent code-reviewer với prompt từ phần trên, chỉ có read-only tools.

Bước 3: Gọi reviewer trên diff hiện tại:

/agents

Bài tập 1: Tạo subagent code reviewer (15 phút)

Bước 4: Check file vào repo:

Spawn code-reviewer để review changes trong branch này vs main.
Trả về danh sách issues theo format [SEVERITY] file:line — mô tả.

Áp dụng ngay (tiếp)

Ghi lại: Reviewer flag bao nhiêu issues? Có CRITICAL nào không? Bạn có đồng ý với assessment không?

Bài tập 2: Setup GitHub Actions (20 phút)

Điều kiện: Cần GitHub repo với admin access.

Bước 1:

git add .claude/agents/code-reviewer.md
git commit -m "chore: add shared code-reviewer subagent"

Bài tập 2: Setup GitHub Actions (20 phút)

Follow wizard — mất khoảng 3-5 phút.

Bước 2: Push thay đổi (wizard tạo .github/workflows/claude.yml):

/install github-action

Áp dụng ngay (tiếp)

Bước 3: Tạo một PR test (hoặc dùng PR đang open). Trong comment, tag:

git add .github/workflows/claude.yml
git commit -m "ci: add Claude GitHub Actions integration"
git push

Áp dụng ngay (tiếp)

Bước 4: Observe response trong vòng 2-3 phút.

Bước 5 (nâng cao): Tag tiếp:

@claude Please explain what this PR does in 3 bullet points for non-technical stakeholders.

Áp dụng ngay (tiếp)

Ghi lại: Claude mất bao lâu để respond? Commit có được thêm vào PR không? Quality của output thế nào?

@claude Add a simple smoke test for the main function in this PR.

Tóm tắt

Subagent reviewer = fresh context, không bias. Code reviewer chạy trong context window riêng, không biết "ý định" của bạn khi code — flag issues khách quan hơn. Restrict read-only tools, check config vào repo để cả team dùng chung.

/commit-push-pr = one-step từ code đến PR. Thay thế chuỗi git add / commit / push / gh pr create thủ công. Commit message chất lượng cao, PR description đầy đủ, Slack notification tự động nếu có MCP.

--from-pr = resume không mất context. Khi Claude tạo PR, session được link với PR number. claude --from-pr <N> pick up exact state — address review comments hay fix CI failures mà không cần explain lại từ đầu.

GitHub Actions @claude = Claude làm việc trong GitHub. /install github-action một lần, sau đó bất kỳ ai tag @claude trong PR comment đều có thể delegate code tasks — fix, add tests, explain — mà không cần mở terminal.

Human review vẫn là final gate. Claude reviewer rút ngắn time-to-human-review, không thay thế nó. Architectural decisions, business logic, context về team — human reviewer mang những thứ này mà Claude không có.