think

Tổng quan về think skill

think skill làm gì

think là một skill hỗ trợ ra quyết định, giúp biến một ý tưởng còn mơ hồ thành một kế hoạch rõ ràng, đã được chốt hướng đi trước khi ai đó viết code. Skill này phù hợp nhất cho thiết kế tính năng, lựa chọn kiến trúc, phân tích đánh đổi, và các câu hỏi kiểu “có nên làm không?” khi nhu cầu chính là phán đoán chứ không phải triển khai.

Ai nên cài đặt skill này

Hãy cài think skill nếu bạn thường xuyên cần hỗ trợ cho quyết định sản phẩm, định hướng kỹ thuật, hoặc lập kế hoạch theo phạm vi trong một workflow ưu tiên repo. Skill này đặc biệt hữu ích khi yêu cầu bắt đầu bằng “lên kế hoạch cho việc này”, “cách tiếp cận tốt nhất là gì”, “có nên giữ cái này không”, hoặc các câu hỏi mang tính đánh giá tương tự.

Điều gì làm skill này khác biệt

Skill này có quan điểm rõ ràng: nó thúc đẩy một khuyến nghị cụ thể, chỉ ra bằng chứng nào có thể làm thay đổi khuyến nghị đó, và tránh đi quá sớm vào code. Điều đó khiến think for Decision Support mạnh hơn một prompt brainstorming chung chung khi bạn cần đầu ra đủ độ chín để ra quyết định.

Cách dùng think skill

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

Cài bằng npx skills add tw93/Waza --skill think. Sau đó dùng nó khi nhiệm vụ liên quan đến việc chọn hướng, định hình, hoặc xác thực một phương án thay vì sửa một lỗi đã biết. Bước think install rất đơn giản, nhưng chất lượng phụ thuộc vào việc bạn đưa cho nó đúng bối cảnh quyết định thực sự.

Đưa đúng dạng đầu vào

Một prompt think usage tốt nên có mục tiêu, ràng buộc, đối tượng sử dụng, và chính xác lựa chọn nào còn đang mở. Ví dụ: “Chúng ta cần một luồng onboarding nhanh hơn cho SMB admins; chỉ được đổi UI, không thể thêm việc backend trong sprint này, và cần một khuyến nghị có phân tích đánh đổi.”

Đọc đúng file trước

Hãy bắt đầu với SKILL.md, vì repo này được thiết kế tối giản và không có các thư mục hỗ trợ như rules/, references/, hay resources/. Hướng dẫn thực tế chính nằm ngay trong phần thân của skill: chế độ lightweight, chế độ evaluation, và quy tắc không đi vào implementation trước khi được phê duyệt.

Dùng workflow như một phễu ra quyết định

Một luồng think guide tốt là: nêu quyết định cần làm, liệt kê ràng buộc, hỏi phương án tốt nhất, rồi chỉ yêu cầu kế hoạch kèm rủi ro và các phương án thay thế nếu thật sự cần. Nếu bạn không chắc nên dùng lightweight mode hay full mode, hãy mô tả xem vấn đề đã được xác định rõ chưa; chỉ riêng chi tiết đó cũng có thể làm đầu ra thay đổi đáng kể.

FAQ về think skill

think chỉ dành cho tính năng mới thôi à?

Không. Skill này cũng hữu ích cho quyết định kiến trúc, đánh giá giá trị sản phẩm, refactor có đánh đổi thực sự, và các câu hỏi kiểu “việc này có đáng làm không?”. Nó không phải lựa chọn tốt nhất cho các bug fix đơn giản hoặc chỉnh sửa nhỏ khi câu trả lời đã quá rõ.

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

Một prompt bình thường thường tạo ra các lựa chọn khá mơ hồ. think skill được thiết kế để ép ra một quyết định: một hướng được khuyến nghị, các đánh đổi được nêu rõ, và một ranh giới rõ ràng là chưa code trước khi được duyệt. Vì vậy, nó phù hợp hơn khi bạn cần một kế hoạch để đồng đội hoặc stakeholder có thể review.

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

Có, miễn là người dùng mô tả mục tiêu bằng ngôn ngữ tự nhiên. Người mới sẽ nhận được nhiều giá trị nhất khi họ nêu rõ vấn đề, ràng buộc, và kết quả mong muốn, ngay cả khi chưa biết thuật ngữ kỹ thuật.

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

Đừng dùng nó khi bạn đã biết cách sửa và chỉ cần thực thi, hoặc khi nhiệm vụ đủ hẹp để sửa trực tiếp nhanh hơn phân tích. Nó cũng ít giá trị hơn nếu bạn không thật sự cần ra quyết định và chỉ cần viết lại nhanh.

Cách cải thiện think skill

Cung cấp bối cảnh đủ để ra quyết định

Đầu vào tốt nhất cho think skill gồm trạng thái hiện tại, trạng thái mục tiêu, các ràng buộc không thể thay đổi, và thế nào là thành công. Ví dụ, “Chúng ta cần giảm thời gian setup từ 10 phút xuống 2 phút, giữ nguyên backend hiện tại, và tránh thêm dependency mới” sẽ cho lời khuyên tốt hơn nhiều so với “cải thiện onboarding.”

Hỏi về quyết định, không chỉ hỏi ý tưởng

Nếu bạn muốn think usage tốt hơn, hãy yêu cầu một khuyến nghị kèm lý do, thay vì một danh sách lựa chọn. Tốt: “Chọn một phương án và giải thích vì sao nó thắng trong các ràng buộc này.” Yếu: “Cho tôi vài ý tưởng.”

Nêu rõ những đánh đổi bạn quan tâm

Hãy nói rõ điều gì quan trọng nhất với bạn: tốc độ, khả năng bảo trì, chi phí, UX, rủi ro, hay năng lực của team. Điều này giúp think for Decision Support tạo ra một kế hoạch khớp với ưu tiên của bạn thay vì một câu trả lời best practice chung chung.

Lặp lại với ràng buộc sắc hơn

Nếu kết quả đầu tiên còn quá rộng, hãy thu hẹp nó bằng một câu hỏi tiếp theo: thêm deadline, một dependency bị cấm, một nhóm người dùng mục tiêu, hoặc một thành phần bắt buộc phải giữ. Cách nhanh nhất để cải thiện đầu ra là biến các giả định ngầm thành ràng buộc rõ ràng trước khi hỏi kế hoạch tiếp theo.