Tự viết slash command cho Claude Code: biến prompt lặp lại thành lệnh một dòng

Có những prompt bạn gõ đi gõ lại mỗi ngày: "review diff đang stage theo chuẩn của team", "đọc issue #123 rồi sửa và viết test", "tóm tắt PR này cho reviewer". Mỗi lần gõ lại là một lần diễn đạt khác nhau, kết quả cũng khác nhau. Claude Code cho phép đóng gói những prompt đó thành custom slash command: một file Markdown trong repo, gọi bằng /ten-lenh, có tham số, có thể chạy shell để lấy dữ liệu thật trước khi gửi cho model. Bài này tóm tắt cách làm theo tài liệu chính thức và vài mẫu dùng được ngay.

Lệnh nằm ở đâu?

Theo tài liệu hiện tại, custom command đã được gộp vào skills: file trong .claude/commands/ vẫn chạy như cũ, nhưng với việc mới Anthropic khuyên dùng skill. Nếu một skill và một command trùng tên, skill thắng. Command vẫn là điểm khởi đầu nhẹ nhất: một file, không cần thư mục.

Cấu trúc một lệnh

Phần frontmatter YAML là tuỳ chọn, phần dưới là prompt:

---
description: Sửa một GitHub issue theo chuẩn của repo
argument-hint: [issue-number]
allowed-tools: Bash(gh issue view *) Bash(git *) Read Edit
model: sonnet
---

Đọc issue #$ARGUMENTS:
!`gh issue view $ARGUMENTS`

Sau đó:
1. Tóm tắt yêu cầu trong 3 dòng
2. Sửa code, viết test cho case trong issue
3. Chạy test, rồi tạo commit có tham chiếu issue

Tham số: $ARGUMENTS và $0, $1

• $ARGUMENTS: toàn bộ chuỗi sau tên lệnh. /fix-issue 123 → 123.
• $0, $1… (hoặc $ARGUMENTS[N]): tham số theo vị trí, đánh số từ 0. Tham số có dấu cách thì bọc trong nháy kép.
• Nếu prompt không có chỗ nhận tham số, Claude Code tự nối ARGUMENTS: … vào cuối.
• Cần ký tự $ thật (ví dụ giá tiền) thì viết \$.

Migrate component $0 từ $1 sang $2, giữ nguyên props public.
# gọi: /migrate-component SearchBar JavaScript TypeScript

Chạy shell trước khi gửi prompt

Cú pháp !`lệnh` chạy shell trước khi nội dung đến tay Claude, rồi thay chỗ đó bằng output. Model nhận dữ liệu thật thay vì phải tự đi tìm, tiết kiệm vài lượt tool call:

---
description: Tóm tắt PR hiện tại cho reviewer
allowed-tools: Bash(gh *)
---
- Diff: !`gh pr diff`
- File thay đổi: !`gh pr diff --name-only`

Tóm tắt PR: mục đích, thay đổi chính, rủi ro, điểm reviewer cần soi.

Ba điều cần nhớ:

• Lệnh lỗi (exit code khác 0) sẽ huỷ cả slash command. Nếu chấp nhận lỗi, thêm || true.
• Lệnh vẫn đi qua quy tắc quyền: bị deny thì huỷ; cần hỏi thì cũng huỷ, trừ khi đã cho phép sẵn trong allowed-tools.
• Admin có thể tắt hẳn tính năng này bằng "disableSkillShellExecution": true trong settings.

5 lệnh đáng tạo ngay

1. /review: lấy git diff --staged, review theo checklist của team (bảo mật, đặt tên, test).
2. /fix-issue: như ví dụ trên, đọc issue → sửa → test → commit.
3. /pr-summary: tóm tắt PR để dán vào mô tả.
4. /changelog: lấy git log từ tag gần nhất, viết changelog theo format của repo.
5. /explain: giải thích một module cho người mới, kèm sơ đồ luồng gọi chính.

Rủi ro và lưu ý

• allowed-tools quá rộng: Bash(*) trong một lệnh commit chung là mở cửa cho mọi lệnh shell. Ghi càng hẹp càng tốt, ví dụ Bash(gh pr diff *).
• Dữ liệu không tin cậy: nội dung issue/PR do người ngoài viết có thể chứa prompt injection. Lệnh tự động hoá trên dữ liệu đó không nên kèm quyền ghi rộng.
• Prompt phình to: gh pr diff của PR lớn có thể chiếm hàng chục nghìn token. Giới hạn bằng | head -n 2000 hoặc chỉ lấy danh sách file.
• Trùng tên với skill: khi chuyển dần sang skill, xoá file command cũ để tránh nhầm lệnh nào đang chạy.

Áp dụng thế nào?

• Dev: Mỗi khi gõ cùng một prompt lần thứ ba, chuyển nó thành file trong .claude/commands/. Bắt đầu bằng 2–3 lệnh, đừng làm cả bộ một lúc.
• Tech Lead: Commit các lệnh chuẩn (review, fix-issue, changelog) vào repo để cả team có cùng quy trình. Review file lệnh như review code, nhất là dòng allowed-tools.
• PM: Lệnh /pr-summary và /changelog giúp release note nhất quán mà không cần đọc diff.