collab-proof

Tổng quan về collab-proof skill

collab-proof dùng để làm gì

collab-proof là một Claude skill giúp biến phiên lập trình có AI hỗ trợ thành bằng chứng cộng tác có thể sử dụng được: bạn đã quyết định điều gì, Claude đã đóng góp gì, vì sao các phương án khác bị loại, và những artifact nào chứng minh điều đó. Skill này phù hợp nhất với lập trình viên dùng Claude Code muốn có bản nhìn lại phiên làm việc tốt hơn, bằng chứng cho portfolio, tư liệu phục vụ tuyển dụng, hoặc Knowledge Capture bền vững sau những công việc kỹ thuật có ý nghĩa.

Thay vì tạo một bản tóm tắt chung chung, collab-proof skill áp dụng workflow nhiều lớp: nhận diện độ mạnh của tín hiệu trong phiên làm việc, phân loại mục đích công việc, chấm điểm khung cộng tác, rồi quyết định những artifact tài liệu nào đáng được tạo.

Người dùng và công việc phù hợp nhất

Dùng collab-proof khi bạn cần trả lời các câu hỏi như:

• “Claude thật sự đã đóng góp gì ở đây?”
• “Quyết định nào là của tôi, quyết định nào do AI gợi ý?”
• “Tôi có thể đưa phần việc này vào portfolio mà không phóng đại không?”
• “Nếu transcript cuộc trò chuyện biến mất, phần lập luận nào sẽ bị mất theo?”

Skill này đặc biệt hữu ích sau các phiên chẩn đoán lỗi, lựa chọn kiến trúc, triển khai tính năng, refactor, và thảo luận về đánh đổi trong thiết kế. Skill kém hữu ích hơn với các chỉnh sửa rất nhỏ, commit chỉ định dạng lại, nâng version dependency, hoặc những phiên gần như không có lập luận đáng ghi lại.

Điểm khác biệt của collab-proof

Điểm khác biệt chính là khả năng quy attribution một cách có kiểm soát. collab-proof không chỉ tóm tắt “đã thay đổi gì”; nó tách riêng ý định của lập trình viên, gợi ý của Claude, ý tưởng được chấp nhận, phương án bị từ chối, và lập luận về nguyên nhân gốc. Tài liệu nguồn cũng có hướng dẫn tạo bằng chứng khó bị chỉnh sửa âm thầm bằng Git notes và SHA-256 hashes, điều này quan trọng nếu bạn muốn tài liệu có thể gắn với một commit cụ thể.

Với Knowledge Capture, collab-proof phát huy mạnh nhất khi phiên làm việc chứa quyết định, chẩn đoán, phương án thay thế, hoặc lý do mà nhìn vào diff cuối cùng sẽ không thấy rõ.

Cách sử dụng collab-proof skill

Bối cảnh cài đặt collab-proof

Cài skill từ repository bằng lệnh:

npx skills add alirezarezvani/claude-skills --skill collab-proof

Skill nằm tại:

engineering/collab-proof/skills/collab-proof

Sau khi cài đặt, hãy xem SKILL.md trước, rồi đọc các file tham chiếu giải thích mô hình bằng chứng:

• references/ai-collaboration-evidence.md
• references/developer-portfolio-proof.md
• references/session-documentation-patterns.md
• references/tamper-evident-proof.md

Không có helper script trong thư mục skill, vì vậy hãy kỳ vọng đây là workflow chạy bằng prompt, không phải một trình tạo báo cáo chỉ cần một lệnh.

Những input collab-proof cần

Để dùng collab-proof hiệu quả, đừng chỉ đưa một yêu cầu mơ hồ. Skill hoạt động tốt nhất khi có:

• Trạng thái hiện tại của repository
• Các commit gần đây hoặc diff liên quan
• Mô tả ngắn về mục tiêu của phiên làm việc
• Những đoạn hội thoại quan trọng
• Lỗi, tính năng, hoặc quyết định cần được ghi lại
• Đầu ra dùng cho chính bạn, PR, portfolio, hay bằng chứng tuyển dụng

Workflow upstream yêu cầu Claude chạy git log --oneline -10 và git diff --stat HEAD~3..HEAD trước. Các lệnh này giúp phân loại phiên làm việc thành tín hiệu cao, trung bình, hoặc thấp. Một bản sửa lỗi chỉ trong một file vẫn có thể là tín hiệu cao nếu transcript có chẩn đoán nguyên nhân gốc và lý do chọn cách sửa.

Mẫu prompt hiệu quả

Một prompt yếu là:

“Use collab-proof on this project.”

Một prompt tốt hơn là:

“Use collab-proof for the last session. The goal was to fix the login redirect bug. Please inspect recent commits and diff stats, classify the collaboration signal, identify root cause reasoning, separate my decisions from Claude’s suggestions, and produce portfolio-safe evidence. Emphasize why the chosen fix was better than the rejected middleware approach.”

Prompt này hiệu quả hơn vì nó cung cấp cho skill một nhiệm vụ, phạm vi, đối tượng đọc đầu ra, và các điểm quyết định cần được giữ lại.

Workflow được đề xuất cho collab-proof

Hãy bắt đầu bằng một bản retrospective hẹp ngay sau phiên làm việc, khi phần lập luận vẫn còn mới. Yêu cầu Claude xác định mức tín hiệu trước khi viết artifact cuối cùng. Nếu phiên làm việc có tín hiệu cao, hãy yêu cầu decision records, session history, worklog, và đầu ra bằng chứng có thể mang đi dùng lại. Nếu tín hiệu trung bình, một worklog ngắn gọn có thể đã đủ. Nếu tín hiệu thấp, tránh ghi chép quá mức.

Với mục đích portfolio hoặc tuyển dụng, hãy yêu cầu cách viết thận trọng. Bằng chứng tốt nên nói “Claude identified X; I evaluated and chose Y because Z,” chứ không phải “AI built the project.”

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

collab-proof chỉ dành cho portfolio thôi sao?

Không. Bằng chứng cho portfolio là một use case lớn, nhưng collab-proof cho Knowledge Capture cũng quan trọng không kém. Skill giúp lưu lại phần lý do thường biến mất khỏi lịch sử Git: vì sao lỗi xảy ra, vì sao thiết kế thay đổi, AI đã nhận ra điều gì, và chỗ nào lập trình viên đã không làm theo AI.

collab-proof tốt hơn prompt tóm tắt thông thường như thế nào?

Một prompt tóm tắt thông thường thường nén cả phiên làm việc thành các nhiệm vụ đã hoàn thành. collab-proof skill có cấu trúc rõ hơn: nó chấm độ mạnh của bằng chứng, phân biệt đóng góp của con người và AI, ưu tiên lý do phía sau quyết định, và không xem mọi phiên coding là quan trọng như nhau. Nhờ vậy, đầu ra hữu ích hơn cho review, retrospective, và proof of work.

Người mới có dùng được skill này không?

Có, nhưng người mới nên giữ lần chạy đầu tiên thật đơn giản. Hãy yêu cầu worklog và phần phân tách đóng góp trước khi yêu cầu đầy đủ bằng chứng cho portfolio. Phần khó không nằm ở cài đặt; khó hơn là cung cấp đủ ngữ cảnh và tránh phóng đại những gì AI đã làm.

Khi nào không nên dùng collab-proof?

Không nên dùng collab-proof cho các commit thường lệ không có lập luận đáng kể, boilerplate được sinh tự động, dọn dẹp giao diện/cosmetic, hoặc transcript riêng tư mà bạn không thể tóm tắt an toàn. Cũng không nên dùng nó thay cho test thật, code review, hoặc thói quen commit sạch. Skill này ghi lại quá trình cộng tác; nó không xác thực tính đúng đắn của mã.

Cách cải thiện collab-proof skill

Cải thiện input cho collab-proof

Lỗi thường gặp nhất là ngữ cảnh quá mỏng. Hãy cải thiện kết quả bằng cách cung cấp cho Claude mục tiêu phiên làm việc, các đoạn hội thoại quan trọng, file bị ảnh hưởng, khoảng commit, và người đọc dự kiến. Nếu đầu ra dùng cho tuyển dụng, hãy nói rõ. Nếu dùng cho Knowledge Capture nội bộ, hãy yêu cầu nhiều chi tiết kỹ thuật hơn và bớt màu sắc marketing.

Định dạng input hữu ích:

• Goal: bạn đang cố đạt điều gì
• Change set: commit, file, hoặc khoảng diff
• Reasoning: các phương án đã cân nhắc và loại bỏ
• Attribution: bạn đề xuất gì, Claude đề xuất gì, điều gì đã thay đổi
• Audience: ghi chú riêng, PR, README, recruiter, portfolio

Tinh chỉnh attribution và chất lượng bằng chứng collab-proof

Hãy yêu cầu attribution có kiểm soát cho mọi quyết định quan trọng. Đầu ra collab-proof tốt nên tránh cả hai cực đoan: làm như lập trình viên tự làm mọi thứ, hoặc tuyên bố Claude tự mình xây dựng giải pháp. Hãy yêu cầu các cụm bằng chứng như “Claude suggested,” “developer selected,” “developer rejected,” “jointly refined,” và “root cause identified from.”

Với bug fix, hãy yêu cầu skill ghi lại rõ nguyên nhân, đường đi chẩn đoán, và lý do chọn cách sửa. Quy tắc BUG_FIXING của repository xem một bản sửa trong một file nhưng được giải thích tốt là bằng chứng có giá trị cao.

Lặp lại sau đầu ra đầu tiên

Đừng chấp nhận bản proof đầu tiên một cách mù quáng. Hãy rà soát xem có chỗ nào phóng đại, thiếu phương án thay thế, quyền sở hữu chưa rõ, hoặc phát biểu không kiểm chứng được không. Sau đó yêu cầu lượt chỉnh sửa thứ hai:

“Revise this collab-proof output to be more conservative. Remove claims not supported by the diff or transcript. Add a short ‘developer-owned decisions’ section and a ‘Claude-assisted insights’ section.”

Cách này thường tạo ra tài liệu đáng tin hơn so với việc yêu cầu ngay một artifact trau chuốt từ đầu.

Thêm bằng chứng khó bị chỉnh sửa âm thầm khi cần

Nếu bằng chứng có thể được chia sẻ ra bên ngoài, hãy cân nhắc workflow Git notes được mô tả trong references/tamper-evident-proof.md. Ý tưởng là hash file HTML proof đã tạo và gắn hash đó vào commit liên quan bằng git notes. Việc này không tự động biến nội dung thành sự thật, nhưng giúp cho thấy một artifact bằng chứng cụ thể đã tồn tại tại một trạng thái code cụ thể.