run은 Claude용 AgentHub orchestration 스킬로, /hub:run을 실행해 작업을 초기화하고 agent를 생성하며 결과를 평가한 뒤 우승 결과를 merge합니다. 명확한 task, agent, eval, metric, direction, template 파라미터가 있는 측정 가능한 코드 개선 작업이나 평가 기준이 있는 창의적 비교에 적합합니다.
이 스킬의 점수는 70/100으로, 디렉터리 등록에는 무리가 없지만 이미 AgentHub 워크플로를 도입한 사용자에게 가장 적합합니다. 디렉터리 사용자는 명확한 명령 트리거, 예시, 의도된 엔드투엔드 라이프사이클 가치를 확인할 수 있습니다. 다만 저장소 근거가 `SKILL.md` 외에는 부족하며, 의존성, 설치 방법, 운영 중 발생할 수 있는 예외 상황이 충분히 문서화되어 있지는 않습니다.
- 트리거가 명확합니다. frontmatter에 `command: /hub:run`이 정의되어 있고, 설명에서도 `/hub:run` 또는 전체 AgentHub 경쟁 실행에 사용한다고 안내합니다.
- 최적화, 리팩터링, 테스트 커버리지, LLM judge 시나리오에 대한 구체적인 사용 예시를 제공합니다.
- 초기화, baseline 캡처, agent 생성, 평가, 우승 결과 merge를 하나의 agent 호출 명령으로 연결해 의미 있는 전체 라이프사이클 워크플로를 제공합니다.
- 더 넓은 AgentHub 명령 세트(`/hub:init`, baseline, spawn, eval, merge)에 의존하지만, 이 스킬 디렉터리 항목에는 `SKILL.md`만 포함되어 있으며 지원 참고 자료나 설치 안내가 없습니다.
- 파라미터 동작은 개략적으로 설명되어 있지만, 저장소 근거만으로는 예외 상황, 실패 처리, 메트릭 추출 형식, judge mode 세부 사항을 확인하기 어렵습니다.
run skill 개요
run skill이 하는 일
run은 Claude에서 /hub:run 명령을 노출하는 AgentHub 오케스트레이션 skill입니다. 하나의 요청 안에서 작업 초기화, baseline 캡처, 여러 agent 실행, 결과 평가, 우승 결과 병합까지 경쟁형 전체 라이프사이클을 수행합니다. 하나의 직접적인 답변을 받기보다 여러 해결 시도를 agentic workflow로 비교하고 싶을 때 run skill을 사용하면 좋습니다.
AgentHub 사용자에게 적합한 경우
run skill은 이미 AgentHub command pattern을 사용하고 있으며, multi-agent 실행을 위한 단일 상위 진입점을 원하는 팀에 가장 잘 맞습니다. 성능 최적화, 리팩터링, 테스트 생성, 버그 수정, 측정 가능한 코드 개선 같은 엔지니어링 작업에 적합합니다. judge mode를 사용하면 여러 후보 중 최고의 마케팅 카피를 고르는 식의 비코드 창작물 선택에도 활용할 수 있습니다.
설치 전 가장 중요한 판단 기준
/hub:init, baseline 캡처, agent 생성, 평가, 병합 단계를 수동으로 호출하지 않고 AgentHub 라이프사이클을 하나로 연결하는 반복 가능한 명령이 필요하다면 run을 설치하세요. 다만 이를 범용 자동화 실행기로 보면 안 됩니다. 이 skill의 가치는 평가하거나 판정할 수 있는 작업이 있고, 관련 명령을 사용할 수 있는 AgentHub 환경이 갖춰져 있을 때 발휘됩니다.
핵심 차별점
Claude에게 “여러 접근을 시도해 봐”라고 요청하는 일반 프롬프트와 달리, /hub:run은 task, agent 수, 선택적 eval command, metric, optimization direction, template 같은 명시적 parameter가 있는 구조화된 라이프사이클을 제공합니다. 이 구조 덕분에 결과를 비교하고, 검토하고, 병합하기가 더 쉬워집니다.
run skill 사용 방법
run 설치와 repository 확인
사용 중인 skill manager로 repository에서 skill을 설치합니다. 예를 들면 다음과 같습니다.
npx skills add alirezarezvani/claude-skills --skill run
그다음 먼저 upstream file을 확인하세요.
engineering/agenthub/skills/run/SKILL.md
이 repository path에는 핵심 동작 방식과 예시가 들어 있습니다. 제공된 tree에서는 이 skill에 딸린 scripts/, resources/, references/, rules/ 폴더가 보이지 않습니다. 따라서 도입 여부는 주로 SKILL.md의 command contract를 이해하고, 더 넓은 AgentHub command set을 사용할 수 있는지에 달려 있습니다.
기본 run 사용 패턴
명령 형식은 다음과 같습니다.
/hub:run --task "..." --agents 3 --eval "..." --metric metric_name --direction lower --template optimizer
중요한 parameter는 다음과 같습니다.
--task: 필수입니다. agent들이 경쟁할 정확한 작업입니다.--agents: 선택 사항입니다. source 예시에서는 기본값이 3입니다.--eval: 선택 사항입니다. 결과를 측정하는 데 사용할 command입니다.--metric:--eval을 사용할 때 필수입니다. 비교할 값입니다.--direction: metric을 비교할 때 필수입니다.lower또는higher를 사용합니다.--template: 선택 사항입니다. 예시로는optimizer,refactorer,test-writer,bug-fixer가 있습니다.--judge: 결정적인 metric이 없고 LLM judge가 출력물을 비교해야 할 때 유용합니다.
막연한 목표를 좋은 명령으로 바꾸기
약한 요청은 다음과 같습니다.
/hub:run --task "make it faster"
더 좋은 run 사용 프롬프트는 다음과 같습니다.
/hub:run --task "Reduce p50 latency in the product search endpoint without changing response schema" --agents 3 --eval "pytest bench.py --json" --metric p50_ms --direction lower --template optimizer
이 버전은 대상 영역을 정의하고, 지켜야 할 제약을 명시하며, agent들이 측정 가능한 benchmark를 기준으로 작업하게 하고, metric 이름과 승리 방향을 지정하기 때문에 출력 품질이 좋아집니다. coverage 작업처럼 값이 높을수록 좋은 metric을 쓸 때는 다음과 같이 작성합니다.
/hub:run --task "Add tests for untested utils without modifying production behavior" --agents 3 --eval "pytest --cov=utils --cov-report=json" --metric coverage_pct --direction higher --template test-writer
병합 전 권장 워크플로
중요한 코드에 run skill을 사용하기 전에 repository가 clean 상태인지, 테스트가 재현 가능한지, eval command가 기계가 읽을 수 있거나 일관되게 parse 가능한 출력을 반환하는지 확인하세요. 비용과 속도를 관리하려면 2~3개의 agent로 시작하는 것이 좋습니다. 코드 작업에는 가능한 한 deterministic eval을 사용하고, copywriting이나 design alternative처럼 주관적인 출력에는 --judge를 남겨 두세요. 우승 결과가 병합된 뒤에도 diff는 반드시 직접 검토해야 합니다. 이 skill은 선택 과정을 오케스트레이션하지만, 코드 소유자의 책임을 대신하지는 않습니다.
run skill FAQ
run은 Agent Orchestration용인가요, 단순 prompting용인가요?
run은 Agent Orchestration용입니다. 여러 agent를 하나의 라이프사이클로 조율하고 우승 결과를 선택하도록 설계되었습니다. 설명 하나, 리팩터링 제안 하나, 초안 하나만 필요하다면 일반 프롬프트가 더 단순합니다. 비교, 평가, 병합 절차의 엄격함이 중요할 때 run skill을 사용하세요.
run이 잘 작동하려면 무엇이 미리 있어야 하나요?
/hub:run과 관련 lifecycle command를 인식할 수 있는 AgentHub-compatible setup이 필요합니다. 측정 가능한 소프트웨어 작업이라면 신뢰할 수 있는 eval command, 명확한 metric name, 알려진 optimization direction도 필요합니다. 이것들이 없어도 judge mode로 실행할 수는 있지만, 결과의 객관성은 낮아집니다.
이 skill을 피해야 할 때는 언제인가요?
acceptance criteria가 없는 모호한 작업, rollback plan 없이 진행하는 destructive change, 테스트와 benchmark가 flaky한 프로젝트에는 run 사용을 피하세요. 또한 기본적으로 너무 많은 agent를 쓰는 것도 피하는 편이 좋습니다. 작업 정의가 약하면 agent 수를 늘려도 품질은 좋아지지 않고 비용과 검토 부담만 커질 수 있습니다.
run skill은 초보자에게도 쉬운가요?
command-style Claude skill과 기본적인 AgentHub 개념을 이미 이해하고 있다면 접근하기 어렵지 않습니다. 다만 초보자는 eval parameter, 특히 --metric과 --direction에서 어려움을 겪을 수 있습니다. 성능 개선, 리팩터링, 병합이 많은 workflow를 시도하기 전에는 위험이 낮은 창작 작업에서 judge mode로 시작하거나 간단한 test command를 사용해 보세요.
run skill 개선 방법
더 나은 작업 경계로 run 결과 개선하기
run skill은 agent들이 독립적으로 완료할 수 있을 만큼 작업 범위가 좁을 때 가장 좋은 성능을 냅니다. 대상 file, 기대 동작, 제약 조건, 변경하면 안 되는 것을 포함하세요. 예를 들어 “Refactor auth module”도 가능은 하지만, “Refactor src/auth/session.ts to reduce duplication while preserving public function signatures and existing tests”처럼 쓰면 agent들에게 더 안전한 작업 범위를 줄 수 있습니다.
eval과 metric 강화하기
코드 작업에서는 eval command가 품질을 좌우하는 가장 중요한 레버입니다. 명확히 실패하고 안정적인 metric을 생성하는 command를 선호하세요. metric에는 올바른 direction을 함께 지정해야 합니다. latency와 error count는 보통 lower를 사용하고, coverage, throughput, score는 보통 higher를 사용합니다. eval output이 모호하면 agent들이 유용한 작업을 했더라도 merge decision의 신뢰도가 떨어질 수 있습니다.
흔한 실패 패턴 살피기
흔한 실패 패턴에는 지나치게 넓은 작업 범위, 누락된 metric, flaky test suite, 측정해야 하는 작업에 judge mode를 사용하는 경우, 작업과 맞지 않는 template 선택이 있습니다. 측정 가능한 성능 개선에는 optimizer, coverage에는 test-writer, 구조를 유지하는 정리에는 refactorer, 결함 수정에는 bug-fixer를 사용하세요. 맞지 않는 template은 agent들을 잘못된 유형의 해결책으로 유도할 수 있습니다.
첫 출력 이후 반복 개선하기
첫 /hub:run 이후에는 우승 diff와 탈락한 접근들을 함께 살펴보세요. 어느 결과도 받아들일 수 없다면 같은 명령을 그대로 다시 실행하지 마세요. 작업을 더 좁히고, 제약을 추가하고, eval을 개선하거나, 범위를 줄이세요. 우승 결과가 거의 맞지만 일부가 빠져 있다면 전체 lifecycle을 다시 시작하기보다 누락된 문제에만 집중한 follow-up command를 실행하는 편이 좋습니다.