spec-driven-development
bởi addyosmanispec-driven-development là một skill quy trình để viết spec trước khi viết code, rồi đi qua các bước lập kế hoạch, chia việc và triển khai với đánh giá của con người ở mỗi giai đoạn.
Skill này đạt 74/100, là một ứng viên khá tốt nhưng chưa phải hàng đầu. Với người dùng thư mục, điều đó có nghĩa là nó thực sự hữu ích cho các agent cần quy trình làm việc ưu tiên spec, đủ cấu trúc để giảm suy đoán, nhưng vẫn còn thiếu file hỗ trợ và hướng dẫn đóng gói khiến việc áp dụng chưa thật sự liền mạch.
- Hướng dẫn kích hoạt rõ ràng: dùng khi bắt đầu một dự án mới, một tính năng mới, hoặc một thay đổi còn mơ hồ, và nêu rõ không phù hợp cho các sửa lỗi nhỏ.
- Quy trình vận hành chặt chẽ: bốn giai đoạn có điểm chặn (Specify → Plan → Tasks → Implement) với việc con người xem xét ở từng bước.
- Độ sâu thực tiễn tốt: nội dung SKILL.md khá đầy đủ với nhiều heading, ràng buộc và ví dụ code, giúp agent dễ bám theo quy trình hơn.
- Không có file hỗ trợ hoặc lệnh cài đặt: việc áp dụng gần như hoàn toàn phụ thuộc vào hướng dẫn trong SKILL.md.
- Chỉ phát hành dưới dạng một file: không có script, tài liệu tham chiếu hay tài nguyên bổ trợ để củng cố quy trình hoặc xử lý các tình huống biên.
Tổng quan về skill spec-driven-development
spec-driven-development là một skill cho quy trình làm việc, giúp viết một bản spec rõ ràng trước khi viết code, rồi dùng bản spec đó để định hướng kế hoạch, chia việc và triển khai. spec-driven-development phù hợp nhất khi bạn bắt đầu một tính năng mới, thay đổi kiến trúc, hoặc làm việc từ yêu cầu còn mơ hồ và cần giảm tối đa giả định trong bản dựng cuối cùng.
Skill này dùng để làm gì
Hãy dùng hướng dẫn spec-driven-development này khi rủi ro lớn nhất là làm sai thứ cần xây, chứ không chỉ làm chưa tốt. Nó giúp bạn biến một ý tưởng sơ bộ thành một nguồn thông tin chung có thể dùng làm chuẩn, xác định phạm vi, hành vi, ràng buộc và tiêu chí chấp nhận trước khi bạn chốt hướng triển khai.
Trường hợp áp dụng phù hợp nhất
Skill này hợp với cả team lẫn cá nhân muốn đồng bộ chặt hơn với người review, đặc biệt khi một tác vụ liên quan nhiều file, phụ thuộc vào quyết định sản phẩm, hoặc đủ lớn để kiểu “cứ code đi” dẫn đến làm lại. Nó cũng hữu ích cho spec-driven-development trong Skill Authoring khi bạn muốn chính skill này tạo ra đầu ra có kỷ luật và có thể review được.
Điểm khác biệt của nó
Giá trị cốt lõi nằm ở quy trình có chốt kiểm soát: xác định spec, rồi lập kế hoạch, rồi chia task, rồi mới triển khai, với người review ở mỗi bước. Nhờ vậy nó mạnh hơn một prompt chung chung vì giảm các giả định ẩn và buộc các điểm phải quyết định được đưa ra sớm hơn, lúc thay đổi còn ít tốn kém.
Cách dùng skill spec-driven-development
Cài đặt và nạp bối cảnh
Để cài spec-driven-development, hãy thêm skill này vào cấu hình skills của agent rồi mở file skill trước tiên:
npx skills add addyosmani/agent-skills --skill spec-driven-development
Sau đó đọc SKILL.md trước mọi thứ khác. Repository này không có các thư mục hỗ trợ như rules/, references/ hay scripts/, nên phần bối cảnh của skill gần như nằm hoàn toàn trong file skill chính.
Đưa cho skill một điểm xuất phát cụ thể
Mẫu sử dụng của spec-driven-development hiệu quả nhất khi bạn cung cấp mục tiêu, ràng buộc và những điều chưa chắc chắn. Đầu vào yếu là kiểu “xây một dashboard.” Đầu vào mạnh sẽ giống như:
“Create a spec for a dashboard that shows subscription health, supports role-based access, and must work with our existing REST API. Ask clarifying questions before drafting the spec. Do not propose implementation details yet.”
Cách này cho skill đủ bối cảnh để phát hiện giả định và tránh thiết kế quá sớm.
Đi theo quy trình có chốt kiểm soát
Skill này được thiết kế để dừng ở từng giai đoạn cho đến khi được xác nhận. Trong thực tế, điều đó có nghĩa là:
- Xác định vấn đề và các giả định.
- Lên phương án sau khi spec được duyệt.
- Tách plan thành các task.
- Chỉ triển khai sau khi task đã được review.
Nếu bạn bỏ qua các chốt review, bạn sẽ mất lợi ích chính của skill: ít phải làm lại hơn do giả định chưa được kiểm chứng.
Đọc trước, dùng sau
Bắt đầu với SKILL.md, rồi dùng các phần overview, when to use và gated workflow như nguyên tắc vận hành. Nếu bạn đang điều chỉnh skill này cho luồng agent riêng của mình, hãy giữ lại các điểm kiểm tra review và hành vi “hỏi cho đến khi cụ thể”, vì đó là những phần có khả năng cải thiện chất lượng đầu ra nhiều nhất.
Câu hỏi thường gặp về skill spec-driven-development
spec-driven-development có tốt hơn prompt bình thường không?
Thường là có, khi tác vụ mơ hồ, ảnh hưởng nhiều phần, hoặc tốn kém nếu phải làm lại. Prompt bình thường có thể tạo code nhanh, nhưng spec-driven-development tốt hơn khi bạn cần thống nhất phải xây gì trước khi ai đó bắt đầu code.
Khi nào không nên dùng?
Đừng dùng skill spec-driven-development cho các chỉnh sửa nhỏ, lỗi rõ ràng dễ sửa, hoặc thay đổi khép kín không có nhiều mơ hồ về sản phẩm. Trong các trường hợp đó, chi phí của một vòng spec đầy đủ có thể còn chậm hơn bản thân công việc.
Có thân thiện với người mới không?
Có, nếu bạn sẵn sàng trả lời câu hỏi làm rõ và review bản nháp. Skill này dễ dùng hơn việc tự nghĩ ra một quy trình riêng vì nó bảo agent tạm dừng, nêu giả định và đi qua từng giai đoạn theo đúng thứ tự.
Có phù hợp với workflow Skill Authoring không?
Có, đặc biệt là với spec-driven-development cho Skill Authoring khi bạn muốn một quy trình lặp lại được để viết skill mới hoặc nâng cấp skill hiện có. Nó hữu ích nhất khi tác vụ authoring cần phạm vi rõ ràng, các chốt review và một bản spec có thể được kiểm chứng trước khi triển khai.
Cách cải thiện skill spec-driven-development
Cung cấp đầu vào sắc nét hơn ngay từ đầu
Kết quả tốt nhất đến từ việc nêu rõ người dùng mục tiêu, kết quả mong muốn, ràng buộc và phần còn chưa biết. Ví dụ: “Migrate the checkout flow without changing the public API, preserve existing analytics events, and identify any dependency risks before planning.”
Buộc skill nêu rõ các giả định
Một lỗi thường gặp là spec nghe có vẻ đầy đủ nhưng lại che mất những quyết định then chốt. Hãy yêu cầu model liệt kê các giả định trước khi viết spec, rồi review các giả định đó với kỹ sư trước khi chuyển sang lập kế hoạch. Đây thường là chỗ spec-driven-development tiết kiệm thời gian nhiều nhất.
Lặp trên spec, không lặp trên code
Nếu bản đầu chưa ổn, hãy sửa phạm vi, tiêu chí chấp nhận hoặc ràng buộc trước khi yêu cầu triển khai. Quy trình này hiệu quả nhất khi mỗi vòng sửa làm chặt thêm “hợp đồng”, vì các giai đoạn sau phụ thuộc vào độ chính xác của spec.
Dùng khi chi phí review cao
Skill này giá trị nhất khi giả định sai sẽ rất tốn kém: thay đổi nhiều file, dịch chuyển kiến trúc, hoặc tính năng ảnh hưởng đến nhiều bên liên quan. Nếu bản nháp đầu tiên của spec vẫn còn mơ hồ, hãy giữ nó ở giai đoạn spec lâu hơn thay vì ép sang task hay code quá sớm.