context-driven-development

Tổng quan về skill context-driven-development

Skill context-driven-development làm gì

context-driven-development giúp bạn tạo và duy trì một bộ nhỏ các artifact ngữ cảnh dự án trong thư mục conductor/ để quá trình phát triển có AI hỗ trợ luôn có nền tảng ổn định, tái sử dụng được. Thay vì phải giải thích lại dự án trong từng cuộc trò chuyện, bạn xác định các tài liệu cốt lõi như product.md, tech-stack.md, workflow.md và tracks.md, rồi cập nhật chúng khi dự án thay đổi theo thời gian.

Ai nên cài skill này

Skill này phù hợp nhất với những người đang dùng workflow kiểu Conductor, phát triển với AI qua nhiều phiên, hoặc làm việc trong môi trường nhóm nơi mục tiêu dự án, lựa chọn stack và cách theo dõi công việc cần được giữ nhất quán xuyên suốt các prompt. Skill đặc biệt hữu ích cho:

• khởi tạo dự án mới
• onboarding AI agent vào codebase sẵn có
• các nhóm muốn có ngữ cảnh dự án lặp lại, dùng lại được
• người dùng thấy mệt vì liên tục mất ngữ cảnh giữa các phiên

Bài toán thực sự mà skill này giải quyết

Phần lớn người dùng không cần “thêm tài liệu”. Họ cần đầu ra từ AI bớt lệch hướng. Công việc thực tế của context-driven-development là biến kiến thức dự án còn mơ hồ, chỉ tồn tại trong từng phiên, thành các artifact được quản lý và có thể tồn tại xuyên suốt các tác vụ triển khai, lập kế hoạch và bàn giao.

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

Một prompt bình thường có thể mô tả ứng dụng của bạn một lần. context-driven-development skill cho bạn một cấu trúc để giữ phần mô tả đó luôn cập nhật và nhất quán nội bộ theo thời gian. Điểm khác biệt của nó không nằm ở việc tự sinh code, mà ở lớp scaffold ngữ cảnh và cơ chế đồng bộ trước, trong khi phát triển.

Bạn nhận được gì nếu skill này phù hợp

Nếu bạn dùng context-driven-development for Context Engineering, lợi ích lớn nhất là tính liên tục tốt hơn:

• mục tiêu sản phẩm rõ ràng hơn
• quyết định về stack được ghi lại
• kỳ vọng về workflow được thể hiện rõ
• công việc được theo dõi thành đơn vị cụ thể thay vì TODO rời rạc
• onboarding agent tốt hơn cho các repo brownfield

Khi nào đây không phải lựa chọn phù hợp

Bỏ qua skill này nếu bạn chỉ cần một đoạn code dùng một lần, không có ý định duy trì tài liệu dự án, hoặc không làm việc theo kiểu workflow mà ngữ cảnh bền vững giúp cải thiện kết quả về sau. Skill này tạo giá trị lớn nhất khi cùng một dự án sẽ được chạm vào nhiều lần.

Cách dùng skill context-driven-development

Bối cảnh cài đặt và vị trí của skill này

Skill này đến từ repository wshobson/agents, nằm tại plugins/conductor/skills/context-driven-development. Cách cài đặt cơ bản trong các môi trường hỗ trợ Skills là:

npx skills add https://github.com/wshobson/agents --skill context-driven-development

Sau khi cài, hãy gọi skill này từ môi trường AI của bạn khi cần dựng hoặc cập nhật ngữ cảnh dự án, thay vì lao ngay vào phần triển khai.

Nên đọc các file này trước khi dùng lần đầu

Nếu muốn bắt đầu nhanh và ít phải đoán, hãy đọc:

1. plugins/conductor/skills/context-driven-development/SKILL.md
2. plugins/conductor/skills/context-driven-development/references/artifact-templates.md

SKILL.md giải thích khi nào nên dùng skill, mối quan hệ giữa các artifact và workflow bảo trì chúng. references/artifact-templates.md là phần tăng tốc thực dụng hơn: nó cho thấy hình dạng mong đợi của product.md, tech-stack.md và các file liên quan để bạn có thể cung cấp đầu vào đầy đủ cho agent nhanh hơn.

Skill context-driven-development cần những đầu vào gì

Skill này hoạt động tốt nhất khi bạn cung cấp đủ tư liệu nguồn để tạo mới hoặc cập nhật các artifact ngữ cảnh. Đầu vào tốt thường gồm:

• loại dự án: greenfield hay brownfield
• repository hiện tại hoặc cấu trúc thư mục
• mục đích sản phẩm và người dùng mục tiêu
• ràng buộc kỹ thuật và lựa chọn stack
• sở thích về workflow phát triển
• roadmap, milestone hoặc work item hiện tại
• tài liệu sẵn có như README.md, ticket, ghi chú kiến trúc hoặc code

Nếu bạn chỉ nói “set up context for my app”, đầu ra sẽ khá chung chung. Nếu bạn cung cấp bằng chứng về sản phẩm, stack, workflow và repo hiện có, các artifact sẽ dùng được ngay hơn nhiều.

Cách dùng cho greenfield: bắt đầu dự án mới

Với dự án mới, hãy dùng context-driven-development để dựng các artifact cốt lõi trước khi viết quá nhiều code. Một yêu cầu tốt nên nêu rõ:

• sản phẩm là gì
• phục vụ ai
• những tính năng nào nằm trong hoặc ngoài phạm vi
• stack dự kiến
• kỳ vọng về deploy và testing
• cách công việc nên được theo dõi

Skill này đặc biệt có giá trị ở giai đoạn này vì nó buộc bạn phải chốt những quyết định vốn rất dễ mơ hồ cho đến khi bắt tay vào triển khai.

Cách dùng cho brownfield: trích xuất ngữ cảnh từ repo hiện có

Với codebase sẵn có, hãy yêu cầu skill suy luận và sắp xếp ngữ cảnh từ repository. Hãy trỏ skill tới:

• cây thư mục mã nguồn
• các file dependency
• cấu hình CI
• README và lịch sử issue
• tài liệu hiện có
• quy ước đặt tên và các dấu hiệu về workflow

Đây là điểm mà nhiều người nhận ra giá trị rất nhanh: context-driven-development guide giúp biến một repo “chạy được nhưng khó giải thích” thành các artifact mà agent có thể tái sử dụng về sau.

Các artifact cốt lõi và vai trò của từng file

Repository này xoay quanh một vài file bền vững trong conductor/:

• product.md: bài toán, người dùng, giải pháp, tính năng, metric, roadmap
• tech-stack.md: ngôn ngữ, framework, dependency, hạ tầng, công cụ
• workflow.md: cách quá trình phát triển được kỳ vọng sẽ diễn ra
• tracks.md: đơn vị công việc, trạng thái hoặc cách tổ chức delivery đang diễn ra

Ý quan trọng ở đây là mối quan hệ giữa các file, chứ không chỉ là tạo file cho đủ. Quyết định về sản phẩm phải ăn khớp với lựa chọn stack, quy tắc workflow phải phản ánh đúng thực tế của nhóm, và phần theo dõi công việc phải bám vào roadmap cũng như ưu tiên triển khai.

Biến một mục tiêu mơ hồ thành lời gọi skill hiệu quả

Một prompt yếu:

• “Use context-driven-development for my project.”

Một prompt mạnh hơn:

• “Use context-driven-development to create initial conductor/ artifacts for a brownfield SaaS repo. Infer product scope from README.md, src/, and issue labels. Capture stack choices from package.json, Docker config, and CI. Create product.md, tech-stack.md, workflow.md, and tracks.md. Flag assumptions separately from confirmed facts.”

Vì sao cách này hiệu quả hơn:

• nó nêu rõ trạng thái của repo
• nó chỉ ra các artifact cần tạo
• nó cung cấp nguồn bằng chứng
• nó yêu cầu tách riêng giả định với dữ kiện đã được xác nhận

Workflow gợi ý khi áp dụng context-driven-development lần đầu

Một luồng context-driven-development usage thực tế:

1. Thu thập bằng chứng hiện tại từ repo và tài liệu.
2. Yêu cầu skill phác thảo các artifact cốt lõi trong conductor/.
3. Rà soát lỗi thực tế và các ràng buộc còn thiếu.
4. Gỡ các mâu thuẫn giữa tài liệu sản phẩm, stack và workflow.
5. Chỉ sau đó mới bắt đầu các tác vụ triển khai hoặc lập kế hoạch dựa trên các artifact này.
6. Chạy lại skill sau những thay đổi lớn về phạm vi, kiến trúc hoặc workflow.

Trình tự này quan trọng vì skill được thiết kế để cải thiện công việc ở các bước sau, chứ không chỉ để tạo tài liệu một lần rồi thôi.

Cách tận dụng tốt artifact templates

File references/artifact-templates.md đặc biệt hữu ích khi skill chỉ có thông tin một phần. Thay vì để agent tự bịa ra các mục còn thiếu, hãy cung cấp câu trả lời trực tiếp cho các trường trong template như:

• chân dung người dùng mục tiêu
• trạng thái tính năng
• chỉ số thành công
• lý do chọn dependency
• lựa chọn hosting
• bộ công cụ test và lint

Bạn điền được càng nhiều ràng buộc thật vào template, về sau càng ít phải dọn dẹp.

Mẹo thực tế giúp chất lượng đầu ra thay đổi rõ rệt

Để có kết quả context-driven-development usage tốt hơn:

• yêu cầu agent đánh dấu rõ phần chưa biết
• tách biệt trạng thái hiện tại với trạng thái mong muốn trong tương lai
• cho biết quyết định nào đã chốt, còn tạm thời hay vẫn chưa quyết
• cung cấp ví dụ về workflow của nhóm nếu workflow.md là phần quan trọng
• yêu cầu kiểm tra tính nhất quán trước khi chấp nhận các artifact

Một mẫu rất hữu ích là: “Draft, then validate for cross-file contradictions.” Cách này giúp bắt các lệch nhau kiểu roadmap hứa hẹn app di động trong khi stack và workflow lại cho thấy đây chỉ là MVP web.

Câu hỏi thường gặp về skill context-driven-development

Có đáng cài context-driven-development nếu tôi đã viết prompt tốt không

Thường là có, nếu bạn quay lại cùng một dự án thường xuyên. Prompt tốt giúp trong một phiên. context-driven-development skill giúp tạo ra ngữ cảnh bền vững để các prompt về sau có thể tham chiếu, thay vì phải dựng lại từ đầu.

Skill này có thân thiện với người mới không

Có, nhưng chỉ khi bạn sẵn sàng trả lời các câu hỏi cơ bản về dự án. Skill cung cấp cấu trúc, không thay bạn làm rõ bài toán kinh doanh. Người mới với mục tiêu dự án còn mơ hồ vẫn có thể nhận ra các artifact khá chung chung cho đến khi họ xác định rõ hơn người dùng, tính năng và ràng buộc.

Nó có chỉ hoạt động với Conductor không

Skill này được thiết kế cho các artifact ngữ cảnh kiểu Conductor, nên đó là môi trường phù hợp nhất. Dù vậy, phương pháp nền tảng vẫn có thể mang đi nơi khác: bộ tài liệu có cấu trúc về sản phẩm, stack, workflow và theo dõi công việc vẫn hữu ích trong các thiết lập AI-assisted khác.

Giới hạn chính của skill này là gì

Nó không thay thế chuyên môn triển khai hay việc review thiết kế hệ thống. context-driven-development mạnh nhất ở việc tổ chức ngữ cảnh dự án, làm lộ rõ mối quan hệ giữa các artifact và giữ tài liệu bám sát công việc thực tế.

Nó khác gì so với chỉ duy trì một file README

README thường hướng ra bên ngoài và bao quát ở mức rộng. Skill này đẩy bạn về phía ngữ cảnh vận hành cho phát triển: sản phẩm là gì, vì sao chọn stack như vậy, công việc di chuyển ra sao, và điều gì cần được giữ nhất quán qua các phiên làm việc với agent.

Khi nào không nên dùng context-driven-development

Đừng dùng nó cho các thử nghiệm nhỏ bỏ đi, script dùng một lần, hoặc dự án mà bạn sẽ không duy trì các artifact. Giá trị của skill nằm ở tái sử dụng và đồng bộ liên tục, không phải chỉ ở bản nháp đầu tiên.

Cách cải thiện skill context-driven-development

Hãy đưa cho skill bằng chứng, đừng chỉ đưa kỳ vọng

Bước nhảy lớn nhất về chất lượng đến từ việc neo skill vào bằng chứng thật trong repo và các quyết định đã có. Hãy đính kèm hoặc tham chiếu file thật, config thật và danh sách tính năng thực tế. Nếu bạn chỉ đưa ra mong muốn, các artifact sẽ đọc giống tài liệu lập kế hoạch chung chung hơn là ngữ cảnh làm việc thực sự.

Yêu cầu tách rõ dữ kiện đã xác nhận và giả định được suy ra

Một lỗi phổ biến là trộn lẫn dữ kiện quan sát được trong repo với những phần đoán định. Để cải thiện đầu ra của context-driven-development, hãy yêu cầu hai lớp thông tin:

• đã xác nhận từ file hoặc tài liệu
• suy ra từ mẫu lặp hoặc từ phần còn thiếu thông tin

Cách này giúp review nhanh hơn nhiều và giảm nguy cơ lệch hướng ngoài ý muốn.

Siết chặt từng artifact quanh các quyết định

Người dùng quan tâm nhất tới việc liệu các artifact có giúp ích cho các phiên code về sau hay không. Muốn vậy, hãy làm cho mỗi file xoay quanh quyết định:

• product.md: ai dùng, vấn đề gì, phạm vi, chỉ số thành công
• tech-stack.md: công cụ nào được chọn và vì sao
• workflow.md: thay đổi được đề xuất, xây dựng, kiểm thử và review như thế nào
• tracks.md: việc gì đang active, bị chặn, tiếp theo hoặc đã xong

Nếu một mục không thể giúp định hướng cho quyết định code trong tương lai, hãy cắt bớt nó.

Kiểm tra tính nhất quán trước khi tin vào đầu ra

Skill này hữu ích hơn nhiều khi bạn yêu cầu nó rà soát các mâu thuẫn như:

• phạm vi sản phẩm vượt quá roadmap
• lựa chọn stack xung đột với ràng buộc deploy
• kỳ vọng workflow không được công cụ trong repo hỗ trợ
• tracks không khớp với ưu tiên hiện tại

Bước xác thực này là một trong những thói quen có giá trị cao nhất khi dùng context-driven-development for Context Engineering.

Cải thiện prompt bằng hướng dẫn đọc repository cụ thể

Thay vì nói “analyze my repo”, hãy chỉ rõ sự thật nằm ở đâu. Ví dụ:

• “Use package.json, Dockerfile, .github/workflows/, and README.md as primary evidence.”
• “Treat issue labels and milestone names as workflow clues.”
• “Prefer explicit config over naming heuristics.”

Cách này giúp giảm các chi tiết bịa ra về stack và quy trình.

Lặp lại sau bản nháp đầu tiên, không phải trước đó

Một mẫu làm việc hiệu quả là draft -> review -> refine. Trước hết hãy yêu cầu tạo đầy đủ các artifact, sau đó mới chạy lượt thứ hai với các yêu cầu như:

• loại bỏ phần đệm chung chung
• bổ sung ràng buộc còn thiếu
• chuyển giả định thành câu hỏi
• căn chỉnh tracks theo roadmap
• cập nhật lý do chọn stack với phiên bản cụ thể nếu đã biết

Cách lặp này thường hiệu quả hơn việc cố tối ưu prompt đầu tiên đến mức hoàn hảo.

Giữ cho các artifact luôn sống cùng dự án

Quyết định context-driven-development install chỉ thật sự đáng giá nếu tài liệu được cập nhật theo thời gian. Hãy chạy lại hoặc xem lại skill khi:

• kiến trúc thay đổi
• ưu tiên thay đổi
• tooling thay đổi
• xuất hiện ma sát khi onboarding
• đầu ra từ agent bắt đầu lệch khỏi thực tế dự án

Ngữ cảnh lỗi thời thường còn tệ hơn là không có ngữ cảnh, vì nó tạo ra cảm giác tự tin sai.