언제 쓰면 좋나
혼자서 기획→설계 리뷰→구현→QA→배포를 팀처럼 돌리고 싶을 때 맞습니다. 20개가 넘는 명령을 다 외우기보다 자주 쓰는 3~5개로 자기 흐름을 만드는 쪽이 효과적입니다. 한 줄 수정이나 이미 리뷰 체계가 있는 팀 코드, 토큰 여유가 적은 요금제에는 과합니다.
설치
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setupGit, Bun v1.4.2 이상 필요(1.3.3 미만은 설치 거부), Windows는 Node.js 추가 필요
사용 팁
- 명령을 다 외우지 마세요. 20개가 넘는 명령 중 자주 쓰는 3~5개로 자기 흐름을 만드는 편이 효과적입니다. 기획부터 배포까지라면
/office-hours(범위 정리) →/plan-eng-review(구조·테스트 확정) →/ship(테스트·푸시·PR) 순서가 출발점으로 좋습니다. - 상황별로 꺼내 쓸 명령: 버그는
/investigate(가설을 세워 추적), 큰 PR은/review, 화면 회귀는/qa(실제 브라우저 확인), 머지와 배포 확인은/land-and-deploy. - 한 번에 다 돌리는 명령은 신중하게. 여러 리뷰를 한꺼번에 도는
/autoplan은 결과가 쏟아져서, 단계별 명령을 나눠 돌리는 쪽이 품질이 좋은 경우가 많습니다. - 토큰을 많이 씁니다. 여러 단계를 도는 명령은 토큰 소모가 커서 Pro 요금제에서는 부담이 될 수 있습니다.
- 커밋을 중간에 나누세요. 자동 커밋을 켜 두면 아주 큰 커밋 하나가 생길 수 있어서, 작업 중간에 직접 커밋을 나누는 습관이 도움이 됩니다.
- 한 줄 수정이나 이미 리뷰 체계가 있는 팀 저장소에는 과할 수 있습니다.
주의할 점
보안 감사 명령(/cso)은 별도 네이티브 빌드 도구가 있어야 동작합니다. Claude Code 외 Codex·Cursor 지원은 실험 단계라 안전 장치가 권고 수준에 그칩니다.
커뮤니티 반응
CEO·엔지니어링 매니저·QA처럼 역할을 나눈 워크플로가 실제로 다른 관점의 답을 끌어내고, 브라우저로 직접 확인하는 QA가 유용하다는 반응이 있습니다. 반면 사실상 프롬프트 모음인데 개리 탄의 유명세로 별이 몰렸다는 회의론이 강하고, 텔레메트리 수집에 대한 우려와 저장소마다 다른 프로세스에 맞추기 어렵다는 지적도 나옵니다.
다른 사용자들의 공개 후기를 요약했습니다 · 2026-10-09 확인

