1. 작업 소개
curvez 0.4.1의 실행 과정을 아홉 절로 정리한 글이다. 에이전트 13종 · 스킬 15종 · 실행기 8종 · 훅 5종 · 프리셋 4종 · 벤더 스킬 7종으로 되어 있다.
서브에이전트 셋은 대화를 공유하지 못한다. 공통으로 알아야 할 설정과 결정을 전달하기 위해 .curvez/ 아래의 여덟 갈래에 파일을 저장한다.
2. 구현 과정과 선택 기준
실행 전에는 설정 두 가지와 승인을 마쳐야 한다. bootstrap 이 profile.json 을 만들고 architecture-setup 이 금지 import 를 확정해야 하며, 오케스트레이터는 팀 구성안을 사람에게 보이기 전까지 워커를 하나도 띄우지 않는다. 그다음 라운드 여섯이 표준형이다.
핸드오프는 JSON 한 칸도 비울 수 없다. from to status summary artifacts decisions blocked_on verification 여덟이 전부 필수고, status 는 done · partial · blocked 셋뿐이라 "거의 다 됐다"를 쓸 자리가 없다. verification 이 비면 done 을 쓸 수 없다.
품질 게이트는 arch → typecheck → lint → test → build 를 순서대로 돌리되 명령을 하드코딩하지 않고 profile.json 의 commands 에서 읽는다. 테스트가 0건이면 통과로 치지 않고 no tests found 같은 출력을 따로 잡아낸다.
3. 현재 상태와 남은 작업
벤더링 규칙이 이 글에서 굳었다. templates/CLAUDE.md 는 출처만 적고 버전을 안 적어 두었는데, 원본 1.0.0 은 절이 넷인 반면 사본은 열둘이라 5~12절은 대응이 아예 없었다. 그래서 사본마다 원본 버전 · 복사 시점 · 라이선스 세 값을 남기고, vendor/ 아래에 두며, 고치지 않기로 정했다.
실행 절차에 드는 비용도 표로 정리했다. 전제를 세우는 두 단계를 먼저 해야 시작할 수 있고, 소유 경로가 겹치면 병렬을 포기해 느려지며, 검증할 게 없는 작은 작업도 verification 을 채워야 한다. 에이전트가 하나라면 이런 추가 절차가 필요하지 않다.
확인되지 않은 것은 둘이다. /plugin install 로 실제 설치했을 때 로더가 전부 인식하는지, 그리고 실제 환경에서 멀티에이전트가 end-to-end 로 왕복하는지. 벤더 스킬 7종도 아직 라운드에 투입해 보지 않았다.