Bỏ qua để đến nội dung

Thư viện prompt

Tuyển tập prompt dùng được ngay, xếp theo giai đoạn của một vòng phát triển: khám phá → thiết kế → xây dựng → phát hành → vận hành. Phần trong {...} là chỗ bạn thay bằng thông tin của mình (giá trị trong ví dụ chỉ để minh hoạ).

Mỗi prompt có hai phiên bản - Tiếng Việt và English - chọn tab rồi bấm icon copy ở góc khối code để sao chép nguyên văn.

Đọc cùng Best practicesQuy trình thường gặp để hiểu vì sao các prompt này hiệu quả.

Làm quen repo mới

cho tôi tổng quan codebase này: kiến trúc, các thư mục chính, và các phần ghép với nhau ra sao

Mô tả điều bạn muốn biết, không phải file cần đọc. Claude tự khám phá và trả về bản tóm tắt.


Giải thích code lạ

giải thích {src/scheduler/queue.ts} làm gì và dữ liệu chảy qua nó thế nào. Viết ra dưới dạng {một trang HTML có sơ đồ, rồi mở trong browser}

Nêu file định dạng câu trả lời bạn muốn.


Tìm nơi xử lý một hành vi

chúng ta {kiểm tra loại file được upload} ở đâu?

Tìm theo hành vi thay vì theo tên file - dùng được cả khi bạn không biết file tên gì.


Kiểm tra trước khi xoá

nếu tôi xoá {hàm retryWithBackoff} thì cái gì sẽ hỏng?

Danh sách nơi gọi và ảnh hưởng lan toả cho biết đây là dọn dẹp một dòng hay một thay đổi cần phối hợp.


Truy vết code hình thành thế nào

đọc lịch sử commit của {internal/auth/session.go} và tóm tắt nó đã tiến hoá ra sao và vì sao

Trỏ tới commit history khi câu hỏi là vì sao, không phải cái gì.


Ước lượng phạm vi thay đổi

lên kế hoạch {thêm dark mode toggle vào settings} thì cần sửa gì?

Danh sách file cho biết đây là một component hay một thay đổi xuyên suốt.


Hỏi câu hỏi sản phẩm

tôi là {PM}. Dẫn tôi qua những gì xảy ra khi user {bấm Export to PDF}, từ UI xuống tới kết quả

Nêu vai trò của bạn để câu trả lời được đặt ở đúng tầng.

Lập kế hoạch thay đổi nhiều file

lên kế hoạch refactor {module payment} để {hỗ trợ nhiều loại tiền tệ}. Liệt kê các file bạn sẽ sửa, nhưng chưa sửa gì cả

Thêm “chưa sửa gì” tách khám phá khỏi thay đổi. Muốn mặc định như vậy: nhấn Shift+Tab vào plan mode.


Viết spec bằng phỏng vấn

tôi muốn xây {rate limit theo từng workspace}. Hãy phỏng vấn tôi về cách triển khai, UX, edge case và các đánh đổi đến khi bao hết mọi thứ, rồi viết spec vào SPEC.md

Nhờ được phỏng vấn thay vì tự viết spec - Claude hỏi có cấu trúc đến khi yêu cầu đủ rõ.


Biến biên bản họp thành ticket

đọc {@meeting-notes.md} và viết ra các action item, rồi tạo một ticket {Linear} cho mỗi cái kèm acceptance criteria

Bỏ qua bước chép tay. Cần MCP kết nối tracker.


Vạch edge case trước khi làm

liệt kê các error state, empty state và edge case của {luồng upload file} mà thiết kế cần bao

Hỏi cái còn thiếu, không phải cái đang có.


Mockup → prototype chạy được

[dán mockup]
dựng một prototype tôi bấm thử được, khớp layout và các trạng thái trong ảnh

Prototype bấm được trả lời những câu hỏi mockup tĩnh không trả lời được.


Triển khai từ ảnh thiết kế

[dán thiết kế]
triển khai thiết kế này, rồi chụp ảnh kết quả, so với ảnh gốc và sửa các khác biệt

Tạo cho Claude một vòng lặp tự kiểm chứng: render → so sánh → sửa, không cần bạn chỉ từng chỗ.

Theo pattern có sẵn

xem {webhook handler của GitHub} được triển khai thế nào để hiểu pattern, rồi làm {webhook handler cho Stripe} theo đúng cách đó

Không có mẫu tham chiếu, Claude dùng “best practice” chung. Có mẫu, nó khớp đúng quy ước codebase bạn.


Tính năng nhỏ, rõ ràng

thêm endpoint {/health} trả về {version của app và uptime}

Nêu input/output, đừng nêu cách xây.


Công cụ nội bộ nhỏ

tạo {một Kanban board kéo-thả có ba cột} bằng HTML, CSS và vanilla JavaScript, rồi mở trong browser

Không cần project, framework hay build step.


Làm một issue trọn vẹn

đọc issue #{312}, triển khai bản sửa, và chạy test

Đưa số issue thay vì bản tóm tắt - Claude tự đọc full ticket nên không bỏ sót yêu cầu.


Sinh tài liệu cho code

tìm {các hàm public trong src/auth/} chưa có comment {JSDoc} và thêm vào, khớp style đang dùng trong file

Nêu phạm vi định dạng.


Sửa copy khắp codebase

tìm mọi nơi viết "{Sign up free}" hoặc biến thể gần giống, cho tôi xem từng chỗ kèm ngữ cảnh, rồi đổi hết thành "{Start free trial}". Đừng đụng vào test và changelog

Yêu cầu cả biến thể và nói rõ cái gì bỏ qua.


Viết bản nháp theo mẫu cũ

đọc {các privacy impact assessment} trong {legal/pia/} để học cấu trúc và văn phong, rồi viết một bản mới cho {tích hợp analytics mới}

Trỏ tới một thư mục công việc đã hoàn thiện thay vì mô tả văn phong bằng lời.

Viết test, chạy, sửa lỗi

viết test cho {app/parsers/feed.py}, chạy chúng, và sửa các test fail

Gộp cả viết + chạy + sửa vào một prompt để Claude tự lặp, không dừng lại chờ chỉ dẫn.


TDD

viết test cho {luồng reset password} trước, rồi triển khai đến khi test pass

Test định nghĩa thời điểm công việc hoàn tất.


Lấp lỗ hổng từ báo cáo coverage

đọc {coverage/coverage-summary.json} và thêm test cho các file coverage thấp nhất đến khi mỗi file trên {80}%

Trỏ tới báo cáo thật thay vì đoán xem cái gì chưa có test.

Migrate một pattern

migrate mọi thứ từ {logging API cũ} sang {structured logger}: xác định mọi nơi cần đổi, rồi thực hiện

Yêu cầu liệt kê trước nghĩa là các call site nằm trong câu trả lời - bạn kiểm được có bỏ sót không.


Port sang ngôn ngữ khác

port {module Python này} sang {Rust}, giữ nguyên {public API và hành vi test}

Nói rõ cái gì phải giữ nguyên, không chỉ nói ngôn ngữ đích.


Tối ưu theo mục tiêu đo được

tối ưu {query search} để đưa {p95 latency} từ {2s} xuống dưới {500ms}

Nêu chỉ số và ngưỡng → định nghĩa “xong” không còn mơ hồ.


Sửa bug hiển thị chính xác

{nút login} tràn {20px} khỏi {viền card} trên {mobile}. Sửa đi.

Phản hồi hình ảnh chính xác cho ra bản sửa chính xác: nêu đúng element, số đo, viewport.

Review trước khi commit

review các thay đổi chưa commit của tôi và chỉ ra thứ gì trông rủi ro trước khi tôi commit

Claude đọc toàn bộ file đã đổi, không chỉ các dòng diff - nên bắt được thứ tự review nhanh bỏ sót. Lệnh tương đương: /code-review.


Review pull request

review PR #{247} và tóm tắt những gì đã đổi, rồi liệt kê các điểm đáng lo

Claude review với cả codebase trong ngữ cảnh, không chỉ diff.


Review thay đổi hạ tầng

[dán output terraform plan]
cái này sẽ làm gì, và có gì ở đây gây vấn đề không?

Output plan dày và khó đọc - dán vào để nhận bản diễn giải bằng lời trước khi apply.


Review bảo mật

dùng một subagent review {src/api/} về các vấn đề bảo mật và báo lại những gì tìm được

Subagent chạy trong ngữ cảnh riêng nên một lượt audit dài không làm đầy phiên chính.


Review nội dung trước khi gửi

review {launch-post.md} về {các tuyên bố thiếu căn cứ, thiếu ghi nguồn, và vấn đề brand guideline} và liệt kê những gì tôi nên sửa trước khi gửi cho {legal}

Nêu rõ các mối quan tâm để lượt review có trọng tâm.

Sửa hướng tiếp cận sai

chưa đúng: {chữ ký hàm phải giữ tương thích ngược}. Thử cách khác đi

Nêu ràng buộc Claude bỏ sót, không chỉ nói “sai” - cho nó một điều kiện cụ thể để thoả mãn ở lần thử lại.


Thu hẹp phạm vi thay đổi

nhiều quá. Chỉ giữ các thay đổi ở {logic validation trong src/forms/} và hoàn tác phần còn lại

Khi hướng đúng nhưng thay đổi quá rộng - giữ một phần thay vì tua lại tất cả.


Biến một lần sửa thành quy tắc

bạn cứ {dùng default export trong khi dự án này dùng named export}. Thêm một quy tắc vào CLAUDE.md để việc này không xảy ra nữa

Một lời sửa trong chat không chia sẻ được cho team; một quy tắc trong CLAUDE.md thì có, và được đọc ở đầu mỗi phiên.

Giải quyết merge conflict

giải quyết merge conflict trong branch này và giải thích bạn giữ gì từ mỗi bên

Nêu trạng thái bạn muốn, không nêu marker nào cần giữ. Yêu cầu giải thích để lượt merge có thể review được.


Commit với message tự sinh

commit các thay đổi này với message tóm tắt những gì tôi đã làm

Claude suy ra message từ diff và khớp style commit hiện có của repo.


Mở PR từ một ticket

tìm ticket {Linear} về {timeout khi login} và mở một PR triển khai nó

Bỏ được các lần chuyển ngữ cảnh giữa tracker, editor và GitHub.


Viết release notes từ git

so sánh {v2.3.0} với {v2.4.0} và viết release notes nhóm theo feature, fix và breaking change

Đưa hai mốc tham chiếu và cấu trúc bạn muốn.


Viết CI workflow

viết một GitHub Actions workflow {chạy test và deploy lên staging} mỗi lần push vào {main}

Mô tả khi nào chạy và làm gì; YAML được sinh khớp với lệnh build/test của dự án.

Tìm và sửa test fail

test {UserAuth} đang fail, tìm nguyên nhân và sửa

Mô tả triệu chứng; bạn không cần biết file nào hỏng. Claude chạy test để thấy lỗi, truy vào source rồi sửa.


Điều tra lỗi được báo

user đang thấy {lỗi 500} ở {/api/settings}. Điều tra và cho tôi biết chuyện gì đang xảy ra

Nêu triệu chứng và vị trí; dán stack trace/log nếu có.


Sửa lỗi build tận gốc

[dán lỗi build]
sửa nguyên nhân gốc và xác nhận build thành công

Yêu cầu “nguyên nhân gốc + kiểm chứng” ngăn kiểu vá bề mặt chỉ làm lỗi im đi.

Điều tra sự cố production

{endpoint checkout bắt đầu trả 500 từ một tiếng trước}. Kiểm tra log, các lần deploy gần đây và thay đổi config, rồi cho tôi biết nguyên nhân khả dĩ nhất

Liệt kê các nguồn bằng chứng cần đối chiếu, không liệt kê các bước cần làm.


Chẩn đoán từ ảnh console

[dán screenshot]
đây là ảnh {GCP Kubernetes dashboard}. Giải thích vì sao {pod này} lỗi và cho tôi đúng các lệnh để sửa

Cloud console cho thấy vấn đề nhưng không cho lệnh sửa - Claude dịch dashboard thành lệnh kubectl/gcloud/aws.


Truy vấn log bằng tiếng nói tự nhiên

cho tôi xem mọi {lần login thất bại} của {auth service} trong {24 giờ qua}. Viết query, chạy nó, và cho tôi biết điều gì đáng chú ý

Hỏi câu hỏi thay vì viết SQL. Claude cho xem cả query lẫn kết quả để bạn kiểm được cái gì đã chạy.

Phân tích một file dữ liệu

đọc {@reports/q1-signups.csv}, tóm tắt các pattern chính, và ghi kết quả ra {một trang HTML có biểu đồ, rồi mở trong browser}

Một câu hỏi dùng-một-lần không cần một script dùng-một-lần.


Sinh biến thể từ dữ liệu hiệu năng

đọc {@ads-performance.csv}, tìm các {headline} kém hiệu quả, và sinh {20} biến thể mới dưới {90} ký tự

Nêu ràng buộc ngay từ đầu để phần sinh ra nằm trong giới hạn.

Biến việc lặp lại thành skill

tạo một skill /{ship} cho dự án này, {chạy linter và test, rồi viết nháp commit message}

Nêu các bước một lần; tái dùng như một lệnh.


Thêm hook cho hành vi lặp

viết một hook {chạy prettier} sau mỗi lần {sửa file .ts hoặc .tsx}

Hooks biến một hành vi thành tự động, thay vì thứ bạn phải nhớ để yêu cầu.


Kết nối một tool qua MCP

cài {MCP server của Sentry} để bạn đọc được {báo cáo lỗi} của tôi trực tiếp

Kết nối nguồn một lần thay vì dán dữ liệu mỗi phiên. Xem MCP.


Ghi lại điều cần nhớ

tóm tắt những gì chúng ta đã làm trong phiên này và đề xuất nội dung thêm vào CLAUDE.md

Hỏi trước khi bạn quên - Claude biết nó đã phải tự mò ra những gì trong phiên.

Các prompt trên có chung vài pattern. Nhận ra chúng giúp bạn tự chỉnh mọi prompt ở đây cho việc của mình.

Mô tả kết quả, không mô tả các bước. Nói bạn muốn gì và để Claude tự tìm file.

thêm rate limiting cho public API và bảo đảm các test hiện có vẫn pass

Cho nó cách tự kiểm chứng. Yêu cầu chạy, test, so sánh, xác nhận ngay trong cùng prompt để Claude tự lặp thay vì dừng sau một lần thử.

viết migration, chạy nó trên dev database, và xác nhận schema khớp

Trỏ tới một mẫu tham chiếu. Nêu file, test hoặc pattern cần khớp để code mới nhất quán với những gì bạn đã có.

thêm trang settings theo đúng layout của trang profile

Nêu mục tiêu đo được. Khi mục tiêu là hiệu năng hay coverage, hãy đưa chỉ số và ngưỡng để việc “hoàn thành” không còn mơ hồ.

đưa bundle size xuống dưới 200KB và cho tôi xem bạn đã bỏ những gì

Đưa nguyên vật liệu thật. Dán lỗi, log, screenshot, output plan trực tiếp vào prompt, hoặc gõ @ để tham chiếu file. Claude đọc nguồn thay vì đọc bản mô tả của bạn về nguồn.

vì sao build fail? @build.log

Nói rõ bạn muốn câu trả lời thế nào. Nêu định dạng, độ dài, hoặc đối tượng đọc để phần giải thích khớp với cách bạn sẽ dùng nó.

giải thích logic retry thanh toán dưới dạng một trang HTML có sơ đồ, rồi mở trong browser

Các prompt ở đây là điểm khởi đầu. Khi một prompt đã hiệu quả với dự án của bạn, bước tiếp theo là làm nó lặp lại được: lưu thành một skill để cả team chạy như một /command, và ghi các quy ước Claude đã học vào CLAUDE.md để mỗi phiên bắt đầu với ngữ cảnh đó thay vì Claude học lại từ đầu.