collab-proof

collab-proof skill 개요

collab-proof의 용도

collab-proof는 AI와 함께한 코딩 세션을 실제 협업 증거로 정리해 주는 Claude skill입니다. 무엇을 결정했는지, Claude가 어떤 기여를 했는지, 왜 다른 대안은 선택하지 않았는지, 어떤 산출물이 그 과정을 입증하는지를 구조화합니다. Claude Code를 사용하는 개발자 중 의미 있는 엔지니어링 작업 이후 더 나은 세션 회고, 포트폴리오 증거, 채용용 근거 자료, 오래 남길 Knowledge Capture가 필요한 경우에 특히 잘 맞습니다.

collab-proof skill은 일반적인 요약을 만드는 대신 계층적인 워크플로를 적용합니다. 먼저 세션의 신호 강도를 감지하고, 작업 의도를 분류하며, 협업 프레임을 평가한 다음, 어떤 문서 산출물을 생성할 가치가 있는지 판단합니다.

가장 잘 맞는 사용자와 작업

다음과 같은 질문에 답해야 할 때 collab-proof를 사용하면 좋습니다.

• “여기서 Claude가 실제로 기여한 부분은 무엇인가?”
• “어떤 결정은 내가 했고, 어떤 결정은 AI가 제안했는가?”
• “과장 없이 이 작업을 포트폴리오에 보여줄 수 있는가?”
• “채팅 기록이 사라지면 어떤 추론 과정이 함께 사라지는가?”

버그 진단, 아키텍처 선택, 기능 구현, 리팩터링, 설계 트레이드오프 논의 이후에 특히 유용합니다. 반대로 아주 작은 수정, 포맷팅만 바꾼 커밋, 의존성 버전 업데이트, 별다른 추론이 없었던 세션에는 효과가 크지 않습니다.

차별점

핵심 차별점은 보정된 기여도 표기입니다. collab-proof는 단순히 “무엇이 바뀌었는지”를 요약하는 데 그치지 않고, 개발자의 의도, Claude의 제안, 채택된 아이디어, 거절된 대안, 근본 원인에 대한 추론을 분리합니다. 또한 원본 자료에는 Git notes와 SHA-256 hash를 활용해 변조 여부를 확인할 수 있는 증거를 남기는 방법도 포함되어 있습니다. 특정 커밋과 연결할 수 있는 문서화가 필요할 때 중요한 부분입니다.

Knowledge Capture 관점에서 collab-proof는 세션 안에 결정, 진단, 대안, 근거처럼 최종 diff만 봐서는 드러나지 않는 내용이 있을 때 가장 강력합니다.

collab-proof skill 사용 방법

collab-proof 설치 맥락

다음 명령으로 저장소에서 skill을 설치합니다.

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

skill 위치는 다음과 같습니다.

engineering/collab-proof/skills/collab-proof

설치 후에는 먼저 SKILL.md를 확인한 다음, 증거 모델을 설명하는 reference 파일을 읽어보세요.

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

skill 폴더에는 별도의 helper script가 없으므로, 한 번의 명령으로 리포트를 생성하는 방식이 아니라 프롬프트 중심의 워크플로를 기대하는 편이 좋습니다.

skill에 필요한 입력

collab-proof를 제대로 활용하려면 막연한 요청보다 더 많은 맥락을 제공해야 합니다. 다음 정보를 함께 줄 때 가장 잘 작동합니다.

• 현재 repository 상태
• 최근 커밋 또는 관련 diff
• 세션 목표에 대한 짧은 설명
• 중요한 대화 발췌
• 문서화하려는 버그, 기능, 결정
• 결과물이 개인용인지, PR용인지, 포트폴리오용인지, 채용 증거용인지

상위 워크플로에서는 먼저 Claude에게 git log --oneline -10과 git diff --stat HEAD~3..HEAD를 실행하게 하도록 안내합니다. 이 명령들은 세션을 high, medium, low signal로 분류하는 데 도움이 됩니다. 단일 파일 버그 수정이라도 transcript에 근본 원인 진단과 수정 근거가 포함되어 있다면 high signal이 될 수 있습니다.

효과적인 프롬프트 패턴

약한 프롬프트는 다음과 같습니다.

“Use collab-proof on this project.”

더 좋은 프롬프트는 다음과 같습니다.

“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.”

이 프롬프트가 더 잘 작동하는 이유는 skill에 해야 할 일, 범위, 결과물의 독자, 보존해야 할 의사결정 지점을 함께 알려주기 때문입니다.

권장 워크플로

세션이 끝난 직후, 추론 과정이 아직 선명할 때 좁은 범위의 회고부터 시작하세요. 최종 산출물을 작성하기 전에 Claude에게 signal level을 먼저 식별하게 하세요. 세션이 high signal이면 decision record, session history, worklog, portable proof output을 요청합니다. medium signal이면 간결한 worklog만으로 충분할 수 있습니다. low signal이면 과도하게 문서화하지 않는 편이 좋습니다.

포트폴리오나 채용 목적으로 사용할 때는 보수적인 표현을 요청하세요. 좋은 증거 문장은 “Claude identified X; I evaluated and chose Y because Z”에 가깝습니다. “AI built the project”처럼 말하지 않는 것이 좋습니다.

collab-proof skill FAQ

collab-proof는 포트폴리오용으로만 쓰나요?

아닙니다. 포트폴리오 증거는 중요한 사용 사례이지만, Knowledge Capture를 위한 collab-proof도 그만큼 중요합니다. Git 기록에서는 사라지기 쉬운 근거를 보존하는 데 도움이 됩니다. 예를 들어 버그가 왜 발생했는지, 설계가 왜 바뀌었는지, AI가 무엇을 발견했는지, 개발자가 어떤 지점에서 AI 제안을 거절하거나 덮어썼는지를 남길 수 있습니다.

일반 요약 프롬프트보다 나은 점은 무엇인가요?

일반적인 요약 프롬프트는 보통 세션을 완료한 작업 목록으로 압축합니다. collab-proof skill은 더 구조적입니다. 증거의 강도를 평가하고, 사람과 AI의 기여를 구분하며, 의사결정 근거를 우선시하고, 모든 코딩 세션을 똑같이 중요한 것으로 취급하지 않습니다. 그래서 리뷰, 회고, 작업 증명에 더 유용한 결과를 만들 수 있습니다.

초보자도 이 skill을 사용할 수 있나요?

네. 다만 처음에는 단순하게 시작하는 것이 좋습니다. 전체 포트폴리오 증거를 요청하기 전에 worklog와 contribution breakdown부터 요청하세요. 어려운 부분은 설치가 아니라 충분한 맥락을 제공하는 것, 그리고 AI가 한 일을 과장해서 주장하지 않는 것입니다.

collab-proof를 쓰지 않는 편이 나은 경우는 언제인가요?

의미 있는 추론이 없는 routine commit, 생성된 boilerplate, 외형만 다듬은 cleanup, 안전하게 요약할 수 없는 private transcript에는 collab-proof를 사용하지 않는 것이 좋습니다. 또한 실제 테스트, 코드 리뷰, 깔끔한 커밋 관리의 대체재로 사용해서도 안 됩니다. collab-proof는 협업을 문서화하는 도구이지, 코드의 정확성을 검증하는 도구가 아닙니다.

collab-proof skill 개선 방법

collab-proof 입력 개선하기

가장 흔한 실패 원인은 맥락이 부족한 입력입니다. Claude에게 세션 목표, 대화에서 중요한 부분, 영향을 받은 파일, 커밋 범위, 예상 독자를 알려주면 결과가 좋아집니다. 채용용 결과물이라면 그렇게 명시하세요. 내부 Knowledge Capture용이라면 마케팅 문구를 줄이고 기술적 세부사항을 더 많이 요청하세요.

유용한 입력 형식은 다음과 같습니다.

• Goal: 달성하려던 목표
• Change set: 커밋, 파일, 또는 diff 범위
• Reasoning: 검토했지만 거절한 대안
• Attribution: 내가 제안한 것, Claude가 제안한 것, 변경된 것
• Audience: 개인 메모, PR, README, recruiter, portfolio

기여도 표기와 증거 품질 조정하기

중요한 결정마다 보정된 기여도 표기를 요청하세요. 좋은 collab-proof 결과물은 양극단을 모두 피해야 합니다. 개발자가 전부 한 것처럼 보이게 해서도 안 되고, Claude가 독립적으로 해결책을 만들었다고 주장해서도 안 됩니다. “Claude suggested,” “developer selected,” “developer rejected,” “jointly refined,” “root cause identified from” 같은 증거 표현을 요청하세요.

버그 수정의 경우 원인, 진단 경로, 수정 근거를 명시적으로 캡처해 달라고 하세요. repository의 BUG_FIXING rule은 잘 설명된 단일 파일 수정도 가치 높은 증거로 다룹니다.

첫 결과물 이후 반복 개선하기

처음 생성된 proof를 그대로 받아들이지 마세요. 과장된 주장, 빠진 대안, 불분명한 소유권, 검증할 수 없는 문장이 있는지 검토해야 합니다. 그런 다음 두 번째 패스를 요청하세요.

“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.”

이렇게 하면 처음부터 완성도 높은 산출물을 요청하는 것보다 보통 더 신뢰할 수 있는 문서가 나옵니다.

필요할 때 변조 확인 가능한 증거 추가하기

증거를 외부에 공유할 수 있다면 references/tamper-evident-proof.md에 설명된 Git notes workflow를 검토하세요. 핵심 아이디어는 생성된 HTML proof file의 hash를 만들고, git notes로 해당 hash를 관련 commit에 붙이는 것입니다. 이것이 내용의 진실성을 자동으로 보장해 주지는 않지만, 특정 proof artifact가 특정 code state에 존재했다는 점을 보여주는 데 도움이 됩니다.