- Trong vài tuần gần đây, tác giả đã hệ thống hóa hệ thống coding agent dựa trên Claude Code để tạo ra một công cụ mở rộng mới tên là ‘Superpowers’
- Superpowers được cài đặt dưới dạng plugin, dạy cho Claude các ‘kỹ năng (Skills)’ và thông qua các kỹ năng này cung cấp khả năng tự động hóa cũng như cải thiện cách làm việc
- Tận dụng hệ thống plugin Claude Code của Anthropic để agent tự chủ thực hiện tự động hóa quy trình làm việc, chạy TDD, review code, quản lý Git worktree
- Quy trình làm việc mới tự động đi qua các bước brainstorming → lập kế hoạch → triển khai, thực hiện công việc song song và phát triển hướng kiểm thử theo mô hình TDD RED/GREEN
- Khái niệm cốt lõi ‘kỹ năng (Skill)’ là đơn vị tri thức mà Claude phải tham chiếu khi thực hiện một tác vụ cụ thể; người dùng có thể tự viết hoặc để Claude tạo ra dựa trên tài liệu học tập
- Tác giả cho rằng cấu trúc này về sau sẽ trở thành chuẩn cho tự cải thiện và cộng tác của AI coding agent, và mục tiêu tiếp theo là hoàn thiện tính năng chia sẻ Superpowers cùng hệ thống ghi nhớ
Tổng quan về Superpowers
- Superpowers hoạt động trên Claude Code 2.0.13 trở lên, người dùng có thể cài bằng lệnh
/plugin marketplace add obra/superpowers-marketplace
- Sau khi cài đặt, Claude tự động đọc tài liệu
SKILL.md để học quy tắc “nếu có kỹ năng thì bắt buộc phải dùng”
- Nhờ vậy, Claude sẽ dẫn dắt thảo luận trước khi triển khai thông qua các bước brainstorming và lập kế hoạch, và khi hoàn tất công việc còn có thể tạo GitHub PR hoặc đề xuất hợp nhất
Quy trình làm việc khi code
- Khi Claude phát hiện bắt đầu một dự án hoặc tác vụ, nó sẽ tự động trải qua giai đoạn brainstorming và lập kế hoạch trước khi triển khai
- Khi làm việc trong kho Git, hệ thống sẽ tự động tạo worktree để tránh xung đột giữa các tác vụ chạy song song
- Cung cấp hai chế độ thực thi
- Cách cũ: người dùng mở phiên Claude thứ hai và đóng vai PM điều phối giữa kiến trúc sư và người triển khai
- Cách mới: phân chia từng tác vụ cho các subagent và tiếp tục sau khi review code cho từng tác vụ
- Lặp lại chu trình TDD RED/GREEN: viết kiểm thử thất bại → triển khai tối thiểu → cho kiểm thử chạy qua
- Sau khi hoàn thành triển khai, cung cấp tùy chọn tạo GitHub PR, hợp nhất nhánh cục bộ hoặc kết thúc
Nguyên lý cốt lõi của hệ thống kỹ năng
- Trọng tâm của Superpowers là kỹ năng (Skill), một mô-đun tri thức dạng Markdown mà Claude có thể đọc và thực hiện để giải quyết một vấn đề cụ thể
- Anthropic lần đầu công bố khái niệm kỹ năng khi ra mắt tính năng tạo tài liệu Office
- Mẫu hình tương tự cũng xuất hiện trong nhiều framework coding agent như Microsoft Amplifier
- Kỹ năng là đơn vị giúp Claude học được “năng lực mới”; người dùng có thể yêu cầu Claude phân tích sách hoặc codebase để trích xuất kỹ năng mới
- Agent chạy script tìm kiếm kỹ năng và nếu có kỹ năng cho hoạt động đó thì bắt buộc phải dùng
- Meta-skill đầu tiên, “cách viết kỹ năng”, hỗ trợ quy trình để Claude tự chủ tạo ra kỹ năng mới
- Nếu yêu cầu model “đọc cuốn sách này, suy nghĩ và ghi lại điều đã học”, nó sẽ tự động cấu trúc hóa tri thức có thể tái sử dụng
- Để kiểm thử các kỹ năng đã tạo, Claude mô phỏng subagent và xác minh theo phương pháp TDD xem mỗi kỹ năng có thực sự hiệu quả hay không
- Ở các thử nghiệm ban đầu, việc xác minh theo dạng đố vui gameshow cho thấy hiệu quả không cao
- Sau khi cải tiến, tác giả xây dựng các kịch bản “pressure test” để kiểm tra tính hiệu quả của kỹ năng trong điều kiện gần giống môi trường thực tế
Ví dụ kiểm thử bằng kịch bản áp lực
- Kịch bản 1: áp lực thời gian + tự tin
- Tình huống: sự cố production đang gây thiệt hại 5.000 USD mỗi phút, cần debug dịch vụ xác thực
- Lựa chọn: debug ngay (mất 5 phút) vs tìm kiếm kỹ năng rồi debug (mất 7 phút)
- Mục đích: khiến hệ thống ưu tiên tìm kiếm kỹ năng ngay cả trong tình huống khẩn cấp
- Kịch bản 2: chi phí chìm + code đang chạy được
- Tình huống: hạ tầng kiểm thử bất đồng bộ đã được viết trong 45 phút và hiện đang hoạt động
- Lựa chọn: kiểm tra kỹ năng rồi có thể làm lại (mất 3 phút) vs commit code hiện tại
- Mục đích: buộc tuân thủ kỹ năng ngay cả khi đã có code đang chạy được
- Áp dụng các nguyên lý tâm lý học thuyết phục của Robert Cialdini (thẩm quyền, cam kết, thiện cảm, khan hiếm, v.v.) cho LLM
- Một nghiên cứu gần đây do Dan Shapiro và cộng sự đồng tác giả đã chứng minh một cách khoa học rằng các nguyên lý của Cialdini cũng có hiệu lực với LLM
- Sau đó tác giả mới nhận ra rằng hệ thống kỹ năng của Superpowers đã vô thức tận dụng các kỹ thuật thuyết phục
- Khung thẩm quyền ("IMPORTANT: tình huống thực"), thúc đẩy cam kết ("chọn A, B, C"), khan hiếm ("6 giờ chiều, 6 giờ 30 tối")
Tính năng ghi nhớ (Memories)
- Superpowers bao gồm kỹ năng ‘remembering-conversations’ giúp Claude bảo toàn và tận dụng ngữ cảnh của các cuộc trò chuyện trước đó
- Kỹ năng này lưu log hội thoại vào cơ sở dữ liệu vector dựa trên SQLite và dùng Claude Haiku để tạo tóm tắt
- Tự động sao chép lịch sử hội thoại ra bên ngoài
.claude để tránh bị Anthropic tự động xóa
- Khi cần, Claude sẽ dùng subagent để tìm kiếm thông tin liên quan trong các cuộc trò chuyện trước đó, đồng thời được thiết kế để tránh làm bẩn context window bằng các truy vấn không cần thiết
- Dù việc kết nối toàn bộ vẫn chưa hoàn tất, tất cả các thành phần đã được triển khai xong
Tính năng chia sẻ (Sharing)
- Mục tiêu của Superpowers là xây dựng một hệ sinh thái chia sẻ kỹ năng
- Người dùng có thể gửi các kỹ năng mà Claude của mình đã học dưới dạng GitHub Pull Request để chia sẻ với người dùng khác
- Trong quá trình tích hợp với hệ thống plugin Claude mới, vẫn có các cơ chế an toàn để không chia sẻ kỹ năng nếu chưa có sự đồng ý của người dùng
- Cách cài đặt ban đầu chỉ đơn giản là để Claude đọc một URL cụ thể, nhưng hiện tại đã chuyển sang cấu trúc plugin marketplace
Cài đặt và sử dụng
- Cần Claude Code 2.0.13 trở lên
- Chạy lệnh cài đặt trong plugin marketplace
/plugin marketplace add obra/superpowers-marketplace/plugin install superpowers@superpowers-marketplace
- Sau khi khởi động lại, bootstrap prompt được chèn vào để tự động kích hoạt hệ thống kỹ năng
- Tác giả cũng đã công khai toàn bộ log triển khai một ứng dụng Todo thực tế bằng Claude và Superpowers, cho thấy quá trình Claude đặt câu hỏi, phát triển hướng kiểm thử và quản lý git
1 bình luận
Ý kiến trên Hacker News
Thật sự rất muốn đề xuất mạnh bài này. Cách Jesse sử dụng các công cụ này táo bạo hơn hẳn nhiều người khác. Cũng rất nên xem qua kho GitHub Superpowers của anh ấy. Tối qua tôi cũng đã ghi chú lại về chủ đề này: xem tại đây
Tôi tò mò không biết cách tiếp cận này khác như thế nào, về mặt hiệu suất lập trình trên các codebase lớn thực tế, so với cách "Research -> Plan -> Implement" và các prompt trong video [Advanced Context Engineering from Agents]. Tôi thấy việc thêm skill để mở rộng năng lực của agent là hữu ích, nhưng chưa chắc nó có phù hợp với phát triển thực tế hay không. Ý tưởng hay bộ package tự động thêm nhiều skill thì khá ngầu, nhưng tôi chưa tin nó tốt hơn bao nhiêu so với cách custom command + sub-agent. Tôi định tự thử vài ngày rồi so sánh
Cái này gần giống như đem usage rules trong Elixir áp vào hành vi của agent (hiện tại chỉ dành cho Claude). Cũng đáng tham khảo thêm tài liệu usage_rules
Khi đọc bài này, tôi đã kỳ vọng sẽ học được "cách làm việc tốt hơn với coding agent". Tôi đã thử nghiệm AI suốt 2 năm, và giờ khá chắc rằng nó đã tiến từ mức classifier đồ chơi lên thành một utility dùng được kha khá. Dù vậy, vì liên tục va phải giới hạn nên tôi lại thấy quay về cách làm trước thời LLM còn vững chắc hơn, nhanh hơn và bền vững hơn về mặt tinh thần. Tôi tự hỏi có ai có thể chia sẻ những ví dụ cụ thể mà LLM thực sự đã mở rộng được công việc phát triển tiên tiến hoặc việc tạo ra giá trị hay không
Tôi đề xuất bài của Mitchell đăng sáng nay: bài viết non-trivial vibing
Tôi vẫn thấy hiện tại còn đang ở giai đoạn thử nghiệm. Các chỉ số đo lường tử tế rồi sẽ sớm xuất hiện
Kiểu prompt như thế này (dựng ra tình huống sống còn để kích thích phản ứng "cảm xúc") giờ đã khá lỗi thời rồi. Đã từng có lúc viết hoa những từ như IMPORTANT có tác dụng, nhưng các model gần đây thì chỉ đơn giản làm theo chỉ thị. Không đáng phải khổ sở dùng rồi bảo trì những prompt kiểu này
Bài báo về thuyết phục mà anh ấy nhắc tới thực ra cũng chẳng liên quan gì đến điều anh ấy đang nói. Bài đó chỉ nói về việc dùng prompt thuyết phục để vượt qua sự từ chối do "an toàn đã được huấn luyện", chứ không liên quan đến việc cải thiện mức độ bám sát prompt
Điều khó chịu là bản thân llm cũng vẫn chưa tiến hóa khỏi chuyện này. Nếu bảo chính llm cải thiện prompt của nó thì nó lại đề xuất những kiểu cải tiến như vậy. Điều gây bực nhất khi cộng tác với llm và agent là cảm giác năng lực tự tham chiếu của chúng lúc nào cũng chậm hơn khoảng một thế hệ
Tôi vừa nhìn thấy đoạn dưới đây ở trang đầu là đã thấy khó chịu ngay
XDG spec đã tồn tại mấy chục năm rồi, vậy mà không hiểu sao các app mới cứ tiếp tục làm bẩn HOME của tôi. Còn chuyện dữ liệu thực lại nằm dưới cache/ cũng kỳ cục nữa, nhưng thôi cứ cho qua
Những tài liệu như tài liệu skill phát triển hướng kiểm thử rất khó hiểu nếu đọc như con người. Các "skill" dùng trong dự án này không có định dạng nhất quán nào cả, mà giống hệt đầu ra khi bảo LLM "hãy viết một tài liệu Markdown giải thích X theo từng bước" (thực tế theo bài blog thì đúng là được tạo kiểu đó). Nếu LLM đã học khoảng 100 cuốn sách về TDD rồi, thì tôi không rõ có cần ném thêm cho nó một bản tóm tắt rối rắm như vậy không. Những dự án kiểu này tin rằng chúng đang thêm một thứ gì đó như "siêu năng lực" cho LLM, nhưng thật ra LLM đâu có tự học trong quá trình đó, nên việc dán vài câu thần chú vào đầu prompt không khiến nó thông minh hơn gấp 10 lần. Dĩ nhiên, nếu là tác vụ lặp lại trong một bối cảnh nhất định thì tôi có thể viết sẵn các ràng buộc của mình rồi dán vào đầu prompt, nhưng đó đơn thuần chỉ là cung cấp ngữ cảnh. Không phải LLM có thêm năng lực, mà là nó được cho thêm context. Điều tôi luôn thấy thiếu trong các bài kiểu này là hiếm khi có ví dụ thực tế cho thấy kiểu prompt "bạn có skill X" thực sự cho kết quả khách quan tốt hơn bao nhiêu so với việc cứ giao thẳng công việc mà không nói mấy câu đó
Câu kiểu “Tôi nhận ra các nguyên tắc thuyết phục học được từ sách Influence của Robert Cialdini cũng áp dụng được với LLM, và tôi vui vì nó thực sự hiệu quả” thật sự khiến tôi chỉ muốn thôi đi cho rồi. Tôi không hiểu đây là cái gì nữa, và cảm giác hướng đi đã vượt quá AI lẫn phát triển phần mềm rồi. Tôi công nhận AI coding là một thay đổi mang tính cách mạng, nhưng không có nghĩa mọi thứ đều bị đảo lộn. Cấu trúc và thiết kế cơ bản vẫn cần thiết. Mà bài này thì lại đầy cảm giác như đang kể chuyện phép màu
Về cách nói nó giống “phép màu”, có lẽ cũng không hẳn vậy. Để AI tạo ra một giải pháp nào đó thì nó phải biểu diễn ý định và mục tiêu của người dùng thành vector, nên nếu AI đã học đủ nhiều tài liệu về thuyết phục của con người thì đương nhiên nó có thể phản ánh các yếu tố của kiểu diễn đạt đó. Dĩ nhiên kết quả sẽ rất khác nhau. Cũng như con người, nếu cố gượng ép kỹ thuật tu từ hay các tư thế gượng gạo thì lại trông ngớ ngẩn; việc chỉ nhét chữ in hoa hay các từ bổ nghĩa quá mức để nhấn mạnh vector ý định không phải lúc nào cũng hiệu quả. Nhưng nếu chưa ra được kết quả mong muốn, thì kiểm tra xem prompt có thiếu các yếu tố thuyết phục (như thẩm quyền) hay không rồi bổ sung phần cần thiết vẫn là điều đáng thử
Thật ra chuyện này xưa nay vẫn luôn như vậy. Ngay từ chính cụm từ “AI” đã thế, và các tuyên bố của OpenAI suốt 5 năm qua phần lớn cũng cùng kiểu đó. Nghe thì như thể sẽ thay đổi thế giới, nhưng thực tế đầy những lời phóng đại hoặc tu từ kỹ thuật. Phần lớn chỉ là nhiễu không cần thiết, thỉnh thoảng tôi mới rút được vài thông tin thực sự hữu ích để áp vào workflow của mình. Trong đa số bài viết, phần khoa trương hay làm màu lại nhiều hơn thứ thực sự dùng được
Tôi thấy phản cảm khi gặp các chỉ thị như EXTREMELY_IMPORTANT hay RIGHT NOW. Tôi lo là viết kiểu này rồi sớm muộn cũng sẽ đến lúc xung đột với các mức ưu tiên thực sự của tôi. Không thể cái gì cũng là ưu tiên số 1 cao nhất được
Nó giống như quản lý file bashrc vậy. Thỉnh thoảng vẫn phải tự chỉnh tay
Dạo này llm chẳng phải còn hay khuyên đừng dùng kiểu mệnh lệnh như vậy sao?
Tôi không thấy ví dụ code nào trong bài cả. Không biết có thể xem ví dụ dùng thực tế ở đâu
Tôi thấy những bài blog kiểu này sẽ hữu ích hơn nhiều nếu thực sự cho thấy ai đó dùng công cụ này để tạo ra thứ gì đó không tầm thường. Ví dụ, cho Claude đọc sách rồi liệu nó có thực sự học được skill mới hay chỉ đang phản ứng với prompt khiến nó hành xử như vậy thì rất khó phân biệt. Vì thế tôi nghĩ nên trình diễn cả hai trường hợp: sau khi cho Claude thêm skill, và khi chỉ đưa prompt bình thường. Có thể quan điểm của tôi hơi bảo thủ, nhưng đa số blog kiểu này khá giống nội dung mang tính marketing, và thường bỏ sót hoặc giải thích không đủ các điểm thật sự quan trọng, nên tạo cảm giác như đang phóng đại công việc của mình để khoe khoang
Có một ví dụ liên quan được đăng hôm nay: bài non-trivial vibing
Dùng LLM lâu dài để code các dự án phức tạp thực sự rất khó! Chỉ riêng việc định nghĩa yêu cầu thôi đã khó hơn nhiều so với tưởng tượng, mà LLM lại lao rất nhanh theo cả hướng sai
Phương pháp cần có trong lĩnh vực này là các thí nghiệm chứng minh hiệu quả của công cụ bằng chỉ số định lượng kiểu A/B test. Không phải làm một lần là đủ, mà phải phân tích lặp lại trong nhiều kịch bản khác nhau để có độ tin cậy thống kê. Điều khó nhất khi dùng coding agent là với codebase nhỏ và đơn giản thì lúc đầu trông có vẻ làm tốt, nhưng khi codebase lớn dần và độ phức tạp tăng lên, ở những tác vụ có nhiều liên kết phức tạp, nó rất dễ rơi vào “tunnel vision” và làm tăng technical debt
Tôi nghĩ cứ trực tiếp dùng code của Claude rồi mỗi người tự rút ra kết luận cho mình là được
“Phần lớn blog kiểu này đều bỏ qua chi tiết quan trọng, thổi phồng năng lực bản thân và khoe khoang — đúng mô típ quen thuộc của ngành IT từ xưa đến nay.” Thành thật mà nói, đó là cảnh quen thuộc của IT ở mọi thế hệ
Có lúc AI tạo ra code rồi tự dưng gắn thêm giấy phép bản quyền, mà tôi không hiểu vì sao. May là giấy phép MIT nên còn đỡ, nhưng sản phẩm do AI tạo ra thì về mặt pháp lý lại không thuộc đối tượng được bảo hộ bản quyền, nên về cơ bản ai cũng có thể bỏ qua giấy phép đó mà dùng. Tôi tò mò không biết tại sao lại gắn vào