tstack: 코딩 에이전트가 변경 증명부터 리뷰 봇 대응, PR 병합까지 맡게 하는 스킬 9종 (feat. Theo Browne)

9bow · 10월 29, 2026, 9:00오전

핵심 요약

tstack은 Theo Browne이 매일 쓰는 에이전트 스킬 9개를 정리해 공개한 저장소로, Claude Code와 Codex에서 동작합니다. 스킬은 주로 코드를 쓴 뒤의 단계, 곧 변경 증명, 리뷰, PR 작성, CI와 리뷰 봇 대응, 병합을 다룹니다.
중심 스킬인 full-send는 사용자가 지켜보지 않는다는 전제로 일합니다. 변경을 증명하고, GPT Sol 리뷰 루프(sol-loop)를 거쳐 PR을 올리고, CI와 리뷰 봇을 지켜보며 병합까지 진행합니다. full-stop은 같은 과정을 밟되 병합 직전에 멈춥니다.
두 스킬은 호출되는 순간 작업 브랜치 강제 푸시(--force-with-lease)와 테스트 방법의 사전 확인 생략을 허락받은 것으로 간주하고, full-send는 병합 권한까지 받습니다. 프로젝트 파일에 "테스트 전에 먼저 물어보라"는 규칙이 있어도 이 요청이 그 규칙을 대신합니다.
tstack이 안내하는 설치 방법은 skills/ 폴더 복사뿐이고, 자동 업데이트 방법은 안내하지 않습니다. full-send가 거치는 sol-loop는 GPT Sol을, 교차 리뷰 스킬 council은 세 회사의 모델을 부를 수 있어야 합니다. PR 감시 스크립트 pr-wait는 현재 Windows에서 시작되지 않습니다.

tstack 소개

코딩 에이전트가 코드를 쓰는 속도는 빨라졌지만, PR을 올린 뒤의 일은 여전히 사람이 지켜봐야 하는 경우가 많습니다. CI 실패를 확인하고, AI 리뷰 봇이 남긴 코멘트 중 실제 문제를 골라 고치고, 베이스 브랜치가 움직이면 리베이스하고, 병합해도 되는 시점을 판단하는 일입니다. 이 단계를 에이전트에게 맡기면 체크가 끝나기 전에 에이전트가 턴을 끝내 작업이 멈추거나, 리뷰 지적을 하나씩 받아들이다 PR이 처음 목적보다 커지기 쉽습니다. 이번에 소개하는 tstack은 이 단계를 에이전트에게 맡기려고 써 온 스킬 9개를 다른 사람도 쓸 수 있게 정리한 프로젝트입니다. T3 Code를 만든 Ping.gg의 CEO Theo Browne이 공개했습니다.

tstack의 스킬은 각각 부르는 말이 정해져 있습니다. "full send"라고 말하면 full-send가, "babysit"이라고 말하면 babysit-pr이 실행되는 식입니다. 큰 스킬은 작은 스킬을 불러 씁니다. full-send는 리뷰를 sol-loop에, PR 작성을 file-pr에, PR 감시를 babysit-pr에 맡기고, 그 결과를 모아 병합 여부를 스스로 판정합니다. 스킬들에는 공통 원칙이 반복해서 나옵니다. 이번 세션에서 직접 관찰한 증거만 증명으로 인정하고, 일어난 문제만 최소한으로 고치고, 리뷰 루프가 PR을 키우지 못하게 막으라는 것입니다.

tstack 저장소는 SKILL.md 마크다운 파일 9개와 Python 스크립트 1개(pr-wait)로 구성되어 있고, 별도 패키지나 설치 프로그램이 없습니다. 일부 스킬은 T3 Code의 도구가 있으면 그것을 쓰고, 없으면 Claude Code나 Codex의 기본 도구로 대신합니다. 하위 작업을 다른 모델에 맡기는 delegate_task, PR 변화를 알려주는 watch_pull_request가 그런 도구입니다. T3 Code는 Claude Code, Codex, Cursor 등 여러 코딩 에이전트를 데스크톱, 웹, 모바일 앱에서 조작하는 MIT 라이선스 오픈소스 프로젝트입니다.

tstack vs. gstack

Y Combinator 대표 Garry Tan이 공개한 gstack ( gstack: Y Combinator 대표 Garry Tan이 공개한, Claude Code로 20인 규모의 가상 엔지니어링 팀을 만드는 스킬 모음)도 "매일 쓰는 스킬 모음"을 공개했다는 점에서 비슷하게 보입니다. 다만 다루는 범위와 설치 방식이 크게 다릅니다. 두 저장소의 README와 스킬 문서를 기준으로 비교하면 다음과 같습니다:

항목	tstack	gstack
다루는 범위	변경 증명, 리뷰, PR 작성과 감시, 병합	제품 기획, 설계, 구현 리뷰, QA, 보안 감사, 배포, 회고
구성	스킬 9개 (마크다운 + Python 스크립트 1개)	역할별 슬래시 명령 수십 개와 브라우저 도구
PR 이후 단계	CI와 리뷰 봇 이벤트를 기다리는 감시 스크립트, 병합 게이트	`/ship`(테스트, 리뷰, PR 생성), `/land-and-deploy`(병합, 배포, 운영 확인), `gstack-pr-wait` CLI
다른 모델의 의견	GPT Sol 리뷰 루프, 세 회사 모델 교차 리뷰	`/codex`, `/claude-code` 두 번째 의견 명령
지원 하네스	Claude Code, Codex (T3 Code 기능 선택 사용)	Claude Code 정식, Codex 등 다른 에이전트는 실험적 지원
설치	`skills/` 폴더 복사	`./setup` 스크립트(Bun 필요), 팀 모드 자동 업데이트

gstack이 개발 주기 전체를 역할로 나눠 맡긴다면, tstack은 변경을 마무리하는 데서 시작해 PR이 병합될 때까지의 구간에 집중합니다. 그 대신 이 구간의 규칙은 더 자세합니다. 예를 들어 리뷰 봇의 지적을 어떻게 걸러 내는지, 체크를 기다리는 동안 턴을 끝내지 않으려면 무엇으로 기다려야 하는지, 병합 전에 무엇을 다시 확인해야 하는지가 적혀 있습니다.

tstack을 사용하면 좋을 사용자

tstack은 GitHub에서 PR과 CI로 일하고, Claude Code나 Codex에게 PR 단계까지 맡기고 싶은 개발자에게 맞습니다. babysit-pr의 기본 대기 조건은 Greptile이나 Macroscope 같은 AI 리뷰 봇의 리뷰를 전제로 합니다. 그래서 이 봇들을 이미 쓰는 저장소라면 설정 없이 바로 쓸 수 있습니다. 스킬 내용이 짧은 마크다운이라 그대로 쓰기보다 팀 규칙에 맞게 고쳐 쓰는 출발점으로 삼기에도 좋습니다. Theo Browne도 README에서 이 스킬들을 출발점으로 보고 직접 고쳐 쓰라고 권합니다.

반대로 Claude Code만 쓰고 GPT Sol을 부를 방법이 없다면, 핵심인 full-send와 full-stop을 끝까지 실행하기 어렵습니다. full-send의 3단계가 sol-loop를 거치는데, sol-loop는 GPT Sol을 실행할 경로가 없으면 다른 모델로 대신하지 않고 중단 사유를 보고하도록 되어 있기 때문입니다. GPT Sol을 부를 수 없는 Claude Code 환경이라면 tstack의 핵심 스킬은 아직 적절한 선택지가 아닙니다. 이 경우에도 file-pr, babysit-pr, takeover, modernize는 다른 모델 없이 쓸 수 있습니다. Windows에서 T3 Code 없이 쓰면 pr-wait가 시작되지 않아 babysit-pr에 감시 도구가 없습니다. 병합 전에 사람의 검토를 반드시 거쳐야 하는 팀이라면 full-send 대신 full-stop을 쓰는 것이 맞습니다.

tstack의 스킬 구성

tstack의 9개 스킬과 각 스킬을 부르는 말은 다음과 같습니다:

스킬	부르는 말	하는 일
`full-send`	"full send"	사람이 지켜보지 않는 상태에서 변경을 증명, 리뷰, PR 작성, 감시를 거쳐 병합까지 진행
`full-stop`	"full stop"	`full-send`와 같지만 PR이 병합 가능한 상태가 되면 멈춤
`council`	"council"	서로 다른 회사의 모델 셋에게 리뷰를 받고, 모두 동의할 때까지 반복
`sol-loop`	"sol loop"	작업 에이전트와 GPT Sol 리뷰어가 모두 동의할 때까지 변경을 반복 리뷰
`file-pr`	"file a PR"	변경 목록이 아니라 문제부터 설명하는 짧은 PR 작성
`takeover`	"take over"	다른 사람이나 에이전트의 PR, 브랜치, 스레드를 이어받아 끝내고 원작자 기여 표시를 유지
`babysit-pr`	"babysit"	CI와 리뷰 봇을 지켜보며 실제 지적을 고침
`modernize`	"modernize"	오래된 PR을 리베이스하고, 그 PR이 아직 필요한지 판단
`leaving-pr-comments`	(자동)	에이전트가 사용자 대신 남기는 댓글의 형식 지정

스킬끼리 서로 불러 쓰므로, 일부만 설치할 때는 의존하는 스킬도 함께 넣어야 합니다. 아래 그림은 README의 의존 관계를 옮긴 것으로, 화살표는 호출하는 스킬에서 불려 나오는 스킬 방향입니다:

tstack의 full-send와 full-stop 동작 방식

full-send는 사용자가 이 스레드를 보고 있지 않다는 전제에서 출발합니다. 그래서 진행 상황과 최종 메시지는 작업이 끝나고 한참 뒤에야 읽히고, 에이전트가 체크를 기다리다 턴을 끝내면 다시 깨워 줄 사람도 없습니다. 스킬은 이 문제를 막으려고 1단계부터 7단계까지 쉬지 않고 진행하고, 기다릴 때는 반드시 babysit-pr의 감시 도구를 쓰라고 지시합니다. 단계는 변경 마무리, 증명, sol-loop 리뷰, file-pr로 PR 작성, babysit-pr로 감시, 병합, 보고 순서입니다.

증명(Proof)은 이번 세션에서 에이전트가 직접 관찰한 증거로 정의됩니다. 스킬은 변경이 허락하는 가장 직접적인 증명을 쓰라고 하면서, 원래 실패를 재현하고 수정한 뒤 같은 재현이 통과하는 것을 보는 방식을 먼저 듭니다. CI가 실행하는 타입 검사, 린트, 테스트를 실행하는 방식과, 테스트 환경이 있는 저장소에서 수정 전에는 실패하는 테스트 하나를 추가하는 방식도 함께 나열되어 있습니다. UI와 런타임 동작은 앱을 실행해서 직접 봐야 하며, 목(mock)으로 통과한 테스트는 사용자 경험이 동작한다는 증명이 아니라고 적혀 있습니다. 증명할 방법을 찾지 못하면 확신이 없는 것으로 보고 사용자에게 묻습니다.

병합 게이트는 최신 커밋에서 다음 다섯 가지가 모두 참일 때 통과합니다:

증명이 diff의 모든 변경을 덮는다.
필수 체크가 모두 통과했다.
리뷰 봇이 리뷰를 마쳤고, 각 지적은 수정되었거나 사유를 적어 기각되었다.
변경을 요청한 사람의 리뷰가 남아 있지 않다.
브랜치가 기본 브랜치와 최신 상태이고, GitHub가 병합 가능하다고 보고한다.

병합은 저장소가 쓰는 방식을 따르고, 브랜치 보호를 우회하는 --admin 같은 옵션은 쓰지 않습니다. 다만 자동 리뷰가 "사람의 리뷰가 필요하다"고 요청한 경우에는 에이전트가 변경에 높은 확신을 가지면 무시해도 된다고 적혀 있습니다. 봇의 이런 요청을 사람 검토의 신호로 쓰는 팀이라면 이 문장을 먼저 고쳐 두는 것이 안전합니다.

full-send는 호출되는 순간 세 가지를 허락받은 것으로 봅니다. 병합 게이트를 통과하면 PR을 병합할 수 있고, 리베이스 후 PR 브랜치를 --force-with-lease로 푸시할 수 있고, 증명에 필요한 테스트 방법을 묻지 않고 쓸 수 있습니다. 프로젝트의 CLAUDE.md 등에 브라우저 자동화, 시뮬레이터, 앱이나 개발 서버 실행, 스크린샷 전에 먼저 물어보라고 적혀 있어도, "full send" 요청이 그 규칙을 대신합니다. 대신하는 것은 먼저 묻는 단계뿐이고, 어떤 명령이나 픽스처(fixture)로 테스트하라는 규칙은 그대로 따릅니다. 이 허락은 이번 작업의 테스트에만 적용되고, 운영 환경 변경이나 데이터 삭제처럼 사용자에게 물어야 하는 일에는 적용되지 않습니다. 하네스나 시스템이 표시하는 승인 창을 건너뛰지도 않습니다.

에이전트가 사용자에게 물어야 할 때는 일반 메시지가 아니라 질문 도구를 씁니다. 일반 메시지로 물으면 스레드가 끝난 것처럼 보여 아무도 답하지 않기 때문입니다. Claude Code에서는 AskUserQuestion, Codex에서는 request_user_input을 쓰고, 질문에 PR 링크와 막힌 이유, 추천안을 먼저 둔 선택지를 담습니다. 답을 받을 수 없으면 PR을 병합하지 않은 채로 두고, 최종 메시지의 첫머리에 질문을 적습니다.

full-stop은 full-send의 과정과 테스트 허락을 그대로 쓰지만 병합 권한은 받지 않습니다. 작업 브랜치에서 커밋, 푸시, 리베이스, 충돌 해결, --force-with-lease는 할 수 있고, 병합, 자동 병합 설정, 병합 대기열 등록, 기본 브랜치 푸시는 하지 않습니다. 작업을 시작하기 전에 이미 켜져 있던 자동 병합을 끄고 병합 대기열에서도 빼며, 푸시할 때마다 이를 다시 확인합니다. 마지막에는 병합 가능, 사람의 승인만 남음, 막힘 중 하나로 상태를 보고합니다.

full-stop의 스킬 설명에는 even as a closing "Full stop." that reads like emphasis라는 문구가 들어 있습니다. 영어 지시문 끝에 강조 표현으로 "Full stop."을 쓰기만 해도 이 스킬이 실행되도록 일부러 넓힌 것입니다. 영어로 지시를 쓰는 사용자라면, 예상하지 못한 순간에 커밋과 푸시가 시작될 수 있다는 점을 알아 두어야 합니다. 직접 부를 때만 실행되게 하려면 Claude Code에서는 ~/.claude/settings.json의 skillOverrides에 "full-stop": "user-invocable-only"를 넣습니다. /skills 메뉴에서 user-only로 바꾸는 방법도 있지만, 이때는 현재 프로젝트의 .claude/settings.local.json에만 저장됩니다. 두 방법 모두 스킬 파일을 고치지 않으므로 스킬을 다시 복사해도 유지됩니다. Codex에서는 스킬에 들어 있는 full-stop/agents/openai.yaml에 다음 설정을 더합니다:

policy:
  allow_implicit_invocation: false

이렇게 해도 Claude Code의 /full-stop, Codex의 $full-stop처럼 이름으로 직접 부르는 호출은 그대로 동작합니다.

tstack의 리뷰 스킬: sol-loop와 council

sol-loop는 OpenAI의 GPT Sol에게 변경을 반복해서 리뷰받는 절차입니다. 기본 예산은 3라운드이고, 1라운드는 전체를, 이후 라운드는 바뀐 코드와 남은 지적만 봅니다. 보안, 권한, 인증, 데이터 손실, 상태나 동시성 문제에서 blocker나 should 지적이 근거와 함께 남아 있거나 사용자가 요청하면 5라운드까지 늘립니다. 반대로 한 라운드가 nit만 돌려주면 일찍 끝냅니다. 리뷰어는 지적마다 세 단계 심각도를 매깁니다. blocker는 의도한 경우가 틀린 것, should는 호출하는 쪽이 실제로 겪을 버그, nit은 그 밖의 모든 것입니다. 에이전트는 이 등급을 그대로 받지 않고 직접 다시 판정하며, 다른 경로나 드문 경우, 작은 성능 비용에 관한 지적은 붙은 등급과 상관없이 nit으로 봅니다.

sol-loop는 리뷰가 PR을 키우는 것을 막는 규칙을 여럿 두고 있습니다. 동의하는 지적은 가장 작은 수정으로 고치고, 새 락이나 캐시나 옵션을 더하기보다 코드를 지우거나 좁히는 쪽을 택합니다. 동의하지 않으면 파일 위치나 테스트 출력 같은 근거로 반박하고, 루프를 끝내려고 동의하지 말라고 적혀 있습니다. 같은 항목을 두 번 주고받은 뒤에도 합의되지 않거나 예산이 끝나면, 양쪽 주장을 2~3줄씩 정리해 사용자가 판단하게 합니다. 예산이 끝난 것은 승인으로 치지 않습니다.

GPT Sol을 실행하는 경로는 환경마다 다릅니다. T3 Code에서는 delegate_task로 Sol을 고르고, 그 밖의 환경에서는 하네스가 기본으로 제공하는 Sol 서브에이전트를 씁니다. Claude Code에서는 Sol을 실행하도록 설정한 커스텀 서브에이전트가 있을 때만 씁니다. 어느 경로도 없으면 다른 모델로 바꾸지 않고 중단 사유를 보고합니다. 현재 스킬 문서는 리뷰를 기다리는 시간에 상한을 두지 않고, Sol의 추론 강도(reasoning effort)도 지정하지 않습니다. 이 두 점은 각각 이슈 #8과 이슈 #5로 보고되어 있습니다. 한 번 기다리는 시간을 10분, 한 라운드를 30분으로 제한하는 PR #9도 열려 있습니다.

council은 서로 다른 회사의 모델 셋을 리뷰어로 부릅니다. 사용자가 구성원을 지정하지 않으면 회사별 최신 주력 모델을 높은 추론 강도로 고르고, 예시로 Claude Opus, GPT Sol, Gemini Pro를 듭니다. 리뷰를 맡기기 전에 남은 PR 코멘트와 알려진 문제를 먼저 고치고 관련 체크를 실행합니다. 리뷰와 피드백 요청이면 리뷰어는 읽기만 하고, 코드 리뷰라면 각자 10점 만점 점수를 매깁니다. 에이전트는 동의하는 권고를 반영한 뒤 새 리뷰를 요청하고, 모든 리뷰어가 만족할 때까지 이 과정을 반복합니다. 작업이 PR로 끝나면 라운드별 점수 표를 PR 설명에 넣고, 점수를 주지 않은 리뷰어는 no score로 적습니다. 세 회사에 닿지 못하거나 지정한 구성원을 쓸 수 없으면 역시 다른 모델로 바꾸지 않고 보고합니다.

tstack의 PR 감시: babysit-pr와 pr-wait

babysit-pr는 PR 하나에 감시 도구 하나만 쓰고, 직접 만든 폴링 루프나 sleep 루프는 쓰지 말라는 규칙에서 시작합니다. GitHub 계정의 모든 감시 도구가 같은 호출 한도를 나눠 쓰기 때문입니다. T3 Code에서는 watch_pull_request를 쓰는데, T3 Code 문서에 따르면 서버가 2분마다 PR을 확인하고 체크 실패, 필수 체크 통과, 새 코멘트나 리뷰, 충돌이 생기면 에이전트를 깨웁니다. 그 밖의 환경에서는 스킬에 들어 있는 pr-wait 스크립트를 씁니다:

pr-wait <pr> [--repo owner/name] [--until ready|green|any-change]

pr-wait는 의미 있는 이벤트가 생길 때마다 한 줄씩 출력합니다. 체크와 관련해서는 필수 체크 실패와 모든 체크 완료를 알립니다. PR 작성자나 gh 사용자가 아닌 사람의 새 코멘트, 리뷰, 리뷰 스레드와 답글, 리뷰 봇의 리뷰 완료도 이벤트입니다. 브랜치 쪽으로는 이 PR의 파일을 건드린 베이스 브랜치 커밋, 병합 상태가 BEHIND(베이스보다 뒤처짐)나 DIRTY(충돌)로 바뀌는 것, 병합과 닫힘을 알립니다. GitHub Actions나 Vercel 같은 CI와 배포 봇의 코멘트는 체크로 이미 알 수 있으므로 건너뜁니다.

Claude Code에서는 이 스크립트를 Monitor 도구로 실행해 줄마다 에이전트가 깨어나게 하라고 안내합니다. 종료 코드는 다음과 같습니다:

종료 코드	의미
`0`	`--until` 조건을 만족했거나 PR이 병합됨
`1`	필수 체크 실패, 충돌, PR 닫힘, `ready` 조건에서 해결되지 않은 스레드나 BEHIND 상태, GitHub에 계속 접속하지 못함처럼 에이전트의 조치가 필요함
`2`	잘못된 인자, 없는 PR, 같은 PR을 이미 다른 `pr-wait`가 감시 중

기본 조건인 ready는 필수 체크 통과에 더해 Greptile이나 Macroscope가 최신 커밋을 리뷰하고, 해결되지 않은 스레드가 없어야 만족됩니다. 두 봇의 이름은 스크립트에 고정되어 있어서, 이 봇들이 없는 저장소에서는 ready가 끝나지 않으므로 --until green을 써야 합니다. 이 문제는 이슈 #7로 보고되어 있습니다. Codex나 Copilot 같은 다른 리뷰 봇도 대기 조건에 들어가지 않아서, 이 봇들이 최신 커밋을 리뷰하기 전에 ready가 만족될 수 있습니다. CodeRabbit의 지적은 다른 지적과 똑같이 다루지만, 리뷰가 끝나기를 기다리지는 않습니다. 다만 CodeRabbit이 남긴 스레드가 해결되지 않은 채 남아 있으면 그것도 ready를 막습니다.

pr-wait는 이미 보고한 내용을 ~/.local/state/pr-wait/에 기록해 두므로, 6시간 안에 다시 시작하면 그 사이에 도착한 이벤트를 놓치지 않습니다. 기록이 6시간보다 오래되면 새 기준점에서 다시 시작합니다. 처음 실행할 때는 PR에 이미 있는 내용을 기준점으로만 기록하고 그 뒤의 변화만 보고합니다.

리뷰 대응 규칙은 봇의 지적을 그대로 믿지 않는 쪽으로 쓰여 있습니다. 최신 푸시 이후의 체크와 코멘트만 다루고, 코드를 바꾸기 전에 모든 봇 지적을 소스와 대조합니다. 실제 버그와 CI 실패는 고치고, 저장소 문제와 인프라의 일시적 실패를 구분하며, 오탐은 사유를 적어 답한 뒤 해결 처리합니다. 필요 없는 테스트, 중요하지 않은 경계 조건 처리, 작은 성능 비용 같은 지적은 사유를 적어 거절하고 후속 작업 목록에 올립니다. GitHub GraphQL 호출 한도를 다 쓰면 gh api의 REST 경로로 PR과 체크를 읽으라는 안내도 있습니다. babysit-pr를 단독으로 부르면 병합까지 하지 않습니다. 사용자가 병합을 명시적으로 요청한 경우에만 병합하고, 그렇지 않으면 PR이 준비되었다고 보고합니다.

pr-wait는 Python 표준 라이브러리만 쓰는 556줄짜리 스크립트이고, 실행하는 외부 명령은 GitHub CLI인 gh 하나뿐입니다. 기본값으로 20초마다 PR을 조회하고, --interval로 간격을 바꿀 수 있습니다(최소 5초). 다만 파일 잠금에 fcntl 모듈을 import하는데 Windows Python에는 이 모듈이 없어서, Windows에서는 스크립트가 시작되지 않습니다. 이를 고치는 PR #11이 열려 있지만 아직 병합되지 않았습니다.

tstack의 PR 작성과 인계 스킬

file-pr는 PR 제목이 커밋 메시지가 되는 경우가 많다는 점에서 출발해, 저장소의 제목 규칙을 따르되 변경이 왜 중요한지 드러나는 제목을 쓰라고 합니다. 스킬에 실린 예시에서는 perf(server): negotiate permessage-deflate on the websocket보다 perf(server): cut websocket frame size by 70%+ with gzipping이 낫다고 봅니다. 설명은 사용자가 처음 요청한 문제부터 쉽게 설명하고 해결책을 짧게 덧붙이며, 바꾼 함수 목록으로 시작하지 않습니다. 끝에는 Created with <model> in <harness>. 형식으로 변경을 만든 모델과 하네스를 적습니다. 리뷰 봇이 돌도록 초안(draft)이 아닌 실제 PR을 열고, 제출 전에 제목과 설명과 첨부 파일에서 비밀 정보를 확인합니다.

leaving-pr-comments는 에이전트가 사용자 대신 남기는 모든 GitHub 댓글 앞에 다음 형식의 표시를 붙입니다. 모델 이름은 하네스가 알려주는 공개 이름을 쓰고, 모를 때는 하네스 이름을 쓰며 추측하지 않습니다:

> [!NOTE]
> 🤖 **<model> responding on behalf of <user>**

Actual comment starts here.

takeover는 다른 사람이나 다른 에이전트가 하던 PR, 브랜치, 스레드를 이어받아 끝냅니다. 새 PR로 대신 올릴 때는 원래 커밋을 새 브랜치로 가져온 뒤 수정을 따로 커밋합니다. Git 작성자 정보와 공동 작성자(co-author) 표시를 유지하고, PR 설명에도 원작자를 밝힙니다. 모델 표시는 기여자 표시를 대신하지 않는다고 적혀 있습니다. 이어받은 구현이 이미 있다는 이유만으로 그 구현을 고집하지 말라는 점도 함께 적혀 있습니다.

modernize는 오래된 PR을 최신 베이스 브랜치에 맞추는 스킬이지만, 충돌 없이 리베이스된다고 그 PR이 아직 필요하다는 뜻은 아니라는 관점에서 출발합니다. 그래서 그 사이 같은 문제가 이미 해결됐는지, API나 스키마나 아키텍처 경계가 바뀌었는지를 먼저 봅니다. 결과는 MODERNIZE(리베이스해서 갱신), REWORK(목적은 유효하지만 구현을 다시 써야 함), CLOSE(이미 대체되었거나 비용만큼 가치가 없음) 중 하나로 판정합니다. 리베이스 전후의 커밋은 git range-diff로 비교하고, 푸시는 리베이스 전에 확인한 원격 헤드를 기준으로 한 --force-with-lease로만 합니다. PR을 닫는 것은 명시적인 허락이 있을 때만 합니다.

tstack 설치와 사용

tstack을 쓰려면 인증된 GitHub CLI(gh)와 pr-wait를 실행할 python3가 필요합니다. sol-loop는 GPT Sol을, council은 세 회사의 모델을 하위 작업으로 실행할 수 있는 하네스가 있어야 합니다. 설치는 저장소를 받아 skills/ 폴더 안의 스킬을 사용자 스킬 폴더에 복사하는 방식입니다:

git clone https://github.com/t3dotgg/tstack
cp -R tstack/skills/* ~/.claude/skills/   # Claude Code
cp -R tstack/skills/* ~/.codex/skills/    # Codex

Codex의 스킬 문서는 사용자 스킬 위치로 ~/.agents/skills를 안내합니다. 다만 Codex 소스 코드는 ~/.codex/skills도 사용자 스킬 위치로 함께 읽으므로, README의 명령 그대로 설치해도 동작합니다. 위 명령은 9개 스킬을 모두 복사하므로, 일부만 쓰려면 앞의 의존 관계 그림을 보고 필요한 스킬을 함께 복사합니다. 설치한 뒤에는 에이전트에게 작업을 맡기면서 "full stop"이나 "babysit"처럼 스킬을 부르는 말을 함께 적으면 됩니다.

Claude Code 플러그인 마켓플레이스로 배포하자는 PR #6과 npx skills add 설치 방법을 더하자는 PR은 열려 있지만 병합되지 않았습니다. tstack이 안내하는 방법만 따르면, 업데이트하려면 저장소를 다시 받아 복사해야 합니다. Theo Browne은 council 구성원 같은 개인 설정을 스킬 파일이 아니라 CLAUDE.md나 AGENTS.md에 적어 두라고 권합니다. 그래야 스킬을 덮어써도 설정이 사라지지 않습니다. 앞에서 설명한 Codex의 agents/openai.yaml 설정은 스킬 폴더 안의 파일을 고치는 것이므로, 다시 복사하면 원래 파일로 덮어써집니다.

tstack의 라이선스

tstack은 MIT 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다.

tstack 프로젝트 GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임에서 이런 글들을 계속 정리하고 있습니다. 회원 가입으로 주요 글들을 이메일로, 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로 새 글 알림을 받아보세요!

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~