spawn

spawn skill 개요

spawn이 하는 일

spawn은 같은 세션 작업을 대상으로 여러 코딩 에이전트를 병렬로 실행하는 AgentHub skill입니다. 하나의 assistant가 문제를 순차적으로 풀도록 맡기는 대신, spawn skill은 격리된 git worktree 안에 N개의 subagent를 만들어 서로의 변경 사항을 덮어쓰지 않으면서 각기 다른 전략으로 경쟁하게 합니다.

이미 초기화된 AgentHub session이 있고, 구현, 리팩터링, 테스트, 최적화, 버그 수정 작업에서 병렬 탐색이 필요할 때 사용하면 좋습니다.

Agent Orchestration에 가장 잘 맞는 경우

spawn for Agent Orchestration은 하나 이상의 그럴듯한 해결 경로가 있는 작업에서 특히 유용합니다. 여러 agent가 대안을 탐색하고 결과물을 비교하며, 첫 번째 구현에 과도하게 고정되는 위험을 줄이고 싶은 팀이나 개인 개발자에게 잘 맞습니다.

성능 튜닝, 대규모 리팩터링, 간헐적으로 발생하는 버그 조사, 부족한 테스트 커버리지 보완, 독립적인 접근 방식이 트레이드오프를 드러낼 수 있는 코드 변경이 좋은 후보입니다.

이 spawn skill이 다른 점

핵심 차별점은 격리와 구조화된 경쟁입니다. 각 agent는 자기만의 git worktree에서 작업하므로 병렬 편집이 서로 분리되고, 이후 비교도 더 안전해집니다. 또한 이 skill은 optimizer, refactorer, test-writer, bug-fixer 같은 template을 지원하므로, 범용적인 “이 문제를 해결해” 식 지시가 아니라 엔지니어링 작업 유형에 맞는 dispatch prompt를 사용할 수 있습니다.

도입 전 고려할 점

이 skill은 이미 주변 AgentHub workflow를 사용하고 있다는 전제를 둡니다. 아무 repository에서나 별도 설정 없이 바로 실행되는 standalone package가 아닙니다. repository 경로에는 SKILL.md만 있으므로, 사용자는 이 skill 정의가 session configuration과 skill 폴더 밖의 template 파일을 포함한 인접 AgentHub convention 및 reference에 의존한다고 예상해야 합니다.

spawn skill 사용 방법

spawn 설치 맥락

다음 명령으로 source repository에서 skill을 설치합니다.

npx skills add alirezarezvani/claude-skills --skill spawn

설치 후에는 환경이 AgentHub command를 지원하는지, session이 이미 초기화되어 있는지 확인하세요. 이 skill이 노출하는 command는 다음과 같습니다.

/hub:spawn

spawn 설치 여부는 단순히 또 하나의 prompt shortcut이 필요한지가 아니라, 조율된 병렬 agent가 필요한지에 따라 판단해야 합니다. workflow에서 git worktree나 session 기반 orchestration을 사용하지 않는다면, 이 skill에 의존하기 전에 더 넓은 AgentHub setup을 먼저 검토하세요.

기본 spawn 사용법

자주 쓰는 command 형식은 다음과 같습니다.

/hub:spawn
/hub:spawn 20260317-143022
/hub:spawn --template optimizer
/hub:spawn --template refactorer

최신 session에는 /hub:spawn을 사용합니다. 특정 AgentHub session을 대상으로 해야 할 때는 session ID를 전달하세요. 작업이 특화된 운영 패턴의 이점을 얻을 수 있다면 --template <name>을 추가합니다.

이 skill이 지원하는 template 의도는 다음과 같습니다.

• optimizer: edit/evaluate/keep-or-discard cycle을 반복
• refactorer: 구조를 바꾸고, 테스트하고, green 상태가 될 때까지 반복
• test-writer: 테스트를 추가하고 coverage improvement를 측정
• bug-fixer: 재현, 진단, 수정, 검증

agent 결과를 개선하는 입력

좋은 spawn 사용 prompt는 command를 입력하기 전부터 시작됩니다. session task는 여러 agent가 독립적으로 실행하고 결과를 비교할 수 있을 만큼 구체적이어야 합니다. 대상 파일, acceptance criteria, test command, 제약 조건, 그리고 무엇을 “더 낫다”고 볼지 포함하세요.

약한 session goal:

Improve the API code.

더 강한 session goal:

Refactor the user lookup API to reduce duplicate database calls without changing response shape.
Focus on src/api/users.ts and src/services/user-cache.ts.
Run npm test -- users and npm run lint.
Preserve public types. Prefer minimal changes unless an agent can prove a cleaner design with tests.

이렇게 하면 spawned agent들이 공유할 목표를 갖되, 서로 다른 전략을 시도할 여지도 남길 수 있습니다.

실행 전에 읽어야 할 파일

engineering/agenthub/skills/spawn의 SKILL.md부터 확인하세요. 그런 다음 skill이 참조하는 인접 AgentHub 자료를 살펴보되, 설치된 repository에 있다면 session setup docs와 agent-templates.md를 특히 확인하세요. 반드시 검증해야 할 핵심 사항은 session naming 방식, N개의 agent 선택 방식, worktree 생성 위치, 최종 비교 또는 merge selection 처리 방식입니다.

spawn skill FAQ

일반 prompt 대신 spawn은 언제 써야 하나요?

병렬 탐색이 실제로 가치가 있을 때 spawn을 사용하세요. 작은 수정, 문서 변경, 정답이 분명한 작업에는 일반 prompt로도 대개 충분합니다. spawn skill은 서로 다른 구현 전략, 테스트 설계, 디버깅 가설이 의미 있게 다른 결과로 이어질 수 있을 때 더 적합합니다.

spawn은 초보자에게도 쉬운가요?

주변 AgentHub workflow와 기본적인 git worktree 동작을 이미 이해하고 있다면 초보자도 사용할 수 있습니다. command 자체는 단순하지만 운영 모델은 더 고급입니다. 여러 agent가 별도의 변경 사항을 만들고, 이를 검토하고 테스트한 뒤 선택해야 합니다.

성공적인 spawn 사용을 막는 요인은 무엇인가요?

주요 장애 요인은 초기화되지 않은 AgentHub session, 불명확한 task definition, 누락된 test command, parallel worktree 변경에 안전하지 않은 repository입니다. 또 하나의 제약은 skill 폴더가 최소 구성이라는 점입니다. 유용한 orchestration context는 더 넓은 AgentHub system 안에 있으므로, 이를 완전히 self-contained tool처럼 평가해서는 안 됩니다.

spawn을 쓰지 않는 편이 나은 경우는 언제인가요?

secrets handling, 되돌릴 수 없는 production operation, 아주 작은 한 줄 수정, agent의 중복 작업이 통찰보다 소음을 더 많이 만드는 작업에는 spawn을 피하세요. 테스트를 실행하거나 결과물을 비교할 수 없는 상황에도 잘 맞지 않습니다. 병렬 agent의 가치는 근거 기반 선택에 달려 있기 때문입니다.

spawn skill 개선 방법

spawn prompt를 더 비교 가능하게 만들기

spawn에서 더 나은 결과를 얻으려면 모든 agent가 최적화 기준으로 삼을 수 있는 success metric을 정의하세요. 좋은 비교 기준에는 passing tests, reduced runtime, smaller diff size, clearer API boundaries, improved coverage, reproduced bug evidence가 포함됩니다. 공통 기준이 없으면 병렬 결과물을 판단하기 어려워집니다.

의도적으로 다양한 전략 배정하기

이 skill의 template guidance는 각 agent가 서로 다른 전략을 받을 때 가장 강력합니다. 버그 수정이라면 한 agent는 재현에서, 다른 agent는 최근 git history에서, 또 다른 agent는 boundary-condition test에서 출발할 수 있습니다. 최적화라면 한 agent는 allocation을 줄이고, 다른 agent는 cache를 적용하며, 또 다른 agent는 algorithmic complexity를 바꿀 수 있습니다. 다양성이 바로 spawn skill의 핵심입니다.

흔한 실패 패턴 피하기

흔한 실패에는 모호한 목표로 agent를 spawn하는 것, 모든 agent가 같은 계획을 따르게 두는 것, 검증을 건너뛰는 것, 가장 커 보이는 solution을 가장 근거가 탄탄한 solution 대신 merge하는 것이 있습니다. 작업 범위를 제한하고, test command를 요구하며, agent에게 접근 방식, tradeoff, 변경한 파일, verification result를 요약하게 하세요.

첫 spawn 실행 후 반복하기

첫 실행 후에는 merge하기 전에 worktree를 비교하세요. 가장 강한 candidate를 유지하고, 약한 branch는 버리거나, 배운 내용을 바탕으로 두 번째 spawn round를 실행할 수 있습니다. 유용한 follow-up instruction은 다음과 같습니다.

Use the best result from agent 2 as the baseline.
Spawn new agents to improve reliability and reduce diff size.
All agents must preserve the public API and run the same test command.

이렇게 하면 spawn을 일회성 경쟁이 아니라 실용적인 agent orchestration loop로 바꿀 수 있습니다.