check

Tổng quan về skill check

Skill check làm gì

check là một workflow review và chặn phát hành dành cho diff code, PR, triage issue, độ sẵn sàng phát hành, push, và audit dự án. Skill này phù hợp nhất với những ai muốn có câu trả lời nhanh nhưng kỷ luật cho câu hỏi: “Chỗ này có an toàn để ship không, đang lỗi gì, và trước khi merge tôi phải sửa gì?”

Khi nào skill này phù hợp nhất

Hãy dùng check khi bạn cần review code cho một tập thay đổi cụ thể, gồm trước khi merge, trước khi release, hoặc khi xác minh các artifact được tạo ra và các bước follow-through. Skill này đặc biệt hữu ích khi bạn muốn agent kiểm tra worktree trước, tránh các thay đổi local ẩn, và tách lỗi có thể sửa được khỏi những điểm cần con người xác nhận.

Điều gì làm check khác biệt

check không phải kiểu prompt chung chung “xem code này giúp tôi”. Skill này có các chốt an toàn rõ ràng cho worktree bẩn hoặc chưa được track, một quy trình ưu tiên review trước, và cơ chế chuyển sang reviewer chuyên sâu khi có rủi ro về kiến trúc hoặc bảo mật. Nhờ vậy, nó mạnh hơn một prompt dùng một lần cho check for Code Review, vì giảm được việc đoán mò về lúc nào cần xem, xem cái gì, và khi nào nên dừng.

Cách dùng skill check

Cài đặt và kích hoạt check

Cài bằng:

npx skills add tw93/Waza --skill check

Sau đó gọi skill này khi bạn có một mục tiêu review cụ thể: một diff, branch, PR, release candidate, phạm vi commit, hoặc yêu cầu audit repo. Với check usage, hãy đưa cho agent một phạm vi rõ ràng như “review 3 commit gần nhất”, “check PR này trước khi merge”, hoặc “audit độ sẵn sàng release sau khi cập nhật dependency”.

Đưa cho skill đầu vào đúng

Đầu vào mạnh nhất cho check không phải là “nó có ổn không?”, mà là một nhiệm vụ có giới hạn kèm ngữ cảnh. Ví dụ tốt:

• “Check PR này xem có regression về bảo mật và kiến trúc trước khi merge không.”
• “Review worktree hiện tại và cho tôi biết điều gì đang chặn release.”
• “Audit các file được generate và xem chúng có khớp với thay đổi trong source không.”

Hãy nêu branch, phạm vi commit, bản release dự kiến, và mọi ràng buộc như “không sửa file” hoặc “chỉ inspect ngữ cảnh repo công khai.” Làm vậy sẽ giúp skill tránh kiểu review quá rộng và mơ hồ.

Đọc các file này trước

Bắt đầu với SKILL.md, rồi xem references/project-context.md và references/persona-catalog.md để hiểu độ sâu review, cách chuyển hướng sang reviewer chuyên môn, và kỳ vọng cho release. Dùng agents/reviewer-security.md và agents/reviewer-architecture.md khi diff chạm tới trust boundary, API, import, hoặc cấu trúc module. references/public-reply.md quan trọng khi workflow có phần maintainer follow-up trên issue hoặc PR.

Mẹo workflow thực tế

Trước khi review, skill này kỳ vọng một bước kiểm tra an toàn worktree bằng git status --short --branch -uall. Điều này quan trọng vì thay đổi bẩn hoặc chưa được track có thể làm đổi nghĩa của review. Nếu bạn muốn kết quả check guide tốt hơn, hãy nói rõ cho agent biết nó chỉ nên báo findings, có được phép sửa các lỗi an toàn hay không, và nên dùng lệnh verification nào sau khi thay đổi.

Câu hỏi thường gặp về skill check

check chỉ dùng để review code thôi à?

Không. check còn bao phủ độ sẵn sàng release, push, artifact đã publish, triage issue và PR, cùng audit toàn bộ dự án. Nó phù hợp hơn một prompt thông thường khi nhiệm vụ có yếu tố “trước khi ship”, chứ không chỉ là đọc code.

Khi nào không nên dùng check?

Đừng dùng check cho việc khám phá ý tưởng mở, debug tìm nguyên nhân gốc, hoặc chỉnh sửa văn bản. Skill này được thiết kế cho diff cụ thể và review vận hành, không phải cho brainstorming hay phản hồi mang tính kể chuyện.

check có thân thiện với người mới không?

Có, nếu bạn nêu được mục tiêu và đầu ra mong muốn. Người mới sẽ có kết quả tốt nhất khi nói rõ đã thay đổi gì, muốn review điều gì, và họ chỉ muốn findings hay muốn cả các sửa lỗi an toàn. Nếu không có những thông tin đó, check install có thể dễ, nhưng check usage sẽ quá rộng để đáng tin cậy.

Nó khác gì so với một prompt bình thường?

Một prompt bình thường thường chỉ yêu cầu review mang tính chủ quan. check bổ sung một quy trình kỷ luật hơn: preflight an toàn, kiểm soát phạm vi, kỳ vọng xác minh, và chuyển hướng sang chuyên gia khi có rủi ro về bảo mật hoặc kiến trúc. Điều đó khiến nó đáng tin cậy hơn cho check for Code Review so với một yêu cầu review ngẫu hứng.

Cách cải thiện skill check

Cung cấp brief review chặt hơn

Đầu vào hữu ích nhất là: đã thay đổi gì, vì sao thay đổi, điều gì tuyệt đối không được hỏng, và bạn muốn kiểu review nào. Ví dụ: “chỉ review luồng authentication,” “tập trung vào release artifacts,” hoặc “check xem refactor này có làm đổi public APIs không.” Cách này thu hẹp phạm vi tìm kiếm và tăng tín hiệu.

Nêu rõ các ràng buộc khó

Hãy nói cho skill biết về quy tắc đóng gói, file được generate, đường dẫn được bảo vệ, và các lệnh verification bắt buộc. Nếu repo có nguồn chân lý cho build hoặc release, hãy nói ngay từ đầu. Như vậy sẽ giảm cảm giác chắc chắn sai lệch và giúp check phát hiện drift, artifact bị thiếu, hoặc phần follow-through không an toàn.

Lặp lại từ findings, không từ lời khen

Sau lượt đầu, hãy phản hồi bằng đúng những findings bạn muốn kiểm tra lại hoặc patch bạn đã áp dụng. Skill sẽ tốt hơn khi bạn yêu cầu pass thứ hai cho từng vùng rủi ro một, như bảo mật, kiến trúc, hoặc độ sẵn sàng release. Nếu kết quả cảm giác quá rộng, hãy thu hẹp phạm vi thay vì chỉ yêu cầu “chi tiết hơn.”