​
Mục tiêu học tập

Sau bài này, bạn sẽ có thể:
  • ✅ Tạo subagent code reviewer dùng chung toàn team, check vào repo để nhất quán
  • ✅ Dùng skill /commit-push-pr để commit, push và tạo PR trong một bước duy nhất
  • ✅ Link các session với —from-pr để tiếp tục công việc đúng điểm đã dừng
  • ✅ Setup GitHub Actions integration và dùng tag @Claude trong PR comments để Claude tự fix
  • ✅ Biết khi nào nên — và không nên — dùng @Claude để tránh over-delegation

​
Mở đầu: Khi bottleneck review làm chậm cả team

Hãy tưởng tượng một team 5 engineers ở một AI startup. Họ build nhanh — mỗi ngày đẩy 3-5 PR. Nhưng có một vấn đề: chỉ có hai engineer senior có thể review code đúng nghĩa. Và cả hai đều đang bận với feature của mình. Kết quả? Mỗi PR trung bình chờ 2-3 ngày trước khi được review lần đầu. Sau khi nhận feedback, engineer phải fix rồi chờ thêm 1-2 ngày review lần hai. Tổng thời gian từ push branch đến merge: 5-7 ngày cho một feature không phức tạp. Team bắt đầu chọn cách dễ hơn: merge PR mà không review kỹ. Kỹ thuật nợ tích lũy. Bug lọt vào production. Sau khi adopt subagent code reviewer cùng với GitHub Actions integration, bức tranh thay đổi hoàn toàn. Engineer push branch → subagent reviewer chạy ngay trên CI, comment lên PR trong vòng 3 phút — kiểm tra logic, security, style consistency. Engineer fix ngay trong cùng session. Human reviewer chỉ cần approve architectural decisions. Time-to-merge giảm từ 5-7 ngày xuống còn 4-6 giờ. Và khi cần fix PR theo comment của reviewer? Không còn phải “nhớ lại” mình đang làm đến đâu. Chỉ cần: 
claude --from-pr 247
Claude pick up đúng state, đúng context, đúng chỗ bạn dừng. Hay hơn nữa, khi có comment trên PR từ teammate: “Hey @Claude, fix this thing” — và nó sẽ fix. Đó là sức mạnh của GitHub Actions integration. Bài này sẽ dạy bạn cách build cả hệ thống đó từ đầu — subagent reviewer, skill commit, session linking, và GitHub Actions automation.

​
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: 
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.
Tools được phép (chỉ read-only):
  • bash — chỉ cho git diff, cat, ls (không cho write commands)
  • grep / glob — search codebase
  • KHÔNG có edit, KHÔNG có write

​
Check subagent vào repo

Sau khi tạo, subagent config được lưu tại: 
.claude/agents/code-reviewer.md
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. 
git add .claude/agents/code-reviewer.md
git commit -m "chore: add shared code-reviewer subagent"
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: 
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.
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.

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

Tiêu chíSubagent ReviewerHuman ReviewerLint/CI
Tốc độ2-5 phút2-3 ngày (trung bình)30 giây
Độ sâu feedbackCao — logic, security, contextRất cao — architectural, business logicThấp — syntax, formatting
Hiểu business logicTrung bình (đọc code + comments)Cao (hiểu product context)Không
Style consistencyCao (theo CLAUDE.md)Phụ thuộc reviewerCao (theo ruleset cố định)
Security checkKhá tốt — biết common patternsTốt nếu reviewer có kinh nghiệmChỉ với security linter
False positive rateTrung bình (đôi khi over-cautious)ThấpThấp (deterministic)
CostToken cost (~vài cent/review)Thời gian engineer seniorGần như 0 (CI minutes)
Ideal use caseFirst pass — catch obvious issues trước humanArchitectural decisions, business logic, final approvalStyle enforcement, breaking changes
Hoạt động khi nàoOn-demand hoặc pre-pushSynchronous — cần người availableMỗi push (automatic)
BiasFresh context — không biasCó thể bị “rubber stamp” khi bậnKhông có bias
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á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
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: 
/commit-push-pr
Claude sẽ:
  1. Review diff — xem toàn bộ changes để hiểu scope
  2. 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ì
  3. Stage và commit — chỉ stage files liên quan (không git add . cẩu thả)
  4. Push lên remote — đúng branch name, không cần nhớ
  5. Tạo PR — title, description đầy đủ, link issues liên quan nếu có
  6. Post Slack (nếu có cấu hình) — tự động post PR link vào channel team

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

Nếu bạn có Slack MCP server và khai báo channel trong CLAUDE.md project: 
<!-- CLAUDE.md -->
## Notifications
Sau khi tạo PR: post link vào Slack channel #engineering-prs
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ế

Cách thủ công/commit-push-pr
Thời gian5-10 phút20-30 giây
Commit message qualityPhụ thuộc tâm trạngConsistent, conventional
PR descriptionThường thiếuĐầy đủ context
Slack notificationThường quênTự động
Lỗi do gõ nhầmThỉnh thoảngKhông có

​
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 --from-pr 247
Claude sẽ:
  1. Fetch PR #247 từ GitHub
  2. Load diff, description, comments
  3. Đọc conversation history được link với PR đó
  4. Resume đúng context — biết bạn đang implement gì, decision nào đã làm, reviewer comment gì
Từ đây bạn có thể: 
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.
Claude hiểu ngay — không cần explain lại từ đầu.

​
Use cases thực tế

​
Use case 1: Address review comments

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

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

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

​
Use case 3: Add reviewer’s requested feature

# 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. 
/install github-action
Wizard sẽ hỏi:
  • 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)
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: 
<!-- 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.
Claude sẽ:
  1. Đọc toàn bộ PR context
  2. Tìm UserForm.tsx và code liên quan
  3. Implement validation (dùng existing pattern trong codebase nếu có)
  4. Tạo commit thêm vào PR branch hiện tại
  5. Reply vào comment: “Done — added email validation using validator.js (consistent with ProfileForm.tsx line 44)“

​
Scope capability của GitHub Actions Claude

Claude trong GitHub Actions có thể làm gì?
CapabilityCóKhông
Đọc code trong repo✅
Tạo PR từ issue✅
Thêm commits vào PR existing✅
Trả lời câu hỏi trong comments✅
Review code và comment✅
Merge PR❌
Delete branch❌
Thay đổi repo settings❌
Access private secrets (ngoài những gì được configure)❌
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:
  1. Đọc codebase Quiz app
  2. Hiểu component structure
  3. Tạo PR cho mỗi issue (hai PR riêng biệt, tách bạch)
  4. Implement FiftyFiftyPowerUp component + hook vào game state
  5. Implement QuestionTimer với countdown và auto-submit
  6. Tự viết tests cho cả hai
  7. Request review từ maintainer
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.

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

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

# 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
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

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

> Spawn subagent code-reviewer để review changes trước khi push
Reviewer chạy, flag 2 issues: 
[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.

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

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

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

/commit-push-pr
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: 
@claude The upload progress indicator in ProgressBar.tsx should also
show percentage text "45%" not just the bar. Matches our design system.

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

​
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ả: 
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:
  • 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
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:
  • 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)
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:
  • 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
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:
  • 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?”
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:
  • 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
Kết quả: Infra PRs có audit trail rõ ràng. Non-infra engineers tự tin approve sau khi Claude giải thích.

​
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:
  • 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”)
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.

​
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

<!-- .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
Chạy cả hai song song: 
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

Thay vì nhớ chạy lint thủ công, dùng hook để tự động hóa (xem chi tiết Bài 2.11): 
// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx eslint --fix ${file} 2>/dev/null || true"
          }
        ]
      }
    ]
  }
}
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: 
.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)
Trước khi push: 
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

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: 
claude --from-pr 247
> CI đã recover. Chạy lại test suite. Nếu vẫn fail, debug và fix.
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: 
## 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
Claude sẽ tự follow quy trình này mỗi khi bạn muốn push.

​
Á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): 
/agents
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: 
Spawn code-reviewer để review changes trong branch này vs main.
Trả về danh sách issues theo format [SEVERITY] file:line — mô tả.
Bước 4: Check file vào repo: 
git add .claude/agents/code-reviewer.md
git commit -m "chore: add shared code-reviewer subagent"
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: 
/install github-action
Follow wizard — mất khoảng 3-5 phút. Bước 2: Push thay đổi (wizard tạo .github/workflows/claude.yml): 
git add .github/workflows/claude.yml
git commit -m "ci: add Claude GitHub Actions integration"
git push
Bước 3: Tạo một PR test (hoặc dùng PR đang open). Trong comment, tag: 
@claude Please explain what this PR does in 3 bullet points for non-technical stakeholders.
Bước 4: Observe response trong vòng 2-3 phút. Bước 5 (nâng cao): Tag tiếp: 
@claude Add a simple smoke test for the main function in this PR.
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?

​
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ó.

​
Bài tiếp theo

Bạn đã biết cách code review với subagent, commit với skill, và tích hợp Claude vào GitHub workflow. Bước tiếp theo để “dạy” Claude hiểu project của bạn sâu hơn là file CLAUDE.md — nơi bạn lưu instructions, conventions, và constraints để Claude tự nhớ mỗi session. Bài 2.7 sẽ đi vào chi tiết CLAUDE.md: hierarchy 3 cấp (project / user / nested), lệnh /init để bootstrap từ codebase hiện tại, syntax @ để compose multiple CLAUDE.md, và anti-patterns thường gặp khi viết file này. Và nếu bạn muốn hiểu sâu hơn về subagents — cách chúng fork context, chạy parallel, và coordinate với main agent — xem Bài 2.8: Subagents. ➡️ Bài tiếp theo: Bài 2.7 — File CLAUDE.md

​
Tài liệu tham khảo

  • Claude Code GitHub Actions — Official setup guide
  • Claude Code SDK — Foundation của GitHub Actions integration (open source)
  • Transcript “Building headless automation” — Demo Quiz app với @claude + GitHub issues → PRs
  • Transcript “A conversation on Claude Code” — Boris Cherny về /install github-action và @Claude, fix this pattern
  • Lệnh trong session: /agents, /commit-push-pr, /install github-action
  • CLI flag: claude —from-pr <PR_NUMBER>
  • Cross-reference: Bài 2.4 (commit phase trong EPCC), Bài 2.8 (subagents deeper dive), Bài 2.11 (hook auto-format trước commit)
Khoá học “Claude Code 101” — bản tiếng Việt v1.0Bản quyền 2026 Anthropic. Mọi quyền được bảo lưu.