메뉴
자율 실행 오케스트레이터. /team 편성표를 소비하여 TaskCreate + Agent 디스패치로 작업을 자율 완주한다. "/go", "실행해", "만들어줘" 등 구현 요청 시 사용.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | go |
| description | 자율 실행 오케스트레이터. /team 편성표를 소비하여 TaskCreate + Agent 디스패치로 작업을 자율 완주한다. "/go", "실행해", "만들어줘" 등 구현 요청 시 사용. |
대화 컨텍스트(discussion, PRD, /team 편성표)를 바탕으로 task를 만들고 에이전트를 디스패치하여 자율 완주한다. 메인은 직접 코드를 쓰지 않고 오케스트레이션한다.
메인의 역할: 판단 + 디스패치 + 검증
에이전트의 역할: 실행 + mini-verify
대화에 이미 discussion/PRD/요청이 있으면 바로 상황 판단으로 넘어간다. 컨텍스트가 없으면(새 세션에서 "/go"만 입력) 아래 순서로 탐색한다:
type=prd 중 역PRD 열이 비어있는 PRD (project 또는 layer 필드로 범위 지정)
created 날짜 순서대로 처리type=handoff, status!=consumed (가장 최근 1개 + 내부 "이후" 섹션의 backlog 링크)git status에 작업 중인 변경판단: [규모] — Phase: [선택된 phase 나열]
| 신호 | Phase 선택 |
|---|---|
| 새 파일 3개+ 또는 새 모듈/아키텍처 | Plan → Cast → Execute → Verify |
| 기존 파일 수정, 범위 명확 | Cast → Execute → Verify |
| discussion/PRD에서 이미 plan 수준 상세도 | Cast → Execute → Verify |
| PRD 없는 단순 요청 | Cast → Execute → Verify |
| 파일 1~2개, 긴장 없음 | Execute (메인 실행 + 평가 에이전트) → Verify |
| 버그 수정, 디버깅 | Debug → Verify |
복잡한 작업일 때만 실행. superpowers:writing-plans 스킬을 호출한다.
/team 스킬로 팀 편성표를 산출한다. /team이 산출하는 것:
대화에 이미 편성표가 있으면 그대로 사용한다.
/team 편성표의 배치를 TaskCreate로 변환한다:
배치 B1 → TaskCreate("B1: [설명]")
배치 B2 → TaskCreate("B2: [설명]")
task를 Agent tool로 디스패치한다.
독립 배치들을 하나의 메시지에서 동시에 Agent tool을 호출한다:
Agent(B1 프롬프트, worktree) ← 동시
Agent(B2 프롬프트, worktree) ← 동시
의존 관계가 있는 배치는 이전 배치 완료 후 디스패치한다.
pnpm typecheck 실행하여 에러 0 확인. 에러가 있으면 수정 후 결과 보고."isolation: "worktree" 사용에이전트가 돌아오면:
여러 worktree의 변경을 메인에 병합한다:
실행 에이전트 완료 후, 별도 평가 에이전트를 디스패치하여 결과를 채점한다. 평가→수정을 최대 5라운드 반복한다.
round = 0
while round < 5:
평가 에이전트 디스패치(PRD/task.md + git diff)
if 합격:
break
실행 에이전트에 불합격 피드백 전달 → 재실행
round += 1
PRD 없는 작업은 Execute 시작 전에 docs/YYYY/YYYY-MM/YYYY-MM-DD/{name}Task.md (frontmatter: type: plan, project 또는 layer)를 작성한다.
PRD가 있는 사이클에서 에이전트에게 양방향 추적 주석을 지시한다:
// ② PRD파일명// V{n}: PRD파일명버그/디버깅 작업일 때. superpowers:systematic-debugging 또는 reproduce-first-debugging 호출.
항상 실행. 에이전트가 mini-verify(typecheck)를 통과했으므로, 메인은 full verify를 수행한다.
pnpm typecheck — TypeScript 에러 0eslint — lint 에러 0vitest run — 테스트 전체 통과pnpm check:deps — 레이어 의존 위반 0하나라도 실패하면 → 수정 후 재검증
/handoff(나가는 길)로 진행한다/handoff가 commit, push, 남은 것 backlog화, handoff 문서 생성을 한 번에 처리한다. retro 산출물이 있으면 PROGRESS.md/ARCHITECTURE.md 갱신도 포함/retrospect 스킬을 호출한다:
Verify + Retrospect(해당 시) 모두 통과하면 완료.
Refactor frontend source trees so layer/slice/segment(role) hierarchy stays clear. Treat FSD names such as shared/entities/features/widgets/app as examples, not as the required target. Use when the user asks to reorganize src, separate app-owned code from reusable packages, remove layer smells, or clarify 책임 경계.
요청이 모호하거나 '왜 하는지'부터 정리가 필요할 때 사용. /discuss, $discuss, 숨은 의도 정렬, 전략 선택, 실행 전 확인 요청, 프로젝트 작업과 개인 도구 작업의 범위 분리가 필요할 때 사용한다. TOC 13요소와 FRT 게이트로 이해도를 순서대로 올린 뒤 goal로 실행 가능한 액션 플랜을 만든다. 질문만 던지는 소크라틱 대화가 아니라, AI가 먼저 범위 안 맥락을 조사하고 추론한 뒤 판단과 근거를 밝히고 필요한 갭 질문만 얹는다.
Use when the user invokes /doubt or $doubt, asks Codex to deliberately reduce unnecessary complexity before introducing a new concept, component, flag, type, file, branch, workflow, document, or procedure, or requests cleanup/review after implementation. Triggers include "이거 다 필요해?", "정리 좀 해줘", "새로 만들어야 할까?", "불필요한 거 없나?", "코드 줄여줘", "why do we need this?", or any review where existence, fit, volume, and efficiency should be challenged before adding or keeping structure.
Use when refactoring frontend entity folders, FSD feature/entity boundaries, exported type names, prefix alignment, or cohesive entity/viewModel/value-object props so files and UI interfaces are grouped by real domain or UI concepts instead of role labels, generic names, or shredded field props. Trigger on requests such as entities 응집도, 접두어 정렬, 인터페이스 중심 폴더링, FSD 위치 점검, feature/entity 경계 리팩토링, props drill, entity shredding, viewModel props, 엔티티를 그대로 넘기기.
파일이나 기능의 개방-폐쇄 원칙(OCP)을 점검하고 리팩토링한다. "OCP", "/ocp", "개방 폐쇄", "switch 너무 많다", "if 분기 정리", "분기 흩어짐", "선언적 맵", "registry", "descriptor", "새 타입/variant 추가마다 여러 곳 수정" 같은 요청에서 사용한다. 열린 집합의 분기가 여러 소비자에 산재해 동반 변경 지점이 2곳 이상인지 분석하고, 확장 시 기존 코드 수정 지점을 0~1곳으로 줄이는 구조를 설계·전환한다.
사용자 발화를 액면 그대로 수행하지 않고 숨은 조사 의도, 배경, 목표를 먼저 추론한 뒤 비교 대상의 범주와 피어셋을 잠그고, 내부 맥락을 감사하고 standard, best practice, de facto, frontier trend를 비교해 읽히는 reference narrative를 만든다. "reference", "레퍼런스", "BP 찾아줘", "best practice", "사실상 표준", "de facto", "요즘 트렌드", "최근 시도", "업계는 어떻게 해", "표준 뭐야", "research", "리서치", "/reference", "/research"처럼 외부 수렴 흐름을 알고 싶을 때 사용한다. 단순 링크 목록이나 표 보고서가 아니라, 소스를 대신 읽고 같은 범주의 BP/de facto와 얼마나 가까운지, 결이 얼마나 비슷한지, 차이가 있다면 더 가까운 유사 레퍼런스는 무엇인지 문단 중심으로 설명하고 필요한 근거 표는 appendix로 내린다.