런타임 어댑터를 이 워크플로우를 따르기 전에 읽으십시오. 해당 런타임 매핑은 참조된 모든 플레이북과 스크립트에 적용됩니다.
Pstack 트리오
하나의 Herdr 또는 Rex 세션, 하나의 저장소에서 세 명의 에이전트가 협업합니다. 마스터는 판단을, 사이드킥은 작업 트리를, 컨설턴트는 제2의 의견을 소유합니다. 에이전트 간의 모든 메시지는 트리오 저장소의 파일과 해당 파일을 지칭하는 한 줄의 프롬프트로 구성됩니다. 터미널은 기록을 남기지 않으므로(대체 화면의 에이전트는 스크롤백이 없음) 터미널을 기록으로 사용하지 않습니다.
트리오는 pstack-pair에 컨설턴트가 추가된 형태입니다. 페어의 계획 회차(plan round), 브리프, 체크인, 조정(steer), 리뷰는 변경되지 않았습니다. 컨설턴트는 모든 계획 회차에 참여하며, 발견 사항이 설계를 변경할 때 자문에 응답합니다. 컨설턴트는 사이드킥에게 메시지를 보내거나 공유 트리에 쓰지 않습니다.
전제 조건
- Herdr (
test "${HERDR_ENV:-}" = 1) 또는 Rex (REX_BLOCK설정) 내부에 있어야 합니다. 둘 다 외부에 있으면 그렇게 말하고 중지합니다. - 창 및 에이전트 제어를 위한 멀티플렉서의 스킬을 로드합니다: Herdr의
~/.agents/skills/herdr/SKILL.md(또는 해당 파일이 없을 경우herdr --skill), 또는 Rex의rex skill show. 해당 안전 규칙은 전체에 적용됩니다. Rex에서 Rex에서 실행을 읽으십시오. herdr또는rex, 그리고 Python 3.11 이상 (python3)이 PATH에 있어야 합니다.scripts/pair.sh help는 모든 저장소 및 채널 작업을 나열합니다. 트리오를 위해 수동으로herdr또는rex호출을 작성하는 대신 사용하십시오.- 마스터, 사이드킥, 컨설턴트 중 적어도 두 개 이상의 서로 다른 에이전트 종류가 필요합니다.
pair.sh spawn은 멀티플렉서에서 마스터의 종류를 읽고 세 가지가 모두 일치하면 종료 코드 8을 반환합니다. 사용자에게 다른 종류를 선택하거나pstack-pair를 사용하라고 알리십시오. 사이드킥과 컨설턴트는 같은 종류를 공유할 수 있습니다. - 마스터를 자동 모드로 시작합니다. Devin은 기본적으로
--permission-mode dangerous로 권한을 우회합니다. 다른 종류는 마스터의 모드를 상속받습니다.pair.sh permission은 감지된 마스터 모드를 출력합니다.--permission <mode>는 두 역할을 모두 재정의합니다.--consultant-permission <mode>는 컨설턴트만 재정의합니다.--뒤의 네이티브 권한 플래그는 해당 호출로 생성된 모든 역할의 기본값을 재정의합니다.--permission auto는 Devin 스마트 모드를 선택합니다. 번역이 없는 종류는--뒤에 네이티브 플래그를 사용합니다.spawn은 또한 각 종류의 폴더 신뢰 프롬프트를 건너뜁니다. 이 프롬프트는 무인 에이전트가 본 적 없는 폴더에서 대기하게 만들 수 있습니다. pi는--approve를, Devin은--respect-workspace-trust false를 사용합니다.--뒤의 신뢰 플래그는 이를 재정의합니다. 생성된 Claude는 MCP 서버 없이 시작됩니다(--strict-mcp-config및 빈 설정). 각 서버는 세션 당 하나의 프로세스이기 때문입니다.--뒤의--mcp-config는 사용자 설정을 유지합니다. Claude와 Codex는 대신 본 적 없는 폴더를 신뢰하도록 요청합니다. 이 결정은 사람의 몫이므로spawn은 대화를 거절하고 수행할 작업과 함께 중지됩니다: 해당 에이전트를 저장소에서 한 번 열고 신뢰하십시오.
역할
| 마스터 | 사이드킥 | 컨설턴트 | |
|---|---|---|---|
| 소유 | 계획, 브리프, 자문, 리뷰, 결정, 사용자 | 작업 트리, 테스트, 진단, 증거 | 설계 비평, 재검토, 프로토타입 |
| pstack 실행 방식 | poteto-mode 프레이밍, how, architect, 리뷰 스킬 | 각 브리프가 지정하는 플레이북 및 해당 todolist | how, why, architect 대안, interrogate 자세, diff에 대한 blast-radius |
| 쓰기 | 트리오 저장소만 | 브리프 범위 내 파일, 진행 로그 및 보고서 | 조언 파일 및 제거하는 임시 작업 트리 |
| 트리 읽기 | 항상, 읽기 전용; 커밋에서 임시 공간(scratch)에서 검사 실행 | 항상 | 항상, 읽기 전용 |
| 통신 방식 | 계획, 브리프, 조정, 자문, 리뷰, 지시, 게이트 | 진행 라인, 보고서 | 조언 |
역할에 진입하십시오. 마스터: references/master.md. 사이드킥: references/sidekick.md. 컨설턴트: references/consultant.md.
트리오 저장소
${XDG_STATE_HOME:-$HOME/.local/state}/pstack/trio/<slug>/, pair.sh init으로 생성됩니다. 파일당 하나의 작성자.
| 경로 | 작성자 | 내용 |
|---|---|---|
pair.json | pair.sh를 통해 마스터 | 에이전트 이름, 창 ID, 종류, cwd, git 루트, 열린 임시 공간 목록, 사이드킥의 폴백 및 장애 조치, 창 배치(분할 또는 탭) |
standing-orders.md | 마스터 | 모든 브리프에 경로별로 붙여넣어지는 번호가 매겨진 제약 조건 |
plans/NNN-<slug>.md | 마스터 | 계획 템플릿의 하나의 계획 회차 |
briefs/NNN-<slug>.md | 마스터 | 브리프 템플릿의 하나의 단위 |
progress/NNN-<slug>.md | pair.sh progress를 통해 사이드킥 | 완료된 단계 또는 접근 방식 변경당 하나의 타임스탬프가 찍힌 라인 |
steers/NNN-<slug>-s<k>.md | 마스터 | 단위 NNN에 대한 중간 브리프 방향 k, 조정 템플릿에서 |
consults/NNN-<slug>-c<k>.md | 마스터 | 컨설턴트를 위한 단위 NNN에 대한 질문 k, 자문 템플릿에서, kind:는 design, finding, objection, 또는 review |
reports/NNN-<slug>-s<k>.md | 사이드킥 | 조정 k에 대한 이의 제기, 조정 응답 템플릿에서 |
reports/NNN-<slug>.md | 사이드킥 | 브리프 NNN에 대한 증거, 보고서 템플릿에서, 또는 계획 NNN에 대한 동의/이의 응답, 계획 응답 템플릿에서 |
advice/NNN-<slug>.md | 컨설턴트 | 계획 NNN에 대한 설계 비평, 계획 조언 템플릿에서 |
advice/NNN-<slug>-c<k>.md | 컨설턴트 | 자문 k에 대한 답변, 조언 템플릿에서 |
scratch/<id> | pair.sh scratch를 통해 컨설턴트 또는 마스터 | 하나의 자문(NNN-<slug>-c<k>) 또는 리뷰(NNN-<slug>-review)를 위한 폐기 가능한 작업 트리에 대한 링크, 커밋 또는 라이브 상태에서, 저장소 외부의 ${XDG_STATE_HOME:-~/.local/state}/pstack/scratch/ (PSTACK_SCRATCH_ROOT가 이동시킴)에 유지되며, Claude와 Codex는 호스트당 한 번 신뢰해야 함 (kitchen.py doctor 확인); 완료되면 제거됨 |
reviews/NNN-<slug>.md | 마스터 | 단위 NNN에 대한 판결, 리뷰 템플릿에서; 참조한 조언과 모든 기각(overrule)을 명명함 |
gates.md | 마스터 | 사용자를 위한 열린 질문 |
decisions.tsv | pair.sh log를 통해 마스터 | 작업 증명 추적 |
status.md | pair.sh status | 파생된 테이블; 수동 편집 금지 |
queue | pair.sh queue 및 dispatch를 통해 마스터 | 다음 브리프의 경로, 하나의 슬롯 |
steps/NNN-<slug>.tsv | pair.sh step을 통해 사이드킥 | 커밋된 단계당 한 행: 번호, 커밋, 시간, 해결하는 노트, 요약 |
notes/NNN-<slug>-n<k>.md | pair.sh new-note 및 note를 통해 마스터 | 단계 k까지 단위 검토, 노트 템플릿에서: 차단 항목 및 후속 조치 |
followups.md | pair.sh note를 통해 마스터 | 모든 노트의 후속 조치, 이후 브리프 또는 이슈용 |
session-handoff.md | 마스터 | 간결한 복구 및 다음 작업 컨텍스트, 부트스트랩 시 읽음 |
sessions/ | pair.sh spawn / rotate | 이전 준비 보고서; 보존된 세션 내보내기 및 타이밍 증거 |
events.tsv | 모든 pair.sh 명령 | 메시지, 보고서, 웨이크, 로그 항목당 한 행, pair.sh metrics가 읽음 |
NNN은 계획 또는 브리프, 보고서, 조언, 리뷰에서 공유되는 0으로 채워진 시퀀스이므로 하나의 단위에 대한 파일이 함께 정렬됩니다.
메시지
| 프롬프트 텍스트 | 방향 | 발신자 도우미 | 수신자 이동 |
|---|---|---|---|
| bootstrap (스킬, 역할, 저장소 이름 지정) | 마스터에서 사이드킥과 컨설턴트로 | pair.sh spawn | 부트스트랩 단계, reports/000-ready.md 또는 advice/000-ready.md, READY 응답 |
pstack-trio PLAN <plan-path> | 마스터에서 사이드킥과 컨설턴트로 동시에 | pair.sh discuss | 사이드킥은 계획을 코드에 근거함; 컨설턴트는 설계를 비평함; 각각 동의 또는 이의를 작성하고 턴을 종료함 |
pstack-trio BRIEF <brief-path> | 마스터에서 사이드킥으로 | pair.sh dispatch | 브리프 실행, 보고서 작성, pair.sh finish 실행, REPORT 라인으로 턴 종료 |
pstack-trio BRIEF <brief-path>, 대기 중 | 마스터에서 작업 중인 사이드킥으로 | pair.sh queue | 마스터는 새 세션 후에 전달함; pair.sh next는 거부함 |
pstack-trio STEER <steer-path> | 작업 중인 사이드킥 또는 이의 제기로 일시 중지된 사이드킥으로 마스터 | pair.sh steer | 도구 호출 사이에 읽음; 동의하고 계속하거나, 증거와 함께 이의를 제기하고 턴을 종료함 |
pstack-trio CONSULT <consult-path> | 마스터에서 컨설턴트로 | pair.sh consult | 명명된 파일을 읽고, 필요한 경우 임시 공간에서 프로토타입을 만들고, 조언을 작성하고, 턴을 종료함 |
pstack-trio REPORT <report-path> | 사이드킥에서 마스터로 | pair.sh finish (또는 notify) | 보고서를 읽고 검토함 |
pstack-trio ADVICE <advice-path> | 컨설턴트에서 마스터로 | pair.sh notify | 조언을 읽고 결정함 |
pstack-trio STOP <store> | 마스터에서 사이드킥과 컨설턴트로 | pair.sh stop | 안전하게 일시 중지하고 중지 보고서 또는 조언을 작성함 |
discuss는 두 에이전트가 합의에 도달하면 역할당 하나의 응답 경로와 상태와 함께 반환됩니다. 단위 작업 중인 사이드킥은 회차를 지연시키지 않습니다: 컨설턴트는 즉시 계획을 받고, 사이드킥의 절반은 deferred(종료 코드 4)이며, 사이드킥이 보고한 후 discuss를 다시 실행하면 해당 절반만 전송됩니다. consult는 컨설턴트가 idle, done, 또는 blocked 상태로 안정되면 반환됩니다. dispatch 및 wait는 사이드킥의 응답이 도착하거나, 보고서가 메시지 이후에 작성되거나, blocked 상태일 때 반환됩니다. 멀티플렉서의 안정 상태(settle)만으로는 신뢰할 수 없습니다: Devin 사이드킥은 프롬프트가 도착하고 단계 사이에 유휴 상태를 보여주며, 좁은 창에서는 전체 실행에 대해 완료 상태를 보여줄 수 있으므로, 안정 상태는 창의 "esc to interrupt" 라인과 비교하여 확인되며, 보고서 없이 1분 동안 유지되는 경우 report: missing과 함께 대기가 종료됩니다. dispatch 및 wait는 또한 체크인 간격에 요약과 함께 반환됩니다. wait는 전달된 브리지의 보고서가 도착하는 즉시 반환되며, 사이드킥이 이미 대기 중인 브리프를 가져간 경우에도 마찬가지입니다. 이때 running:은 현재 작업 중인 브리프를 명명합니다. notify는 마스터가 유휴 상태일 때만 마스터를 프롬프트합니다. 압축 후 받은 메시지는 여전히 이 스킬과 읽을 파일을 명명하므로 스킬을 다시 로드하고 해당 파일부터 계속 진행하십시오.
계획 우선
구현은 사이드킥이 동의하고 컨설턴트가 조언한 계획에서만 시작됩니다. 마스터는 선택한 설계, 평가한 대안 및 그 장단점과 함께 plans/NNN-<slug>.md를 초안하고, pair.sh discuss로 보내면 두 에이전트 모두에게 동시에 도달합니다. 사이드킥은 모든 단계를 코드와 비교하고 증거와 함께 동의 또는 이의를 응답합니다. 컨설턴트는 설계 자체(데이터 형태, 경계, 대안 테이블이 놓친 것)를 비판하고 동의 또는 이의를 응답합니다. 마스터는 둘을 다음 회차 또는 agreed 판결이 있는 리뷰에 병합합니다.
컨설턴트는 자문 역할입니다. 컨설턴트의 object는 agreed를 차단하지 않습니다. 마스터는 리뷰의 기각(Overruled) 섹션과 결정 행에 이유를 명시하여 기각할 수 있습니다. 그러나 계획 회차에 대한 조언 파일은 반드시 존재해야 합니다: pair.sh dispatch는 계획에 컨설턴트 조언 파일이 없거나 agreed 리뷰가 없는 기능, 버그 수정, 리팩토링, 성능 이슈 또는 pstack-tdd 브리프를 거부합니다. 읽기 전용 및 포렌식 브리프는 계획이 필요하지 않습니다. 버그의 진단 브리프는 계획 전에 실행됩니다. 합의 없이 세 번의 회차가 지나면 사용자를 위한 게이트가 되며, 모든 입장은 gates.md에 있습니다.
자문
자문(consult)은 계획 회차 외부에서 마스터가 컨설턴트에게 하는 질문입니다. pair.sh new-consult <store> <NNN> --kind <kind>는 단위 NNN에 대한 파일을 생성합니다. pair.sh consult는 이를 보내고 조언을 기다립니다.
| 종류 | 시기 | 컨설턴트의 답변 |
|---|---|---|
| design | 마스터가 계획 또는 조정 전에 방향을 저울질할 때 | 어느 방향과 그 이유, 그리고 절충점 |
| finding | 체크인 요약, 보고서 또는 diff에서 예상치 못한 것이 드러났을 때 | 그것이 보이는 그대로인지, 그리고 무엇을 변경하는지 |
| objection | 사이드킥이 조정에 이의를 제기했을 때 | 증거에 따르면 누가 옳은지, 그리고 대안 |
| review | 판결이 이의를 제기받거나 단위가 두 번째 수정 중일 때 | 수락, 수정 또는 거절, 그리고 발견 사항 |
| glance | 체크인이 첫 번째 커밋 또는 수정 비용이 가장 많이 드는 단위의 상당한 diff를 보여줄 때 | 5분 안에: 리뷰가 수정을 권할지, 그 이유는 무엇인지, 또는 none |
자문은 다음의 경우에 필수입니다: 합의된 설계에서 벗어나는 조정, 사이드킥 이의 이후의 대체 조정, 단위 두 번째 시도에 대한 revise 판결. 다른 곳에서는 선택 사항이며, 마지막 배포 단위(landing unit)에는 전송되지 않습니다. 모든 논의와 리뷰는 배포 전에 종료됩니다. 단위당 자문 3개; new-consult는 --force 없이 네 번째를 거부합니다. 네 번째는 설계가 잘못되었으며 계획 회차에 속하기 때문입니다. Glance는 이 제한 밖에 있으며, 단위당 하나이며, 필수가 아닙니다: 컨설턴트의 할당량은 부족하므로, 늦은 수정 비용이 가장 많이 드는 곳에 사용하십시오.
모든 자문은 사이드킥이 작업 중이든 아니든 언제든지 실행됩니다. consult는 파일에 사이드킥의 상태와 HEAD를 기록합니다. 컨설턴트는 해당 HEAD에서 커밋된 작업을 읽고, 커밋되지 않은 작업은 pair.sh scratch 스냅샷을 통해서만 읽습니다. 절대 그 아래에서 움직이는 트리는 읽지 않습니다. 각 자문에는 시간 제한이 있으며, 기본값은 15분, glance는 5분입니다. 시간이 지나면 컨설턴트는 partial 조언을 작성하고 턴을 종료합니다.
체크인 및 조정
pstack-pair와 동일합니다: 사이드킥은 진행 라인을 추가하고, dispatch 및 wait는 간격에 체크인 요약을 반환하며, 조정(steer)은 작업 중인 사이드킥에게 도달할 수 있는 유일한 메시지입니다. 브리프당 두 개의 새로운 조정, 각각 두 번의 회차. 컨설턴트가 한 단계를 추가합니다: 요약 또는 이의가 설계를 변경하는 발견을 보여줄 때, 마스터는 조정하기 전에 자문하고, 조정의 방향(Direction)은 조언 경로를 인용합니다.
모든 종류의 작업 세션
모든 종류의 사이드킥(Claude, Codex, Devin, pi, Prime, Muse)은 새로운 대화 세션을 사용합니다
…
[번역을 위해 잘림]