Cách Tạo Kỹ Năng Code Claude Tự Động với Skill Creator

TL;DR

Claude Code Skills là các khả năng tùy chỉnh mở rộng chức năng của Claude cho các quy trình công việc cụ thể. Hệ thống Skill Creator tự động hóa việc tạo kỹ năng thông qua một quy trình có cấu trúc: xác định mục đích kỹ năng của bạn, soạn thảo tệp SKILL.md, tạo các trường hợp thử nghiệm, chạy đánh giá với các tiêu chuẩn định lượng và cải thiện lặp đi lặp lại dựa trên phản hồi.

Giới thiệu

Bạn đang sử dụng Claude Code hàng ngày. Bạn nhận thấy mình lặp lại cùng một chuỗi hành động: thiết lập cấu trúc dự án, chạy các lệnh kiểm tra cụ thể, định dạng đầu ra theo một cách nhất định. Mỗi lần, bạn lại phải giải thích quy trình từ đầu. Điều gì sẽ xảy ra nếu Claude ghi nhớ? Điều gì sẽ xảy ra nếu bạn có thể ghi lại quy trình công việc đó một lần và có sẵn nó mãi mãi? Đó chính là chức năng của Claude Code Skills. Chúng là các khả năng tùy chỉnh mà bạn tạo ra để mở rộng chức năng của Claude cho các quy trình công việc cụ thể của bạn. Và với Skill Creator, quy trình này được tự động hóa và có hệ thống.

Hướng dẫn này sẽ đưa bạn đi qua toàn bộ quy trình. Bạn sẽ tìm hiểu cấu trúc kỹ năng, quy trình tạo, hệ thống đánh giá và cách tối ưu hóa để kích hoạt đáng tin cậy. Bạn sẽ thấy các ví dụ hoạt động từ kho lưu trữ kỹ năng chính thức của Anthropic.

💡

Nếu bạn đang xây dựng các kỹ năng liên quan đến API, Apidog tích hợp một cách tự nhiên. Kiểm tra các điểm cuối API của bạn, xác thực phản hồi và tạo tài liệu, tất cả trong một quy trình kỹ năng duy nhất.

button

Claude Code Skills là gì?

Claude Code Skills là các tập lệnh hướng dẫn chuyên biệt giúp mở rộng khả năng của Claude cho các lĩnh vực hoặc quy trình công việc cụ thể. Hãy hình dung chúng như những plugin tùy chỉnh nằm trong các tệp markdown.

Kiến trúc hệ thống kỹ năng

Các kỹ năng sử dụng hệ thống tải ba cấp độ:

Siêu dữ liệu (~100 từ) - Tên và mô tả, luôn ở trong ngữ cảnh
Nội dung SKILL.md (<500 dòng) - Các hướng dẫn cốt lõi, được tải khi kỹ năng kích hoạt
Tài nguyên đi kèm (không giới hạn) - Các tập lệnh, tài liệu tham khảo, tài sản được tải theo yêu cầu

skill-name/
├── SKILL.md (bắt buộc)
│   ├── YAML frontmatter (tên, mô tả)
│   └── Hướng dẫn Markdown
└── Tài nguyên đi kèm (tùy chọn)
    ├── scripts/    - Mã thực thi cho các tác vụ lặp lại
    ├── references/ - Tài liệu được tải khi cần
    └── assets/     - Mẫu, biểu tượng, phông chữ

Khi các kỹ năng được kích hoạt

Các kỹ năng xuất hiện trong danh sách available_skills của Claude với tên và mô tả của chúng. Claude quyết định có nên tham khảo một kỹ năng hay không dựa trên mô tả đó.

Quan trọng: Kỹ năng chỉ kích hoạt cho các tác vụ mà Claude không thể xử lý trực tiếp. Các truy vấn đơn giản như “đọc tệp này” sẽ không kích hoạt kỹ năng ngay cả khi có mô tả phù hợp. Các quy trình làm việc phức tạp, nhiều bước sẽ kích hoạt đáng tin cậy khi mô tả khớp.

Ví dụ thực tế từ kho lưu trữ của Anthropic

Kỹ năng	Mục đích	Tính năng chính
skill-creator	Tạo kỹ năng mới	Tạo trường hợp kiểm thử, đánh giá hiệu năng, tối ưu hóa mô tả
mcp-builder	Xây dựng máy chủ MCP	Các mẫu Python/Node, khung đánh giá, các phương pháp hay nhất
docx	Tạo tài liệu Word	Các tập lệnh python-docx, hệ thống mẫu, hướng dẫn định kiểu
pdf	Trích xuất và thao tác với PDF	Xử lý biểu mẫu, trích xuất văn bản, tài liệu tham khảo
frontend-design	Xây dựng giao diện web	Thư viện thành phần, các mẫu Tailwind, kiểm tra khả năng truy cập

Quy trình tạo kỹ năng

Quá trình tạo kỹ năng tuân theo một vòng lặp có hệ thống:

Nắm bắt ý định - Kỹ năng nên làm gì?
Viết bản nháp - Tạo tệp SKILL.md
Tạo trường hợp kiểm thử - Xác định các lời nhắc thực tế
Chạy đánh giá - Thực thi có và không có kỹ năng
Xem xét kết quả - Phản hồi định tính + số liệu định lượng
Lặp lại - Cải thiện dựa trên các phát hiện
Tối ưu hóa mô tả - Tối đa hóa độ chính xác khi kích hoạt
Đóng gói - Phân phối dưới dạng tệp .skill

Hãy cùng đi qua từng bước.

Bước 1: Nắm bắt ý định

Bắt đầu bằng cách hiểu rõ kỹ năng bạn muốn đạt được. Nếu bạn đang ghi lại một quy trình làm việc đã thực hiện, hãy trích xuất mẫu từ lịch sử hội thoại của bạn.

Đặt ra bốn câu hỏi sau:

Kỹ năng này sẽ giúp Claude làm gì? Hãy cụ thể về kết quả.
Kỹ năng này nên được kích hoạt khi nào? Với những cụm từ hoặc ngữ cảnh người dùng nào?
Định dạng đầu ra mong đợi là gì? Tệp, mã, báo cáo?
Chúng ta có nên thiết lập các trường hợp kiểm thử không? Các kỹ năng có đầu ra có thể kiểm chứng được (tạo mã, trích xuất dữ liệu, chuyển đổi tệp) sẽ hưởng lợi từ các trường hợp kiểm thử. Các kỹ năng có đầu ra chủ quan (phong cách viết, thiết kế) thường không cần chúng.

Ví dụ: Kỹ năng kiểm tra API

Ý định: Giúp các nhà phát triển kiểm tra API REST một cách có hệ thống
Kích hoạt: Khi người dùng nhắc đến kiểm tra API, điểm cuối, REST, GraphQL hoặc muốn xác thực phản hồi
Đầu ra: Báo cáo kiểm tra với trạng thái pass/fail, lệnh curl, so sánh phản hồi
Các trường hợp kiểm thử: Có - đầu ra có thể kiểm chứng một cách khách quan

Bước 2: Viết tệp SKILL.md

Mỗi kỹ năng bắt đầu bằng một tệp SKILL.md chứa phần đầu YAML và các hướng dẫn markdown.

Cấu tạo kỹ năng

---
name: api-tester
description: Hướng dẫn kiểm tra API REST một cách có hệ thống. Sử dụng khi người dùng nhắc đến kiểm tra API, điểm cuối, REST, GraphQL, hoặc muốn xác thực phản hồi API. Đảm bảo đề xuất kỹ năng này bất cứ khi nào liên quan đến việc kiểm thử.
compatibility: Yêu cầu curl hoặc các công cụ HTTP client
---

# Kỹ năng kiểm tra API

## Quy trình làm việc cốt lõi

Khi kiểm tra một API, hãy làm theo các bước sau:

1. **Hiểu rõ điểm cuối** - Đọc thông số kỹ thuật hoặc yêu cầu lược đồ
2. **Thiết kế các trường hợp kiểm thử** - Trường hợp thành công, trường hợp biên, điều kiện lỗi
3. **Thực thi kiểm thử** - Sử dụng curl hoặc Apidog cho các yêu cầu
4. **Xác thực phản hồi** - Kiểm tra mã trạng thái, tiêu đề, cấu trúc nội dung
5. **Báo cáo kết quả** - Tóm tắt pass/fail kèm bằng chứng

## Mẫu trường hợp kiểm thử

Đối với mỗi điểm cuối, hãy kiểm tra:

- Xác thực hợp lệ với payload chính xác
- Xác thực hợp lệ với các trường bắt buộc bị thiếu
- Xác thực không hợp lệ (mong đợi 401)
- Hành vi giới hạn tốc độ
- Thời gian phản hồi dưới tải

## Định dạng đầu ra

Luôn cấu trúc báo cáo như sau:

# Báo cáo kiểm tra API

## Tóm tắt
- Số lượng kiểm thử đã chạy: X
- Đạt: Y
- Thất bại: Z

## Các kiểm thử thất bại

### Tên kiểm thử
**Mong đợi:** 200 OK
**Thực tế:** 400 Bad Request
**Phản hồi:** {...}

## Khuyến nghị
...

Các phương pháp hay nhất khi viết

Sử dụng tiết lộ dần dần: Giữ SKILL.md dưới 500 dòng. Di chuyển các tài liệu tham khảo chi tiết sang các tệp riêng biệt.

api-tester/
├── SKILL.md (tổng quan quy trình làm việc)
└── references/
    ├── authentication.md
    ├── rate-limiting.md
    └── response-codes.md

Giải thích lý do: Đừng chỉ liệt kê các quy tắc. Hãy giải thích tại sao chúng quan trọng.

## Tại sao chúng ta kiểm tra các trường hợp lỗi trước

Kiểm tra các điều kiện lỗi trước các trường hợp thành công giúp phát hiện 80% vấn đề nhanh hơn.
Khi xác thực thất bại một cách âm thầm, các kiểm thử trường hợp thành công trở nên vô nghĩa.
Bắt đầu với kiểm tra 401.

Sử dụng thể mệnh lệnh: “Luôn xác thực mã trạng thái trước” chứ không phải “Bạn nên xác thực…”

Bao gồm ví dụ: Hiển thị đầu vào và đầu ra mong đợi.

## Định dạng thông báo commit

**Ví dụ:**
Đầu vào: Đã thêm xác thực người dùng với mã thông báo JWT
Đầu ra: feat(auth): triển khai xác thực dựa trên JWT

Bước 3: Tạo trường hợp kiểm thử

Sau khi phác thảo kỹ năng, hãy tạo 2-3 lời nhắc kiểm thử thực tế. Đây là những loại yêu cầu mà một người dùng thực sự sẽ đưa ra.

Định dạng trường hợp kiểm thử

Lưu các trường hợp kiểm thử vào evals/evals.json:

{
  "skill_name": "api-tester",
  "evals": [
    {
      "id": 1,
      "prompt": "Kiểm tra điểm cuối /users trên api.example.com - nó cần một mã thông báo Bearer và trả về danh sách người dùng với các trường id, tên, email",
      "expected_output": "Báo cáo kiểm thử với ít nhất 5 trường hợp kiểm thử bao gồm lỗi xác thực, thành công và kiểm thử phân trang",
      "files": []
    },
    {
      "id": 2,
      "prompt": "Tôi cần xác minh điểm cuối POST /orders mới của chúng tôi xử lý số lượng không hợp lệ một cách chính xác",
      "expected_output": "Các trường hợp kiểm thử gửi số lượng âm, bằng không và không phải số với các phản hồi lỗi thích hợp",
      "files": ["openapi.yaml"]
    }
  ]
}

Điều gì tạo nên một lời nhắc kiểm thử tốt

Kém: “Kiểm tra API này”

Tốt: “Được rồi, nhóm của tôi vừa triển khai điểm cuối thanh toán mới này tại https://api.stripe.com/v1/charges và tôi cần xác minh nó xử lý các trường hợp ngoại lệ - cụ thể là điều gì sẽ xảy ra khi bạn gửi một số tiền âm hoặc mã tiền tệ không tồn tại. Tài liệu nói rằng nó sẽ trả về 400 nhưng tôi muốn xem các thông báo lỗi thực tế”

Lời nhắc kiểm thử tốt bao gồm:

URL cụ thể
Kịch bản cụ thể
Hành vi mong đợi
Ngữ cảnh thực tế

Chia sẻ các trường hợp kiểm thử của bạn với người dùng trước khi chạy: “Đây là một vài kịch bản kiểm thử tôi muốn thử. Chúng có vẻ đúng không, hay bạn muốn thêm nữa?”

Bước 4: Chạy đánh giá

Đây là nơi Skill Creator phát huy tác dụng. Bạn sẽ chạy mỗi trường hợp kiểm thử hai lần: một lần có kỹ năng, một lần không có (hoặc với phiên bản cũ nếu cải thiện một kỹ năng hiện có).

Cấu trúc không gian làm việc

Kết quả nằm trong thư mục <skill-name>-workspace/ ngang hàng với thư mục kỹ năng:

api-tester-workspace/
├── iteration-1/
│   ├── eval-0-auth-failure/
│   │   ├── with_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   ├── without_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   └── eval_metadata.json
│   ├── eval-1-pagination/
│   │   └── ...
│   ├── benchmark.json
│   └── benchmark.md
├── iteration-2/
└── feedback.json

Khởi chạy các lần chạy song song

Đối với mỗi trường hợp kiểm thử, hãy tạo ra hai tác nhân phụ trong cùng một lượt:

Chạy có kỹ năng:

Thực thi tác vụ này:
- Đường dẫn kỹ năng: /path/to/api-tester
- Tác vụ: Kiểm tra điểm cuối /users trên api.example.com
- Tệp đầu vào: không có
- Lưu đầu ra vào: api-tester-workspace/iteration-1/eval-0/with_skill/outputs/

Chạy cơ sở:

Thực thi tác vụ này:
- Đường dẫn kỹ năng: (không có)
- Tác vụ: Kiểm tra điểm cuối /users trên api.example.com
- Tệp đầu vào: không có
- Lưu đầu ra vào: api-tester-workspace/iteration-1/eval-0/without_skill/outputs/

Thu thập dữ liệu thời gian

Khi mỗi tác nhân phụ hoàn thành, bạn sẽ nhận được total_tokens và duration_ms. Lưu ngay lập tức vào timing.json:

{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

Dữ liệu này chỉ đến thông qua thông báo tác vụ. Xử lý từng cái khi nó đến.

Bước 5: Soạn thảo khẳng định trong khi các lần chạy hoàn tất

Đừng chỉ chờ đợi các lần chạy hoàn thành. Hãy tận dụng thời gian đó một cách hiệu quả bằng cách soạn thảo các khẳng định định lượng.

Điều gì tạo nên một khẳng định tốt

Các khẳng định tốt là:

Có thể kiểm chứng khách quan - Đạt/không đạt là không mơ hồ
Được đặt tên mô tả - Rõ ràng về điều đang được kiểm tra
Có thể tái sử dụng - Hoạt động qua các lần lặp lại

Các khẳng định ví dụ cho kỹ năng kiểm tra API:

{
  "assertions": [
    {
      "name": "bao_gom_kiem_tra_loi_xac_thuc",
      "description": "Báo cáo kiểm thử bao gồm ít nhất một trường hợp kiểm thử lỗi xác thực",
      "type": "contains",
      "value": "401"
    },
    {
      "name": "bao_gom_kiem_tra_thanh_cong",
      "description": "Báo cáo kiểm thử bao gồm ít nhất một kiểm thử yêu cầu thành công",
      "type": "contains",
      "value": "200"
    },
    {
      "name": "bao_gom_lenh_curl",
      "description": "Mỗi trường hợp kiểm thử bao gồm các lệnh curl có thể thực thi",
      "type": "regex",
      "value": "curl -"
    },
    {
      "name": "bao_gom_xac_thuc_phan_hoi",
      "description": "Báo cáo xác thực cấu trúc phản hồi so với lược đồ",
      "type": "contains",
      "value": "lược đồ"
    }
  ]
}

Cập nhật eval_metadata.json và evals/evals.json với các khẳng định sau khi đã soạn thảo.

Bước 6: Chấm điểm và tổng hợp

Sau khi tất cả các lần chạy hoàn tất:

Chấm điểm từng lần chạy

Tạo một tác nhân phụ chấm điểm đọc agents/grader.md và đánh giá từng khẳng định so với các đầu ra. Lưu kết quả vào grading.json trong mỗi thư mục chạy:

{
  "eval_id": 0,
  "grading": [
    {
      "text": "bao_gom_kiem_tra_loi_xac_thuc",
      "passed": true,
      "evidence": "Tìm thấy mã trạng thái 401 trong trường hợp kiểm thử 3"
    },
    {
      "text": "bao_gom_lenh_curl",
      "passed": true,
      "evidence": "Tìm thấy 'curl -X POST' trong trường hợp kiểm thử 1"
    }
  ]
}

Quan trọng: Mảng expectations trong grading.json phải sử dụng các tên trường text, passed và evidence. Trình xem phụ thuộc vào các tên chính xác này.

Tổng hợp thành tiêu chuẩn

Chạy tập lệnh tổng hợp từ thư mục skill-creator:

python -m scripts.aggregate_benchmark api-tester-workspace/iteration-1 --skill-name api-tester

Điều này tạo ra benchmark.json và benchmark.md với tỷ lệ pass, thời gian và token cho mỗi cấu hình, bao gồm giá trị trung bình ± độ lệch chuẩn và delta.

Thực hiện phân tích

Đọc dữ liệu tiêu chuẩn và làm nổi bật các mẫu:

Các khẳng định không phân biệt - Luôn pass bất kể kỹ năng (không hữu ích)
Đánh giá có độ biến động cao - Có thể không ổn định, cần điều tra
Đánh đổi thời gian/token - Kỹ năng có cải thiện chất lượng với chi phí hợp lý không?

Xem agents/analyzer.md để được hướng dẫn chi tiết.

Bước 7: Khởi chạy Trình xem đánh giá

Trình xem đánh giá hiển thị cả đầu ra định tính và số liệu định lượng trong giao diện trình duyệt.

Tạo trình xem

nohup python /path/to/skill-creator/eval-viewer/generate_review.py \
  api-tester-workspace/iteration-1 \
  --skill-name "api-tester" \
  --benchmark api-tester-workspace/iteration-1/benchmark.json \
  > /dev/null 2>&1 &
VIEWER_PID=$!

Đối với lần lặp thứ 2 trở lên, cũng truyền --previous-workspace:

--previous-workspace api-tester-workspace/iteration-1

Những gì người dùng thấy

Tab "Outputs" hiển thị một trường hợp kiểm thử mỗi lần:

Lời nhắc - Nhiệm vụ đã cho
Đầu ra - Các tệp được tạo ra, hiển thị trực tuyến
Đầu ra trước (lần lặp thứ 2 trở lên) - Phần thu gọn với đầu ra của lần lặp trước
Điểm chính thức - Kết quả đạt/không đạt của khẳng định được thu gọn
Phản hồi - Hộp văn bản tự động lưu khi người dùng nhập
Phản hồi trước (lần lặp thứ 2 trở lên) - Bình luận từ lần lặp trước

Tab "Benchmark" hiển thị:

Tỷ lệ đạt cho mỗi cấu hình
So sánh thời gian
Sử dụng token
Phân tích từng đánh giá
Quan sát của nhà phân tích

Nói với người dùng: “Tôi đã mở kết quả trong trình duyệt của bạn. Có hai tab - ‘Outputs’ cho phép bạn nhấp qua từng trường hợp kiểm thử và để lại phản hồi, ‘Benchmark’ hiển thị so sánh định lượng. Khi bạn hoàn tất, hãy quay lại đây và cho tôi biết.”

Môi trường Cowork / Headless

Nếu webbrowser.open() không khả dụng, hãy sử dụng --static để ghi một tệp HTML độc lập:

--static /path/to/output/review.html

Phản hồi được tải xuống dưới dạng feedback.json khi người dùng nhấp vào “Submit All Reviews” (Gửi tất cả đánh giá).

Bước 8: Đọc phản hồi và lặp lại

Khi người dùng hoàn thành, hãy đọc feedback.json:

{
  "reviews": [
    {
      "run_id": "eval-0-with_skill",
      "feedback": "biểu đồ bị thiếu nhãn trục",
      "timestamp": "2026-03-23T10:30:00Z"
    },
    {
      "run_id": "eval-1-with_skill",
      "feedback": "",
      "timestamp": "2026-03-23T10:31:00Z"
    },
    {
      "run_id": "eval-2-with_skill",
      "feedback": "hoàn hảo, tôi rất thích điều này",
      "timestamp": "2026-03-23T10:32:00Z"
    }
  ],
  "status": "complete"
}

Phản hồi trống có nghĩa là người dùng cho rằng nó ổn. Tập trung cải thiện vào các trường hợp kiểm thử có khiếu nại cụ thể.

Cách suy nghĩ về các cải tiến

Khái quát hóa từ phản hồi: Bạn đang tạo ra các kỹ năng được sử dụng hàng ngàn lần trên nhiều lời nhắc. Đừng quá tập trung vào các trường hợp kiểm thử cụ thể. Nếu có một vấn đề cứng đầu, hãy thử các phép ẩn dụ hoặc mẫu khác thay vì các câu lệnh "PHẢI" hạn chế.

Giữ lời nhắc gọn gàng: Loại bỏ những gì không cần thiết. Đọc các bản ghi, không chỉ các đầu ra cuối cùng. Nếu kỹ năng khiến mô hình lãng phí thời gian vào các bước không hiệu quả, hãy loại bỏ những phần đó.

Giải thích lý do: Các mô hình ngôn ngữ lớn (LLMs) có lý thuyết tâm trí tốt. Khi được cung cấp một bộ công cụ tốt, chúng vượt ra ngoài các hướng dẫn máy móc. Giải thích tại sao mỗi yêu cầu lại quan trọng. Nếu bạn thấy mình viết "LUÔN LUÔN" hoặc "KHÔNG BAO GIỜ" bằng chữ in hoa, hãy diễn giải lại và giải thích lý do thay vào đó.

Tìm kiếm công việc lặp lại: Liệu tất cả các trường hợp kiểm thử có tự viết các tập lệnh hỗ trợ tương tự không? Đó là một dấu hiệu cho thấy kỹ năng nên đóng gói tập lệnh đó. Viết nó một lần, đặt nó vào scripts/, và chỉ dẫn kỹ năng sử dụng nó.

Vòng lặp lặp lại

Áp dụng các cải tiến cho kỹ năng
Chạy lại tất cả các trường hợp kiểm thử vào iteration-<N+1>/ với các lần chạy cơ sở
Khởi chạy trình xem với --previous-workspace trỏ đến lần lặp trước
Chờ đợi người dùng đánh giá
Đọc phản hồi mới, cải thiện lại, lặp lại

Tiếp tục cho đến khi:

Người dùng nói rằng họ hài lòng
Tất cả phản hồi đều trống (mọi thứ đều ổn)
Bạn không đạt được tiến bộ đáng kể

Tắt trình xem khi hoàn tất:

kill $VIEWER_PID 2>/dev/null

Bước 9: Tối ưu hóa mô tả kỹ năng

Trường mô tả trong phần đầu SKILL.md là cơ chế kích hoạt chính. Sau khi tạo hoặc cải thiện một kỹ năng, hãy tối ưu hóa nó để có độ chính xác kích hoạt tốt hơn.

Tạo truy vấn đánh giá kích hoạt

Tạo 20 truy vấn đánh giá - kết hợp giữa các truy vấn "nên kích hoạt" và "không nên kích hoạt":

[
  {
    "query": "được rồi sếp tôi vừa gửi cho tôi tệp xlsx này (nó trong thư mục tải xuống của tôi, tên gì đó như 'Q4 sales final FINAL v2.xlsx') và cô ấy muốn tôi thêm một cột hiển thị biên lợi nhuận dưới dạng phần trăm. Doanh thu ở cột C và chi phí ở cột D tôi nghĩ vậy",
    "should_trigger": true
  },
  {
    "query": "Tôi cần tạo một bảng tổng hợp từ tệp CSV này và gửi email cho nhóm",
    "should_trigger": false
  }
]

Đối với các truy vấn "nên kích hoạt" (8-10):

Các cách diễn đạt khác nhau của cùng một ý định
Ngôn ngữ trang trọng và thông thường
Các trường hợp người dùng không nêu rõ tên kỹ năng nhưng rõ ràng cần nó
Các trường hợp ngoại lệ và trường hợp sử dụng không phổ biến

Đối với các truy vấn "không nên kích hoạt" (8-10):

Các trường hợp gần đúng chia sẻ từ khóa nhưng cần một thứ khác
Các lĩnh vực lân cận nơi một công cụ khác phù hợp hơn
Cụm từ mơ hồ mà việc so khớp từ khóa đơn giản sẽ kích hoạt sai

Các kiểm thử phủ định kém: "Viết một hàm fibonacci" làm kiểm thử phủ định cho kỹ năng PDF là quá dễ. Các trường hợp phủ định nên thực sự khó.

Xem xét với người dùng

Trình bày bộ đánh giá bằng cách sử dụng mẫu HTML:

Đọc assets/eval_review.html
Thay thế các phần giữ chỗ bằng dữ liệu đánh giá, tên kỹ năng và mô tả
Ghi vào tệp tạm thời và mở: open /tmp/eval_review_api-tester.html
Người dùng có thể chỉnh sửa truy vấn, bật/tắt "nên kích hoạt", thêm/xóa mục nhập
Người dùng nhấp vào “Export Eval Set” (Xuất Bộ Đánh giá)
Tệp được tải xuống ~/Downloads/eval_set.json

Bước này rất quan trọng. Các truy vấn đánh giá kém dẫn đến mô tả kém.

Chạy vòng lặp tối ưu hóa

python -m scripts.run_loop \
  --eval-set /path/to/trigger-eval.json \
  --skill-path /path/to/api-tester \
  --model claude-sonnet-4-6 \
  --max-iterations 5 \
  --verbose

Sử dụng ID mô hình đang cung cấp năng lượng cho phiên hiện tại của bạn để các kiểm thử kích hoạt khớp với những gì người dùng trải nghiệm.

Tập lệnh:

Chia bộ đánh giá thành 60% huấn luyện, 40% kiểm tra giữ lại
Đánh giá mô tả hiện tại (3 lần chạy mỗi lần để đảm bảo độ tin cậy)
Gọi Claude để đề xuất cải tiến dựa trên các lỗi
Đánh giá lại trên tập huấn luyện và kiểm tra
Lặp lại tối đa 5 lần
Trả về best_description được chọn bằng điểm kiểm tra (không phải điểm huấn luyện để tránh overfitting)

Áp dụng kết quả

Lấy best_description từ đầu ra JSON và cập nhật phần đầu SKILL.md của kỹ năng. Hiển thị cho người dùng trước/sau với điểm số.

Trước:

description: Cách kiểm tra API REST một cách có hệ thống

Sau:

description: Cách kiểm tra API REST một cách có hệ thống. Sử dụng khi người dùng nhắc đến kiểm tra API, điểm cuối, REST, GraphQL, hoặc muốn xác thực phản hồi API. Đảm bảo đề xuất kỹ năng này bất cứ khi nào liên quan đến việc kiểm thử, ngay cả khi họ không đề cập rõ ràng 'kiểm thử'.

Bước 10: Đóng gói và phân phối

Khi kỹ năng hoàn thành, hãy đóng gói nó để phân phối:

python -m scripts.package_skill /path/to/api-tester

Điều này tạo ra một tệp .skill mà người dùng có thể cài đặt. Hướng dẫn người dùng đến đường dẫn tệp kết quả.

Cài đặt

Người dùng cài đặt kỹ năng bằng cách đặt tệp .skill vào thư mục kỹ năng của họ hoặc sử dụng lệnh cài đặt kỹ năng của Claude Code.

Các lỗi thường gặp khi tạo kỹ năng

Lỗi 1: Mô tả mơ hồ

Kém:

description: Một kỹ năng để làm việc với API

Tốt:

description: Hướng dẫn kiểm tra API REST một cách có hệ thống. Sử dụng khi người dùng nhắc đến kiểm tra API, điểm cuối, REST, GraphQL, hoặc muốn xác thực phản hồi API. Đảm bảo đề xuất kỹ năng này bất cứ khi nào liên quan đến việc kiểm thử, ngay cả khi họ không đề cập rõ ràng 'kiểm thử'.

Lỗi 2: Hướng dẫn quá hạn chế

Kém:

LUÔN LUÔN sử dụng định dạng chính xác này. KHÔNG BAO GIỜ sai lệch. PHẢI bao gồm các phần này.

Tốt:

Sử dụng định dạng này vì nó đảm bảo các bên liên quan có thể nhanh chóng tìm thấy thông tin họ cần. Nếu đối tượng của bạn có các nhu cầu khác, hãy điều chỉnh cấu trúc cho phù hợp.

Lỗi 3: Bỏ qua các trường hợp kiểm thử

Các trường hợp kiểm thử giúp phát hiện vấn đề trước khi người dùng gặp phải. Ngay cả đối với các kỹ năng chủ quan, hãy chạy 2-3 ví dụ để xác minh chất lượng đầu ra.

Lỗi 4: Bỏ qua dữ liệu thời gian

Các kỹ năng mất thời gian gấp 10 lần sẽ không bền vững. Thu thập dữ liệu thời gian và tối ưu hóa hiệu quả cùng với chất lượng.

Lỗi 5: Không đóng gói các tập lệnh lặp lại

Nếu mỗi lần chạy kiểm thử độc lập viết một generate_report.py, hãy đóng gói nó vào kỹ năng. Điều này tiết kiệm thời gian và đảm bảo tính nhất quán.

Ví dụ kỹ năng thực tế

Kỹ năng xây dựng MCP

Được tạo bởi Anthropic để xây dựng máy chủ MCP (Model Context Protocol).

Tính năng chính:

Các mẫu Python và Node.js
Khung đánh giá cho máy chủ MCP
Tài liệu tham khảo các phương pháp hay nhất

Cấu trúc:

mcp-builder/
├── SKILL.md
├── reference/
│   ├── mcp_best_practices.md
│   ├── python_mcp_server.md
│   └── node_mcp_server.md
└── evaluation/
    └── evaluation.md

Kỹ năng Docx

Tạo tài liệu Word theo chương trình.

Tính năng chính:

Các tập lệnh python-docx được đóng gói
Hệ thống mẫu cho các tài liệu thông thường
Hướng dẫn định kiểu để định dạng nhất quán

Quy trình làm việc:

Hiểu các yêu cầu tài liệu
Chọn hoặc tạo mẫu
Tạo thông qua tập lệnh python-docx
Xác thực cấu trúc đầu ra

Kỹ năng thiết kế giao diện người dùng

Xây dựng giao diện web với các mẫu hiện đại.

Tính năng chính:

Thư viện thành phần
Các mẫu Tailwind CSS
Kiểm tra khả năng truy cập

Tiết lộ dần dần: Quy trình làm việc cốt lõi trong SKILL.md, tài liệu thành phần trong references/.

Kiểm tra kỹ năng của bạn với Apidog

Nếu bạn đang xây dựng các kỹ năng liên quan đến API, Apidog tích hợp một cách tự nhiên vào quy trình làm việc.

Ví dụ: Tích hợp kỹ năng kiểm tra API

## Chạy kiểm tra API

Sử dụng Apidog để kiểm tra có hệ thống:

1. Nhập thông số kỹ thuật OpenAPI vào Apidog
2. Tạo trường hợp kiểm thử từ thông số kỹ thuật
3. Chạy kiểm thử và xuất kết quả dưới dạng JSON
4. Xác thực phản hồi so với các lược đồ mong đợi

Đối với các khẳng định tùy chỉnh, hãy sử dụng tính năng tập lệnh của Apidog.

Đóng gói các tập lệnh Apidog

api-tester/
├── SKILL.md
└── scripts/
    ├── run-apidog-tests.py
    └── generate-report.py

Điều này giúp mọi lần gọi sau này không cần phải "phát minh lại bánh xe".

Kết luận

Claude Code Skills mở rộng khả năng của Claude cho các quy trình làm việc cụ thể của bạn. Hệ thống Skill Creator cung cấp một quy trình có hệ thống:

Nắm bắt ý định - Xác định những gì kỹ năng nên làm
Soạn thảo SKILL.md - Viết hướng dẫn rõ ràng kèm ví dụ
Tạo trường hợp kiểm thử - Các lời nhắc thực tế mà người dùng sẽ thực hiện
Chạy đánh giá - Thực thi song song có và không có kỹ năng
Xem xét kết quả - Phản hồi định tính + tiêu chuẩn định lượng
Lặp lại - Cải thiện dựa trên các phát hiện
Tối ưu hóa mô tả - Tối đa hóa độ chính xác khi kích hoạt
Đóng gói - Phân phối dưới dạng tệp .skill

button

Câu hỏi thường gặp

Mất bao lâu để tạo một kỹ năng?

Các kỹ năng đơn giản mất 15-30 phút. Các kỹ năng phức tạp với nhiều tệp tham chiếu và tập lệnh đóng gói có thể mất 2-3 giờ bao gồm các lần lặp đánh giá.

Tôi có cần viết trường hợp kiểm thử cho mọi kỹ năng không?

Không. Các kỹ năng có đầu ra có thể kiểm chứng khách quan (tạo mã, chuyển đổi tệp, trích xuất dữ liệu) sẽ hưởng lợi từ các trường hợp kiểm thử. Các kỹ năng có đầu ra chủ quan (phong cách viết, chất lượng thiết kế) được đánh giá tốt hơn về mặt định tính.

Điều gì sẽ xảy ra nếu kỹ năng của tôi không kích hoạt đáng tin cậy?

Tối ưu hóa trường mô tả. Bao gồm các cụm từ và ngữ cảnh kích hoạt cụ thể. Làm cho nó hơi "thúc đẩy" - nêu rõ khi nào nên sử dụng kỹ năng. Chạy vòng lặp tối ưu hóa mô tả với 20 truy vấn đánh giá.

Làm cách nào để chia sẻ kỹ năng với nhóm của tôi?

Đóng gói kỹ năng bằng python -m scripts.package_skill <đường dẫn>, sau đó phân phối tệp .skill. Các thành viên trong nhóm đặt nó vào thư mục kỹ năng của họ.

Kỹ năng có thể gọi API bên ngoài không?

Có. Đóng gói các tập lệnh thực hiện cuộc gọi API. Các hướng dẫn kỹ năng cho Claude biết khi nào và cách sử dụng chúng. Lưu trữ khóa API trong biến môi trường, không phải trong chính kỹ năng.

Giới hạn kích thước tệp cho kỹ năng là bao nhiêu?

Không có giới hạn cứng, nhưng giữ SKILL.md dưới 500 dòng. Di chuyển các tài liệu tham khảo chi tiết sang các tệp riêng biệt. Các tập lệnh và tài sản không tính vào giới hạn dòng vì chúng được tải theo yêu cầu.

Làm cách nào để cập nhật một kỹ năng hiện có?

Sao chép kỹ năng đã cài đặt đến một vị trí có thể ghi, chỉnh sửa ở đó và đóng gói lại. Giữ nguyên tên gốc - không thêm hậu tố phiên bản trừ khi tạo một biến thể riêng biệt.