blueprint

Tổng quan về blueprint skill

blueprint làm gì

blueprint skill biến một mục tiêu chỉ với một dòng mô tả thành một kế hoạch triển khai từng bước cho các công việc kỹ thuật phức tạp. Skill này được thiết kế cho các tác vụ nhiều phiên, nhiều PR, nơi một agent mới cần đủ ngữ cảnh để tiếp tục mà không phải đoán. Nếu bạn cần một blueprint cho Project Setup, lộ trình migration, hoặc kế hoạch refactor có phụ thuộc giữa các bước, đây là một lựa chọn rất phù hợp.

Ai nên cài đặt

Hãy cài blueprint nếu bạn thường xuyên bàn giao công việc giữa các phiên, điều phối các tác vụ con chạy song song, hoặc cần một kế hoạch vẫn dùng tốt khi mất ngữ cảnh. Skill này đặc biệt hữu ích cho các agent làm việc trong một repo có sẵn, nơi thách thức thực sự là sắp xếp thứ tự công việc an toàn chứ không phải nảy ra ý tưởng.

Điểm khác biệt của nó

Không giống một prompt chung chung, blueprint tích hợp sẵn quy tắc kích hoạt, thứ tự phụ thuộc, phát hiện bước có thể làm song song, một cổng review mang tính đối kháng, và giao thức chỉnh sửa kế hoạch. Điều đó rất quan trọng khi rủi ro chính không phải là viết code, mà là chọn sai thứ tự, ước lượng thiếu phạm vi của một bước, hoặc bỏ sót đường rollback.

Cách dùng blueprint skill

Cài đặt và kích hoạt đúng cách

Cài blueprint skill bằng trình cài đặt skill chuẩn của directory, rồi chỉ gọi nó khi tác vụ thật sự nhiều giai đoạn. Quy tắc kích hoạt của repo này được đặt có chủ đích rất hẹp: chỉ dùng cho plan, blueprint, hoặc roadmap khi công việc có khả năng cần nhiều phiên hoặc nhiều PR; đừng dùng cho một thay đổi nhỏ có thể hoàn thành trong một lượt.

Cung cấp đúng đầu vào nguồn

blueprint hoạt động tốt nhất khi đầu vào nêu rõ mục tiêu, repo đích, ràng buộc, và định nghĩa hoàn thành. Một prompt yếu là “lên kế hoạch refactor.” Một prompt mạnh hơn là: “Create a blueprint for Project Setup: move config loading into a shared module, keep backward compatibility for two releases, and separate UI changes from backend migration.” Phạm vi càng cụ thể, đồ thị phụ thuộc và độ chia nhỏ của từng bước càng tốt.

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

Bắt đầu bằng SKILL.md, rồi xem các tài liệu trong repo mô tả workflow, quy ước, hoặc các plan hiện có. Trong repository này, phần nội dung của skill là tự chứa, nên điều quan trọng nhất cần rút ra là pipeline: quy tắc research, design, review, và mutation. Nếu codebase đích có các file memory, tài liệu kiến trúc, hoặc ghi chú migration trước đó, chúng sẽ cải thiện đáng kể đầu ra của blueprint.

Workflow giúp đầu ra tốt hơn

Hãy dùng blueprint theo ba lượt: trước hết tạo plan, sau đó kiểm tra xem các bước có thật sự độc lập được không, rồi chỉnh lại để bổ sung phần phụ thuộc còn thiếu hoặc loại bỏ tính song song không an toàn. Hãy chú ý những bước cần cùng một file, dùng chung state, hoặc phụ thuộc vào thứ tự release; đó là các trường hợp mà một plan nhìn rất gọn nhưng khi triển khai lại dễ hỏng. Cách dùng blueprint tốt nhất không phải là “thêm thật nhiều chi tiết,” mà là “sắp xếp đúng thứ tự với đủ ngữ cảnh để có thể triển khai từ trạng thái lạnh.”

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

blueprint có chỉ dành cho dự án lớn không?

Đa phần là có. Skill này được xây dựng cho những công việc quá lớn để gói trong một PR hoặc sẽ rủi ro nếu làm mà không có plan. Nếu tác vụ nhỏ, rõ ràng, hoặc có thể hoàn thành chỉ với vài lần gọi tool, thì một prompt bình thường thường nhanh hơn.

blueprint khác gì so với một prompt thông thường?

Một prompt thông thường có thể yêu cầu một plan, nhưng blueprint bổ sung cấu trúc: phụ thuộc giữa các bước, phát hiện khả năng chạy song song, suy nghĩ về rollback, và một lớp review để bắt các giả định yếu. Điều đó giúp nó đáng tin cậy hơn khi bạn cần một blueprint cho Project Setup hoặc một tác vụ khác mà thứ tự và chất lượng bàn giao là yếu tố quyết định.

blueprint có phù hợp với người mới không?

Có, nếu mục tiêu là học cách chia một dự án thành các giai đoạn có thể quản lý được. Nó ít hữu ích hơn nếu bạn هنوز đang quyết định chính xác bài toán là gì, vì skill này giả định đã có một mục tiêu kỹ thuật thật sự, có ràng buộc và có đường đi tới hoàn thành.

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

Đừng dùng blueprint khi công việc đủ nhỏ để làm trực tiếp xong ngay, khi người dùng nói rõ “just do it,” hoặc khi tác vụ không có cấu trúc phụ thuộc đáng kể. Trong những trường hợp đó, phần chi phí cho kế hoạch có thể làm chậm bạn mà không cải thiện kết quả.

Cách cải thiện blueprint skill

Nêu rõ ranh giới

Đầu ra blueprint tốt nhất đến từ phạm vi được giới hạn rõ: phải thay đổi gì, phải giữ ổn định gì, phần nào nằm ngoài phạm vi, và tiêu chí nào được tính là thành công. Nếu bạn muốn một blueprint cho Project Setup, hãy nói rõ bạn đang thay đổi bootstrapping của repo, cấu hình môi trường, thiết lập CI, hay cả ba. Phạm vi mơ hồ là cách nhanh nhất để nhận được một plan hoặc quá lớn, hoặc quá nông.

Cung cấp tín hiệu phụ thuộc ngay từ đầu

blueprint mạnh nhất khi nó biết phần nào đang chặn phần nào. Hãy nhắc đến migrations, shared modules, feature flags, API contracts, thứ tự release, và bất kỳ thứ gì phải hoàn tất trước khi một bước khác có thể bắt đầu. Điều này giúp skill tạo ra một đồ thị phụ thuộc hữu ích thay vì một danh sách việc rời rạc.

Yêu cầu các bước sẵn sàng để triển khai

Nếu bạn muốn đầu ra blueprint skill tốt hơn, hãy yêu cầu các bước mà một agent mới có thể thực thi ngay từ trạng thái lạnh. Điều đó có nghĩa là mỗi bước cần đủ ngữ cảnh, kết quả kỳ vọng, và ghi chú rủi ro để không phải đọc lại toàn bộ repo. Điều này đặc biệt quan trọng với công việc nhiều agent, nơi một tiêu đề bước quá mơ hồ sẽ dẫn đến làm lại.

Lặp lại trên bản plan đầu tiên

Hãy xem blueprint đầu tiên như bản nháp, rồi tinh chỉnh sau khi kiểm tra các ràng buộc còn thiếu, phần việc song song có thể xung đột, hoặc những bước quá lớn cho một PR. Nếu plan quá rộng, hãy chia nhỏ; nếu nó quá chi tiết, hãy gộp các phần setup lặp lại. Mục tiêu không phải là một dàn ý đẹp hơn, mà là một blueprint giúp giảm rủi ro khi triển khai.