기능을 구현하다 막혔을 때, 먼저 풀어야 할 문제가 하나 더 있었습니다. 지금 필요한 게 요구사항을 좁히는 질문인지, 테스트를 설계하는 절차인지에 따라 여러 스킬 모음에서 비슷한 지침을 찾아 비교해야 했습니다. COCO는 이 탐색을 줄이기 위해 개발자가 하려는 일을 기준으로 스킬을 다시 묶는 작업에서 출발했습니다. 이름은 얼쑤 기술 블로그 첫 글에 등장한 팀원의 반려견 코코에서 따왔습니다. 얼쑤 기술 블로그 첫 글

스킬을 작업별로 묶다

Matt Pocock, Addy Osmani, Lauren Tan의 스킬 모음에서 출발했습니다. 각각을 통째로 설치하는 대신, 개발자가 하려는 일에서 출발하도록 묶었습니다. 요구사항을 좁힐 때는 coco-clarify, 구현할 때는 coco-build, 검증할 때는 coco-verify를 찾는 식입니다. 같은 작업에 도움이 되는 기법을 한곳에서 찾을 수 있게 했습니다.

한 이름 아래 묶으면 어떤 절차를 어디에서 가져왔는지 흐려지기 쉽습니다. 원본 스킬과 COCO에서의 쓰임을 대응표에 남긴 이유입니다. 예를 들어 테스트 주도 개발 지침은 검증 스킬의 근거 중 하나로 연결했습니다. 대응표에는 실제 스킬에 반영한 항목과 참고 자료로 둔 항목도 구분했습니다. COCO 원본 대응표

공개 패키지의 무결성 확인

배포 준비 단계인 0.0.0-stage에는 README와 패키지 정보만 들어 있었습니다. 스킬 26개를 처음 담은 공개 패키지는 0.1.0입니다. 배포 직전에 만든 압축 파일을 임시 디렉터리에 설치해 스킬 수를 확인했고, 공개 뒤에는 npm에서 돌려준 무결성 값이 그 파일과 일치하는지도 대조했습니다. 당시 격리 환경에서 npm을 통해 새로 내려받는 시도는 네트워크 제약에 걸려, 설치 검증에는 무결성 값이 일치한 로컬 파일을 사용했습니다. 0.1.0 배포 검증

0.1.1에서는 빠른 설치와 처음 호출할 스킬 예시를 README에 추가했습니다. 두 공개 패키지의 파일을 대조하면 0.1.0과 비교해 달라진 파일은 README와 버전 번호가 들어 있는 패키지 정보 두 개입니다. 0.1.2에서는 Claude Code 설치를 지원하고, 같은 패키지로 Codex와 Claude Code 양쪽의 설치·재설치를 확인했습니다. npm 버전 기록 · 0.1.2 배포 안내

스킬을 설치하고 나면 팀마다 다른 규칙을 어디에 둘지 결정해야 합니다. 다음 글에서는 Team Edo가 Jira, Git, 사람의 검토를 COCO 흐름과 어떻게 연결했는지 살펴봅니다.