TL;DR

  • Hordev는 소량의 입력만으로 사양과 테스트 주도 설계(TDD)를 결정하고 작성한 뒤, 여러 방향의 실행 가능한 프로토타입을 병렬 구축하는 Claude Code 스킬 라이브러리임.
  • superpowers에서 파생됐지만 승인 게이트와 검토 체크포인트를 제거하고 속도와 폭넓은 탐색에 집중하는 방식임.
  • 실행은 추출·설계·분할·스웜·검증의 5단계로 진행되며, Haiku가 대량 작업을 수행하고 Opus가 오케스트레이션과 판단을 담당함.
  • 묻지 않은 결정은 .hordev/assumptions.md에 영향 범위와 반증 방법을 기록하고, QA를 설계 오류와 잘못된 프로토타입 사이의 핵심 검증 장치로 삼음.
  • 버전 0.2.0의 초기 단계이며 훅은 직접 실행에서 정상 작동하지만, 실제 Claude Code 세션과 충분한 프로젝트에서는 아직 검증되지 않음.

Hordev 소개

  • Hordev는 질문 대신 구축을 선택하는 Claude Code용 스킬 라이브러리임.
  • 적은 양의 입력을 바탕으로 나머지 결정을 내리고, 사양과 테스트 주도 설계를 승인 요청 없이 작성한 뒤, 저렴하고 빠른 에이전트 무리를 문제에 병렬 투입함.
  • 여러 방향의 실행 가능한 프로토타입을 동시에 빠르게 확인하는 것이 목표임.
  • superpowers의 파생 프로젝트이며, 버전 관리되는 마크다운 스킬, 구현 전 테스트, 세션 이후에도 남는 산출물이라는 원칙을 유지함.
  • 다만 작업 속도에 대해서는 다른 선택을 취함.

어떤 것을 사용해야 하는가

  • 두 라이브러리는 서로 다른 작업을 대상으로 하며, Hordev가 superpowers의 엄격한 상위 호환은 아님.
  • superpowers는 구조가 필요할 때 적합함.
  • 사양 주도 개발
  • 작업을 수행할 프레임워크
  • 잘 이해된 작업에 대한 장시간 자율 실행
  • 실제로 원하는 검토 체크포인트
  • superpowers의 강점은 이러한 구조에 있으며, Hordev는 의도적으로 그 일부를 포기함.
  • 아직 무엇을 구축할지 확실하지 않고 여러 접근법이 타당해 보이며, 가장 저렴한 학습 방법이 여러 실행 버전을 직접 확인하는 것일 때 Hordev가 적합함.
  • 핵심은 속도뿐 아니라 폭넓은 탐색임. 호드는 한 방향을 더 빠르게 수행하는 데 그치지 않고 한 번에 네 방향을 탐색하는 데 강함.
  • 이미 신뢰하는 사양을 실행하는 상황에서는 Hordev의 속도가 얻는 이익이 작고 체크포인트를 잃는 비용이 발생하므로 superpowers가 적합함.

작동 방식

  • 모든 Hordev 실행은 다음 5단계를 거침.
  • 추출(Extract) — rapid-spec, Haiku
  • 설계(Design) — writing-tdds, Haiku
  • 분할(Cut) — decomposing-for-hordes, Opus
  • 스웜(Swarm) — dispatching-hordes, reconciling-horde-output, Haiku 팬아웃 및 Opus 병합
  • 검증(Verify) — horde-qa, Opus
  • 올바른 접근법이 실제로 불확실할 때 호드는 깊이보다 폭을 선택함.
  • racing-prototypes는 동일한 예산과 사전 약정된 평가 기준 아래에서 경쟁하는 두 개에서 네 개의 버전을 동시에 구축하고, 실행 코드의 증거를 바탕으로 승자를 선택함.
  • 지원 스킬은 다음과 같음.
  • prototype-first
  • racing-prototypes
  • assumption-ledger
  • debugging-in-a-horde
  • isolating-horde-workspaces
  • improving-hordev
  • writing-hordev-skills
  • using-hordev가 진입점이며, 세션 시작 시 훅이 주입함.

Hordev를 정의하는 세 가지 결정

  • 승인 게이트 없음: Hordev는 사양이나 TDD에 대한 승인을 요청하지 않고, 스스로 결정하고 작성한 뒤 구축을 시작함.
  • 이것이 전체 속도 전략이며, 설계를 승인하는 사람이 없기 때문에 QA가 라이브러리에서 가장 중요한 스킬이 됨. 검증만이 잘못된 사양과 잘못된 프로토타입 사이에 놓인 장치임.
  • 묻지 않은 모든 질문은 기록됨.
  • 질문하지 않는 것이 정직하려면 결정이 보여야 하므로, 각 결정은 .hordev/assumptions.md에 영향 범위와 반증 방법을 포함한 항목으로 기록됨.
  • 실행이 끝나면 열려 있는 가정을 확인할 수 있음.
  • 이 기록은 인터뷰를 생략하는 것이 무모함이 아니라 방어 가능한 선택이 되도록 하는 계약임.
  • 저렴한 에이전트는 물량을 담당하고 강력한 에이전트는 판단을 담당함.
  • 사양, TDD, 구현은 Haiku에서 실행됨.
  • 오케스트레이션, 분할, 조정, QA는 Opus에서 실행됨.
  • 모든 작업에 가장 강력한 모델을 사용하면 호드의 목적이 무너짐.

스스로 개선함

  • 실행 기록은 .hordev/run-log.md에 추가됨.
  • Stop 훅은 로그가 길어졌을 때 변경할 스킬이 있는지 묻고, 반복된 실패에만 수정하는 높은 기준을 적용함.
  • 일회성 실패에는 수정하지 않고 반복된 실패에 수정함.
  • improving-hordev는 증상을 수정이 필요할 가능성이 높은 스킬로 연결함.
  • 연결부 버그는 일반적으로 분할 규칙이 지나치게 느슨하다는 의미임.
  • 에이전트가 코드 대신 계획을 반환하면 디스패치 프롬프트의 계약이 약하다는 의미임.

호드처럼 말함

  • 스킬은 간헐적으로 오크식 문구를 출력함.
  • 작업을 맡을 때 “Zug zug”을 출력함.
  • 웨이브가 디스패치될 때 “For the Horde!”를 출력함.
  • 트리가 다시 합쳐질 때 “Work complete!”를 출력함.
  • 이는 규칙이 있는 반복 농담임.
  • 대화형 출력에서만 사용함.
  • 두 메시지 연속으로 사용하지 않음.
  • 나쁜 소식 위에 사용하지 않음.
  • 사양, TDD, 커밋 메시지, QA 결과는 농담보다 오래 남으므로 깨끗한 상태로 유지함.

설치

  • Claude Code에서 다음 순서로 저장소를 플러그인 마켓플레이스로 추가하고 설치함.
  • /plugin marketplace add heffrey/hordev
  • /plugin install hordev@hordev
  • 진입점 스킬은 세션 시작 시 자동으로 로드되므로 추가 설정은 필요하지 않음.
  • 설치 후 세션을 다시 시작해야 함.
  • 필요한 것은 bash뿐임.

상태

  • 현재 초기 단계이며 버전 0.2.0임.
  • 스킬은 작성된 상태임.
  • 두 훅은 직접 실행했을 때 정상 작동함.
  • session-start.sh는 진입점을 유효한 JSON으로 출력함.
  • reflect.sh는 실행 로그가 길어지면 한 번 차단함.
  • stop_hook_active 루프 가드를 준수함.
  • 이후에는 침묵을 유지함.
  • 다만 실제 Claude Code 세션 내부에서는 아직 실행되지 않았으며, 이는 별개의 검증 대상이자 다음에 확인할 사항임.
  • 라이브러리는 자체 개선 루프가 학습할 만큼 충분한 프로젝트에서 실제로 사용되지 않음.
  • 초기에는 거친 부분이 있을 수 있으며, 실제 실행이 규칙을 반증함에 따라 규칙이 변경될 수 있음.

라이선스

  • MIT 라이선스임. LICENSE 참조 대상임.
  • Jesse Vincent의 superpowers에서 일부 파생됐으며, MIT 라이선스에 따라 사용됨.