icpg

Tổng quan về kỹ năng icpg

Kỹ năng icpg làm gì

Kỹ năng icpg thêm một “lớp WHY” vào việc hiểu mã nguồn. Thay vì chỉ ánh xạ cấu trúc, nó liên kết các function, class và module với lý do chúng tồn tại, ai chịu trách nhiệm, và liệu chúng còn phù hợp với mục đích ban đầu hay không. Nếu bạn cần icpg cho Code Review, refactoring hoặc bảo trì tự động, giá trị cốt lõi là giảm phỏng đoán trước khi thay đổi code.

Ai phù hợp nhất

icpg phù hợp với các engineer và agent làm việc trong những codebase đang thay đổi liên tục, nơi hành vi, ownership và ý đồ thiết kế quan trọng hơn việc quét cú pháp nhanh. Nó hữu ích nhất khi repo đã bị lệch khỏi thiết kế ban đầu, lịch sử công việc không rõ ràng, hoặc thường xuyên xuất hiện câu hỏi kiểu “vì sao đoạn này lại được viết như vậy?”.

Điều gì làm nó khác biệt

Kỹ năng này tập trung vào ReasonNodes, các contract chính thức và phát hiện drift trên nhiều chiều khác nhau. Điều đó có nghĩa là icpg không chỉ là bản đồ code; nó là một lớp hỗ trợ ra quyết định cho phân tích trước khi làm việc. Lợi ích thực tế là tăng độ an toàn khi thay đổi, cung cấp ngữ cảnh review rõ hơn, và giảm số lần chỉnh sửa vô tình vi phạm ý đồ ban đầu.

Cách dùng kỹ năng icpg

Cài đặt và tìm file cốt lõi

Dùng luồng cài đặt skill của repo, rồi bắt đầu với skills/icpg/SKILL.md. Vì repository này không cung cấp script hỗ trợ hay thư mục bổ trợ nào, chính file skill là nguồn thông tin chuẩn quan trọng nhất. Để quyết định cài nhanh, hãy đọc phần frontmatter và các phần đầu tiên trước khi xem thứ khác.

Biến mục tiêu mơ hồ thành prompt dùng được

icpg usage hiệu quả nhất khi bạn cung cấp một nhiệm vụ cụ thể, đường dẫn mục tiêu và dạng đầu ra mong muốn. Ví dụ tốt là: “Review src/payments/charge.ts để tìm intent drift trước khi tôi đổi retry logic” hoặc “Bootstrap ReasonNodes cho luồng auth và xác định các ownership link còn thiếu.” Những input yếu như “phân tích repo này” quá rộng và thường bỏ lỡ thế mạnh theo dõi ý đồ của skill.

Quy trình gợi ý cho lần dùng đầu tiên

Hãy bắt đầu bằng việc hỏi mục đích dự kiến của đoạn code mục tiêu, rồi hỏi các constraint hoặc contract nào đang bảo vệ nó, sau đó hỏi drift có khả năng xảy ra ở đâu. Trình tự đó khớp với thiết kế của skill và giúp agent đi từ cấu trúc sang ý đồ rồi đến rủi ro. Với các workflow icpg guide, hãy giữ yêu cầu tập trung vào một module hoặc một change set thay vì toàn bộ repository.

Nên đọc gì trước trong repo

Hãy bắt đầu với SKILL.md, đặc biệt là phần mô tả mục đích, ví dụ CLI, và các phần nói về nguyên lý cốt lõi, canonical pre-task queries, ReasonNode và edge types. Đây là những phần có khả năng ảnh hưởng lớn nhất đến quyết định áp dụng và chất lượng đầu ra icpg cho Code Review.

Câu hỏi thường gặp về kỹ năng icpg

icpg chỉ dành cho autonomous agents thôi à?

Không. icpg hữu ích cho cả người lẫn agent, nhưng nó phát huy mạnh nhất khi hệ thống cần suy luận trước công việc một cách lặp lại và nhất quán. Nếu bạn chỉ cần một bản tóm tắt một lần, một prompt thông thường có thể đã đủ; còn nếu bạn muốn code review hoặc lập kế hoạch thay đổi có hiểu ý đồ, icpg là lựa chọn phù hợp hơn.

icpg khác gì so với một prompt code chung chung?

Một prompt chung có thể tóm tắt code, nhưng icpg được xây dựng để giữ lại ngữ cảnh về ý đồ, ownership và drift xuyên suốt nhiều nhiệm vụ. Vì vậy nó hữu ích hơn khi bạn cần trả lời “đoạn code này để làm gì?” trước khi sửa nó, chứ không chỉ “đoạn code này làm gì?”.

icpg có thân thiện với người mới không?

Có thể dùng được với người mới, nhưng kết quả tốt nhất đến từ những người có thể nêu chính xác file, feature hoặc ranh giới thay đổi. Nếu bạn mới làm quen repo, hãy bắt đầu bằng một module duy nhất và hỏi về ý đồ, constraint và rủi ro review thay vì phân tích toàn hệ thống.

Khi nào tôi không nên dùng icpg?

Bỏ qua icpg khi nhiệm vụ quá nhỏ, code bị cô lập, hoặc bạn chỉ cần một giải thích bề mặt thật nhanh. Nó cũng không phù hợp nếu bạn không thể cung cấp khu vực mục tiêu hoặc bối cảnh thay đổi nào, vì giá trị của skill phụ thuộc vào việc gắn code với một lý do tồn tại cụ thể.

Cách cải thiện kỹ năng icpg

Cung cấp ngữ cảnh nhiệm vụ mạnh hơn

Kết quả icpg tốt nhất đến từ các prompt có nêu rõ mục tiêu thay đổi, các file bị ảnh hưởng và điều gì tuyệt đối không được vỡ. Ví dụ, “review src/billing để tìm drift sau rule thuế mới” mạnh hơn nhiều so với “check billing code.” Cách này giúp skill làm nổi bật đúng ReasonNodes và các constraint cho icpg for Code Review.

Hỏi về ý đồ trước khi hỏi về triển khai

Một lỗi phổ biến là nhảy thẳng vào chỉnh sửa mà chưa hỏi đoạn code được tạo ra để bảo vệ điều gì. Hãy cải thiện đầu ra bằng cách yêu cầu trước về mục đích ban đầu, contract hiện tại và drift đang bị nghi ngờ, rồi mới hỏi kế hoạch thay đổi. Trình tự đó giúp giảm regression không đáng có và làm cho kết quả review dễ tin hơn.

Dùng câu trả lời đầu để tinh chỉnh câu sau

Nếu lượt đầu quá rộng, hãy thu hẹp theo module, bước workflow hoặc ranh giới ownership. Nếu câu trả lời quá nông, hãy hỏi thêm contract còn thiếu, chiều drift có khả năng xảy ra, hoặc canonical pre-task query phù hợp nhất với nhiệm vụ. Cách lặp này thường cải thiện tín hiệu tốt hơn việc chỉ yêu cầu một câu trả lời dài hơn.

Giữ prompt khớp với thiết kế của skill

icpg skill mạnh nhất khi bạn yêu cầu theo dõi reason, phát hiện drift và phân tích trước tác vụ, chứ không chỉ giải thích code. Nếu muốn icpg usage tốt hơn, hãy nêu rõ thế nào là “xong”, bạn đang cân nhắc loại thay đổi nào, và phần nào của codebase nằm trong phạm vi.