Viết Figma Skills: Dạy AI về các quy tắc của nhóm bạn

Các quy tắc mà agent của bạn ghi nhớ

🔄 Tóm tắt nhanh: Trong Bài học 5, bạn đã viết các prompt với những tham chiếu hệ thống thiết kế rõ ràng, các quy tắc chống hardcode và những quy ước đặt tên. Trong Bài học 6, bạn đã học cách thu thập và làm sạch code trực tiếp. Nhưng vấn đề là: Bạn đang lặp lại những hướng dẫn tương tự mỗi khi đưa ra prompt cho agent. Skill khắc phục điều đó.

Bạn có thể đã nhận thấy một mô hình. Mỗi khi yêu cầu agent tạo ra thứ gì đó, bạn đều bao gồm cùng một khối: "sử dụng hệ thống thiết kế của tôi", "không hardcode các giá trị", "đặt tên các layer như thế này". Đó là sự tốn công sao chép-dán. Và nếu một đồng nghiệp không sao chép những hướng dẫn đó, đầu ra của họ sẽ không nhất quán.

Skill là giải pháp. Chúng là các file markdown - văn bản thuần túy, không có code - dạy cho agent những quy ước của nhóm bạn một lần để bạn không phải lặp lại chính mình. Một nhà phát triển đã nắm bắt được điểm mấu chốt: "Skill dưới dạng file markdown có cùng mô hình với CLAUDE.md để lập trình các agent - dạy AI các quy ước của bạn bằng văn bản thuần túy". Nếu đã từng viết README, bạn cũng có thể viết một skill.

Đến cuối bài học này, bạn sẽ có thể:

• Viết một skill tùy chỉnh mã hóa các quy ước thiết kế của nhóm bạn
• Đánh giá và điều chỉnh các skill cộng đồng cho quy trình làm việc cụ thể của bạn

Skill thực chất là gì?

Skill là một file .md. Chỉ vậy thôi. Markdown. Loại file mà bạn sẽ viết README.

Đây là cấu trúc:

# Tên skill

## Khi nào sử dụng
Mô tả khi nào agent nên áp dụng skill này.

## Các bước
1. Đầu tiên, hãy làm điều này
2. Sau đó, hãy làm điều này
3. Cuối cùng, hãy làm điều này

## Quy tắc đặt tên
- Khung: Dựa trên nội dung (ví dụ: "Hero Section", không phải "Frame 1")
- Thành phần: Danh mục/Biến thể/Trạng thái
- Biến: tập hợp/tên

## Lựa chọn thành phần
- Nút: luôn sử dụng Button/Primary/Default cho CTA
- Đàu vào: luôn sử dụng Input/Text/Default cho các trường biểu mẫu
- Thẻ: luôn sử dụng Card/Surface/Default cho các vùng chứa nội dung

## Những điều KHÔNG nên làm
- KHÔNG hardcode màu hex
- KHÔNG đặt kích thước phông chữ thủ công - hãy sử dụng kiểu văn bản
- KHÔNG tạo thành phần mới khi đã có thành phần hiện có khớp

Không cần nhập. Không cần API key. Không cần bước build. Bạn viết nó trong bất kỳ trình soạn thảo văn bản nào, lưu nó dưới dạng .md và trỏ đến agent.

✅ Kiểm tra nhanh: Một nhà thiết kế junior trong nhóm của bạn hỏi "Tôi có cần biết JavaScript để viết một skill không?" Câu trả lời là gì?

Câu trả lời: Không. Skill là các file markdown văn bản thuần túy. Nếu có thể viết một danh sách hướng dẫn dạng gạch đầu dòng, bạn có thể viết một skill. Toàn bộ vấn đề là kiến ​​thức về quy ước thiết kế — chứ không phải kiến ​​thức lập trình — mới là thứ làm cho một skill trở nên hữu ích.

9 skill Figma đã phát hành khi ra mắt

Figma đã phát hành 9 skill ví dụ cùng với việc ra mắt MCP server. Một số điểm nổi bật:

Từ Edenspiekermann: "apply-design-system" Hướng dẫn agent cách tìm và sử dụng các biến thiết kế, khi nào nên sử dụng những thành phần so với các bản build tùy chỉnh và cách xử lý những trường hợp ngoại lệ khi một thành phần không tồn tại cho một trường hợp sử dụng cụ thể. Đó là skill hệ thống thiết kế từ Bài học 5, được đóng gói dưới dạng một file có thể tái sử dụng.

Từ Uber: "create-voice" Tạo ra các thông số kỹ thuật về khả năng truy cập — thứ tự đọc VoiceOver, nhãn ARIA và những mẫu điều hướng của trình đọc màn hình. Thay vì viết các thông số kỹ thuật về khả năng truy cập theo cách thủ công, hãy hướng agent vào một màn hình và nó sẽ tạo ra những thông số kỹ thuật theo các quy ước nội bộ của Uber.

Từ thư viện cộng đồng: Các skill để tạo bố cục đáp ứng, tạo bộ icon, xây dựng mẫu biểu mẫu và cấu trúc hệ thống phân cấp điều hướng. Mỗi skill mã hóa các quy ước cụ thể của một nhóm cho một loại nhiệm vụ thiết kế cụ thể.

Hãy xem chúng tại figma.com/community/skills. Đọc 5 hoặc 6 skill trước khi viết skill của riêng bạn — xem cách các nhóm khác cấu trúc hướng dẫn của họ là cách nhanh nhất để hiểu điều gì hiệu quả.

Cấu trúc của một skill tốt

Sau khi nghiên cứu các skill khi ra mắt và thử nghiệm hàng chục gợi ý, đây là những yếu tố làm cho một skill thực sự hiệu quả:

1. Phạm vi - Một công việc, được thực hiện tốt

Sai: "Một skill để thiết kế mọi thứ".

Tốt: "Một skill để tạo các hàng chuyển đổi trang cài đặt."

Phạm vi hẹp có nghĩa là hướng dẫn cụ thể. Hướng dẫn cụ thể có nghĩa là đầu ra nhất quán. Một skill cố gắng bao quát toàn bộ hệ thống thiết kế của bạn sẽ mơ hồ ở tất cả những nơi cần phải chính xác.

2. Các bước rõ ràng - Không phải gợi ý

Sai: "Hãy cân nhắc sử dụng bố cục tự động."

Tốt: "Bước 3: Áp dụng bố cục tự động theo chiều ngang cho hàng nút chuyển đổi. Đặt khoảng cách là spacing/md. Đặt khoảng đệm ngang là spacing/lg."

Agent tuân theo hướng dẫn. Nó không "xem xét" các đề xuất. Mỗi bước phải đủ cụ thể để một nhà thiết kế mới có thể làm theo mà không cần đặt câu hỏi.

3. Tham chiếu được đặt tên - mọi biến, mọi thành phần

Mọi tên biến, đường dẫn thành phần và kiểu văn bản mà skill của bạn tham chiếu phải là chuỗi chính xác mà agent sẽ tìm thấy trong file Figma của bạn. Không phải là diễn giải lại. Không phải là mô tả chung chung. Phải là tên thực tế.

## Các biến cần sử dụng
- Nền: surface/card-primary
- Màu chữ: text/primary
- Viền: border/subtle
- Khoảng đệm: spacing/lg (24px)
- Khoảng cách giữa các mục: spacing/md (16px)

✅ Kiểm tra nhanh: Skill của bạn tham chiếu đến một thành phần có tên là "Toggle/Default" nhưng thư viện Figma của bạn thực tế lại đặt tên là "Controls/Toggle/Default". Liệu agent có tìm thấy nó không?

Câu trả lời: Có lẽ là không. Đường dẫn thành phần phải khớp chính xác. Nếu thư viện của bạn sử dụng "Controls/Toggle/Default", skill của bạn phải tham chiếu đến "Controls/Toggle/Default". Đây là nguyên nhân phổ biến nhất gây ra lỗi skill - đường dẫn thành phần sai.

4. Các mẫu phản tác dụng - Những điều KHÔNG nên làm

Đây là yếu tố bí mật. Agent có xu hướng thiên về các mẫu phổ biến. Nếu bạn không cấm rõ ràng các giá trị được hardcode, chúng sẽ mặc định sử dụng chúng. Nếu bạn không nói "đừng tạo nút mới", chúng sẽ xây dựng một nút từ đầu thay vì sử dụng thành phần của bạn.

## Những điều KHÔNG nên làm
- KHÔNG tạo khung hình chữ nhật cho nút — hãy sử dụng các thể hiện Button/*
- KHÔNG đặt màu nền bằng giá trị hex — luôn liên kết với biến
- KHÔNG đặt thủ công Inter 14px — hãy áp dụng kiểu chữ typography/body-md
- KHÔNG đặt tên lớp là "Frame 1," "Group 2," v.v. — hãy sử dụng tên mô tả

5. Trình tự - Thứ tự rất quan trọng

Các tác vụ thiết kế cần có thứ tự. Tạo container trước khi thêm các phần tử con. Thiết lập bố cục tự động trước khi định vị các phần tử. Áp dụng biến trước khi điều chỉnh khoảng cách. Skill của bạn nên tuân theo thứ tự này:

## Các bước
1. Tạo khung container và đặt tên cho nó
2. Áp dụng bố cục tự động (hướng, khoảng cách, lề)
3. Thêm các phần tử con bằng cách sử dụng những thành phần
4. Liên kết tất cả màu sắc với các biến hệ thống thiết kế
5. Áp dụng kiểu chữ cho tất cả các lớp văn bản
6. Kiểm tra cuối cùng: không có giá trị được hardcode, tất cả các lớp đều được đặt tên

Ví dụ minh họa: Viết skill hàng nút

Hãy viết một skill từ đầu cho một mẫu phổ biến: Một hàng nút ở cuối thẻ hoặc hộp thoại.

# Tạo Hàng nút

## Khi nào sử dụng
Khi thêm một hàng nút hành động vào thẻ, hộp thoại hoặc biểu mẫu.

## Các bước
1. Tạo một khung có tên "[Ngữ cảnh] Button Row" (ví dụ: "Settings Button Row")
2. Áp dụng bố cục tự động theo chiều ngang:
  - Hướng: ngang
  - Khoảng cách: khoảng cách/nhỏ (8px)
  - Căn chỉnh: căn phải
  - Không có khoảng đệm (phần tử cha tự động xử lý khoảng đệm)

3. Thêm các nút dưới dạng các thể hiện thành phần:
  - Hành động phụ (trái): sử dụng Button/Secondary/Default
  - Hành động chính (phải): sử dụng Button/Primary/Default

4. Đặt nhãn nút:
  - Phụ: "Cancel" (hoặc nhãn đóng phù hợp với ngữ cảnh)
  - Chính: động từ hành động (ví dụ: "Save Changes", "Delete", "Confirm")

5. Áp dụng các ràng buộc:
  - Hàng nút lấp đầy chiều rộng của phần tử cha (thay đổi kích thước theo chiều ngang: lấp đầy)
  - Các nút ôm sát nội dung (thay đổi kích thước theo chiều ngang: ôm sát)

## Quy ước đặt tên
- Khung hàng: "[Ngữ cảnh] Button Row"
- Các nút giữ nguyên tên thể hiện thành phần của chúng

## Những điều KHÔNG nên làm
- KHÔNG tạo nút từ hình chữ nhật + văn bản — luôn sử dụng các ví dụ
- KHÔNG đặt hành động chính ở bên trái — hành động chính ở bên phải
- KHÔNG thêm nhiều hơn 3 nút trong một hàng — sử dụng menu cho 4 nút trở lên
- KHÔNG hardcode màu nút — các thể hiện thành phần sẽ xử lý việc này

Skill này dài 30 dòng. Mất 5 phút để viết. Và nó đảm bảo mọi hàng nút mà agent tạo ra đều tuân theo quy ước chính xác của nhóm bạn.

Giảm thiểu sự khác biệt

Đây là lý do tại sao các skill lại quan trọng hơn cả sự tiện lợi. Nếu không có skill, bạn và đồng đội của bạn có thể đưa ra cùng một yêu cầu nhiệm vụ theo cách khác nhau:

Bạn: "Thêm nút hủy và lưu ở góc dưới bên phải"

Đồng đội: "Tạo một phần với hai nút"

Cùng một ý định. Kết quả khác nhau. Agent đưa ra các lựa chọn khác nhau về khoảng cách, căn chỉnh, lựa chọn thành phần và đặt tên.

Với một skill, cả hai bạn đều nói: "Sử dụng skill 'Create Button Row' để thêm nút vào thẻ này." Cùng một kết quả mỗi lần.

Đây là ý nghĩa của việc giảm thiểu sự khác biệt. Không phải loại bỏ sự sáng tạo - mà là loại bỏ sự không nhất quán. Các quyết định sáng tạo (màn hình hoạt động như thế nào, bố cục ra sao, thông tin hiển thị là gì) vẫn thuộc về bạn. Các quyết định về mặt kỹ thuật (thành phần nào, khoảng cách như thế nào, cách đặt tên ra sao) được xử lý bởi skill.

✅ Kiểm tra nhanh: Hai nhà thiết kế trong nhóm của bạn đều có skill "tạo thẻ", nhưng với tên biến khác nhau. Vấn đề là gì?

Câu trả lời: Bây giờ bạn có hai nguồn thông tin khác nhau về quy ước tạo thẻ, điều này làm mất đi mục đích của skill. Các nhóm nên chia sẻ skill trong một kho lưu trữ tập trung - cùng một file, được kiểm soát phiên bản - để agent của mọi người tuân theo cùng một quy tắc.

Thực hành: Viết skill đầu tiên của bạn

Chọn một mẫu mà nhóm của bạn sử dụng lặp đi lặp lại: - Bố cục thẻ - Phần biểu mẫu - Mục điều hướng - Hàng danh sách - Mẫu tiêu đề

Viết một skill cho mẫu đó theo cấu trúc trên. Bao gồm:

1. Phần "Khi nào nên sử dụng"
2. Các bước được đánh số với tên biến và thành phần chính xác
3. Phần "Những điều KHÔNG nên làm" với ít nhất 3 lỗi thiết kế
4. Phần quy ước đặt tên

Kiểm tra bằng cách yêu cầu agent áp dụng skill của bạn vào một khung mới. So sánh kết quả với kết quả được tạo mà không có skill.

Những điểm chính cần ghi nhớ

• Skill là các file markdown - những hướng dẫn bằng văn bản thuần túy dạy cho agent các quy ước thiết kế của nhóm bạn. Không cần code lập trình.
• Các skill tốt có phạm vi hẹp, những bước rõ ràng, tên thành phần/biến chính xác, các lỗi thiết kế và trình tự phù hợp.
• 9 skill ví dụ được cung cấp khi ra mắt. Các skill cộng đồng có tại figma.com/community/skills. Luôn luôn điều chỉnh chúng trước khi sử dụng trong dự án của bạn. skill giúp giảm sự khác biệt về kết quả - cùng một skill, cùng một kết quả, bất kể ai là người hướng dẫn.
• Phần "Những điều KHÔNG nên làm" chính là bí quyết. Các agent mặc định sử dụng những mẫu phổ biến trừ khi được chỉ dẫn rõ ràng khác đi.
• Chia sẻ skill trong nhóm của bạn thông qua kho lưu trữ được kiểm soát phiên bản. Hai skill cạnh tranh cho cùng một mẫu còn tệ hơn là không có skill nào cả.