brainstorming

Tổng quan về brainstorming skill

brainstorming skill dùng để làm gì

brainstorming skill là một quy trình tiền triển khai có cấu trúc, giúp biến một ý tưởng còn thô thành một thiết kế đã được phê duyệt trước khi viết bất kỳ dòng code nào. Vai trò chính của nó không phải là “nảy ý tưởng” theo nghĩa chung chung; mục tiêu là giảm làm lại bằng cách buộc phạm vi, giả định, yêu cầu và các lựa chọn thiết kế phải được làm rõ ngay từ đầu.

Ai nên cài brainstorming skill

brainstorming skill đặc biệt phù hợp với những người thường đi quá nhanh từ “chúng ta nên xây X” sang triển khai. Nó особенно hữu ích cho:

• lập kế hoạch tính năng
• thiết kế component
• thay đổi hành vi hệ thống
• đề xuất công cụ nội bộ
• brainstorming cho Requirements Planning

Nếu bạn đã có sẵn một quy trình viết spec chặt chẽ, skill này vẫn hữu ích như một lớp tiền xử lý gọn nhẹ trước quy trình đó.

Điểm khác biệt so với một prompt thông thường

Điểm khác biệt quan trọng nằm ở rào chắn cứng trong SKILL.md: agent không được triển khai, scaffold hay viết code cho đến khi đã trình bày thiết kế và nhận được phê duyệt. Nghe có vẻ đơn giản, nhưng trên thực tế nó thay đổi hành vi đáng kể so với kiểu prompt thông thường như “hãy giúp tôi build cái này”, nơi trợ lý thường nhảy thẳng vào lời giải.

Trước khi cài, người dùng thực sự quan tâm điều gì

Phần lớn người dùng muốn biết nhanh ba điều:

1. Nó có làm chậm tiến độ của tôi không?
2. Nó có đặt câu hỏi hữu ích thay vì hỏi chung chung không?
3. Nó có hỗ trợ trao đổi về thiết kế trực quan không?

Câu trả lời là: nó cố ý thêm một lớp quy trình, nhưng chi phí đó vẫn nhỏ nếu ý tưởng nhỏ. Skill này nêu rất rõ rằng ngay cả những việc tưởng như “đơn giản” cũng cần một vòng duyệt thiết kế ngắn, vì đây chính là nơi các giả định ẩn dễ biến thành sai sót tốn kém.

Cách dùng brainstorming skill

Cài đặt và thiết lập brainstorming skill

Để thêm skill từ repository, dùng:
npx skills add https://github.com/obra/superpowers --skill brainstorming

Sau khi cài xong, hãy mở các file này trước:

• skills/brainstorming/SKILL.md
• skills/brainstorming/visual-companion.md
• skills/brainstorming/spec-document-reviewer-prompt.md

Nếu bạn dự kiến sẽ cần khám phá theo hướng trực quan, hãy xem thêm:

• skills/brainstorming/scripts/start-server.sh
• skills/brainstorming/scripts/frame-template.html

Quy trình cốt lõi mà brainstorming skill kỳ vọng

Cách dùng brainstorming skill có chủ đích khá rõ ràng:

1. khám phá ngữ cảnh dự án
2. nếu phù hợp thì đề xuất visual companion
3. đặt câu hỏi làm rõ từng câu một
4. tổng hợp thành thiết kế
5. lấy phê duyệt rõ ràng
6. chỉ sau đó mới chuyển sang lập kế hoạch hoặc triển khai

Nếu agent của bạn nhảy từ ý tưởng sang code, thì thực chất nó chưa làm đúng theo skill này.

Cần cung cấp đầu vào gì để dùng brainstorming skill hiệu quả hơn

brainstorming skill hoạt động tốt nhất khi bạn cung cấp nhiều hơn một tiêu đề tính năng. Đầu vào khởi đầu tốt thường gồm:

• vấn đề cần giải quyết
• người dùng là ai
• ngữ cảnh hệ thống hoặc repo hiện tại
• các ràng buộc
• thế nào là “xong”
• những gì đã biết là không nằm trong mục tiêu

Một đầu vào yếu:

Add notifications.

Một đầu vào mạnh hơn:

Add in-app notifications for failed background imports. Users are operations staff, not end customers. We already have email alerts, but they are too slow for live triage. Keep scope to the admin dashboard only. Do not add mobile push or user preference management in v1.

Phiên bản thứ hai cho brainstorming skill đủ cấu trúc để đặt các câu hỏi tiếp theo sắc nét hơn.

Cách biến một ý tưởng thô thành prompt mở đầu mạnh hơn

Một mẫu prompt thực tế cho brainstorming:

Use the brainstorming skill for Requirements Planning.
Context: [project/repo/product]
Problem: [what is happening now]
Target user: [who is affected]
Constraints: [timeline, stack, compliance, UX, compatibility]
Non-goals: [what not to solve]
Please ask clarifying questions one at a time, then present a proposed design for approval before any implementation.

Mẫu này bám sát luồng dùng mà skill hướng tới và giảm khả năng rơi vào kiểu hỏi đáp chung chung.

Câu hỏi làm rõ nên vận hành như thế nào

Một hành vi tinh tế nhưng rất quan trọng: skill này kỳ vọng các câu hỏi được hỏi từng câu một, chứ không phải một bảng câu hỏi khám phá thật dài. Điều này quan trọng vì mỗi câu trả lời thường sẽ làm thay đổi câu hỏi tiếp theo. Nếu agent dồn ra 15 câu hỏi cùng lúc, bạn sẽ mất đi khả năng tinh chỉnh tương tác mà hướng dẫn brainstorming này được thiết kế để tạo ra.

Khi nào nên dùng visual companion

Repository có sẵn một visual companion chạy trong trình duyệt. Hãy dùng nó khi người dùng sẽ hiểu các phương án tốt hơn nếu được nhìn thấy:

• wireframe
• so sánh layout
• luồng UI
• sơ đồ kiến trúc
• hình dung state hoặc mối quan hệ

Đừng dùng chỉ vì chủ đề có nhắc đến UI. Một câu hỏi mang tính khái niệm như “nên làm wizard hay modal?” vẫn có thể xử lý bằng văn bản. Nhưng một câu hỏi như “trong hai layout wizard này, cái nào rõ ràng hơn?” thì rất phù hợp với hướng trực quan.

Visual companion thực sự được phục vụ như thế nào

Trợ lý trực quan này không chỉ là tài liệu; repository có sẵn các script để chạy một phiên cục bộ:

• scripts/start-server.sh
• scripts/stop-server.sh
• scripts/server.cjs
• scripts/helper.js

start-server.sh khởi chạy một server cục bộ trên một cổng cao ngẫu nhiên và có thể lưu file session dưới /tmp hoặc trong thư mục dự án như .superpowers/brainstorm/. Điều này hữu ích nếu bạn muốn các mockup được giữ lại qua nhiều phiên làm việc.

Ghi chú thực tế về môi trường trước khi phụ thuộc vào phần trực quan

Quy trình trực quan giả định môi trường của bạn có thể truy cập được qua trình duyệt. Nếu bạn đang làm việc trong remote container, VM hoặc qua SSH, hãy chú ý đến:

• --host
• --url-host
• độ bền lưu trữ của thư mục session

Nếu chỉ dùng cục bộ, thiết lập mặc định khá đơn giản. Nhưng với môi trường chia sẻ hoặc từ xa, bạn nên tính trước chi tiết mạng trước khi xây dựng cả workflow xoay quanh phản hồi trên trình duyệt.

Thứ tự đọc file tốt nhất để làm quen nhanh

Nếu bạn muốn đi theo con đường ngắn nhất nhưng vẫn đạt chất lượng dùng thực tế, hãy đọc theo thứ tự sau:

1. SKILL.md để nắm “hợp đồng hành vi”
2. visual-companion.md để biết khi nào hỗ trợ trình duyệt thực sự hữu ích
3. spec-document-reviewer-prompt.md để hiểu thế nào là “đủ tốt để triển khai”
4. scripts/start-server.sh nếu bạn cần nhánh workflow trực quan

Thứ tự này giúp bạn nắm logic ra quyết định trước, rồi mới đến công cụ tùy chọn.

Đầu ra tốt từ brainstorming skill nên trông như thế nào

Một phiên brainstorming skill thành công nên kết thúc bằng một thiết kế đủ cụ thể để review, bao gồm:

• mục tiêu và người dùng
• ranh giới phạm vi
• các quyết định chính
• rủi ro hoặc giả định còn mở
• mức độ cụ thể đủ để lập kế hoạch triển khai

Nếu đầu ra chỉ là một danh sách ý tưởng lỏng, nghĩa là phiên làm việc đã dừng quá sớm.

Cách dùng brainstorming skill cho Requirements Planning

Với brainstorming cho Requirements Planning, hãy dùng skill này như bước tiền spec:

1. làm rõ vấn đề và các ràng buộc
2. phác thảo hình dạng của thiết kế hoặc yêu cầu
3. lấy phê duyệt
4. viết spec
5. nếu cần thì chạy mẫu prompt review spec

Đây là một trong những cách dùng mạnh nhất của skill, vì nó giúp phát hiện scope drift và sự mơ hồ trước khi kế hoạch bị khóa cứng.

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

brainstorming skill chỉ dành cho dự án lớn?

Không. Skill này nêu rất rõ rằng không nên mặc định việc “nhỏ” thì có thể bỏ qua bước thiết kế. Với thay đổi rất nhỏ, phần thiết kế có thể ngắn, nhưng bước này vẫn quan trọng. Giá trị của nó thường cao nhất ở những thay đổi tưởng như đơn giản nhưng lại chứa nhiều giả định chưa được kiểm chứng.

Nó có tốt hơn các prompt brainstorming thông thường không?

Thường là có, nếu mục tiêu thực sự của bạn là đạt được sự rõ ràng đủ để triển khai, chứ không phải tạo ra thật nhiều ý tưởng. Một prompt brainstorming thông thường có thể sinh ra nhiều phương án. brainstorming skill phù hợp hơn khi bạn cần tư duy hội tụ: hiểu ngữ cảnh, thu hẹp lựa chọn và tạo ra một thiết kế đã được phê duyệt.

brainstorming skill có thân thiện với người mới bắt đầu không?

Có, đặc biệt với người làm một mình và chưa hình thành thói quen lập kế hoạch. Cấu trúc của skill bù lại cho một lỗi rất phổ biến ở người mới: triển khai ngay ý tưởng đầu tiên nghe có vẻ hợp lý mà chưa làm rõ yêu cầu hoặc đánh đổi.

Khi nào brainstorming skill không phù hợp?

Hãy bỏ qua hoặc rút ngắn bước này khi:

• tác vụ chỉ mang tính cơ học và đã được đặc tả đầy đủ
• bạn không phải đưa ra quyết định về thiết kế hay hành vi
• người dùng đã phê duyệt một spec chi tiết và giờ chỉ cần thực thi

Ngay cả trong các trường hợp đó, bạn vẫn nên kiểm tra xem rào chắn cứng của skill có xung đột với workflow của mình hay không. Skill này được thiết kế để nghiêm ngặt một cách có chủ đích.

Skill này có sinh code không?

Không, và đó là chủ ý. brainstorming skill được thiết kế để dừng trước bước triển khai cho đến khi có phê duyệt. Nếu bạn muốn sinh code, hãy dùng skill này trước, sau đó chuyển sang một skill lập kế hoạch hoặc triển khai sau khi đã được duyệt.

Tôi có cần visual companion thì mới thấy giá trị không?

Không. Nhánh làm việc qua trình duyệt là tùy chọn. Dùng brainstorming skill chỉ bằng văn bản vẫn mang lại phần lớn giá trị cho thảo luận về yêu cầu, phạm vi và đánh đổi kỹ thuật. Các công cụ trực quan chỉ thực sự quan trọng khi chính quyết định cần đưa ra mang tính trực quan.

Cách cải thiện brainstorming skill

Cung cấp ngữ cảnh dự án phong phú hơn cho brainstorming skill

Cách nhanh nhất để cải thiện kết quả là neo cuộc thảo luận vào bối cảnh thực:

• các file hoặc thư mục liên quan
• hành vi hiện tại
• thay đổi gần đây
• các ràng buộc kỹ thuật đã biết
• nhóm người dùng bị ảnh hưởng

Bản thân skill đã hướng agent khám phá ngữ cảnh dự án trước. Hãy hỗ trợ nó bằng cách chỉ rõ ngữ cảnh đó nằm ở đâu.

Nêu ràng buộc và non-goals từ sớm

Nhiều đầu ra brainstorming yếu xuất phát từ ranh giới chưa được xác định đủ rõ. Hãy nói cho skill biết những gì bắt buộc phải giữ hoặc phải tránh:

• backward compatibility
• giới hạn hiệu năng
• yêu cầu về compliance hoặc bảo mật
• giới hạn về thời gian hoặc nhân sự
• các tính năng bị loại trừ rõ ràng khỏi phạm vi

Làm vậy sẽ cho ra các thiết kế hẹp hơn nhưng hữu ích hơn cho quyết định.

Hãy yêu cầu một thiết kế, không chỉ là ý tưởng

Nếu bạn muốn đầu ra sẵn sàng cho triển khai, hãy nói thẳng điều đó. Yêu cầu brainstorming skill kết thúc bằng:

• một proposed design
• các giả định
• các câu hỏi chưa giải quyết
• một mốc phê duyệt rõ ràng

Cách này kéo phiên làm việc ra khỏi vòng lặp ideation vô tận và hướng tới một hiện vật có thể sử dụng được.

Dùng prompt mạnh hơn cho visual brainstorming

Với bài toán trực quan, đừng chỉ nói “show mockups.” Hãy chỉ rõ hình ảnh cần so sánh điều gì:

Show two dashboard layout options for failed import alerts: one optimized for fast triage, one optimized for detail review. Keep the existing navigation shell. Highlight which option better supports keyboard-heavy operators.

Kiểu prompt này giúp visual companion tạo ra đầu ra phục vụ quyết định, thay vì chỉ là các màn hình mang tính trang trí.

Theo dõi lỗi chính: lao vào lời giải quá sớm

Kiểu thất bại lớn nhất là nhảy vào chi tiết triển khai trước khi thật sự hiểu vấn đề. Nếu điều đó xảy ra, hãy kéo phiên làm việc trở lại:

Pause implementation thinking. What assumptions are we making about the user workflow, edge cases, and scope boundaries?

Cách nhắc này giữ cho hướng dẫn brainstorming bám đúng mục tiêu cốt lõi của nó.

Cải thiện đầu ra đầu tiên bằng một vòng review tập trung

Sau bản thiết kế ban đầu, hãy yêu cầu một bản chỉnh sửa có trọng tâm thay vì bắt đầu lại từ đầu:

• điểm nào còn mơ hồ?
• điểm nào đang bị over-engineered?
• điểm nào sẽ cản trở việc lập kế hoạch triển khai?
• còn thiếu gì để có thể phê duyệt?

spec-document-reviewer-prompt.md trong repository đặc biệt hữu ích ở đây vì nó hiệu chỉnh việc review theo các điểm chặn lập kế hoạch thực tế, chứ không phải các chỉnh sửa mang tính hình thức.

Giữ hiện vật brainstorming nhỏ gọn nhưng đủ để ra quyết định

Một lỗi phổ biến là làm bản thiết kế phình to với các chi tiết không cần thiết. Brainstorming tốt hơn không có nghĩa là brainstorming dài hơn. Với công việc đơn giản, chỉ vài đoạn ngắn nhưng chặt chẽ bao quát mục đích, phạm vi, ràng buộc, cách tiếp cận và phê duyệt là đã đủ. Chuẩn đánh giá không nằm ở độ dài tài liệu; nó nằm ở việc bước tiếp theo có thể tiến hành với ít phỏng đoán hơn hay không.

Kết hợp brainstorming skill với một bước review spec

Nếu bạn nghiêm túc áp dụng skill này, hãy ghép nó với một bước review tiếp theo dành cho spec hoặc thiết kế được tạo ra. Mẫu reviewer đi kèm sẽ kiểm tra:

• placeholder
• mâu thuẫn
• yêu cầu mơ hồ
• phạm vi quá rộng
• độ phức tạp không được yêu cầu

Nhờ vậy, brainstorming skill hữu ích hơn trong một quy trình giao hàng thực tế, chứ không chỉ dừng ở hội thoại.