적게 만들고, 깊게 검증한다.

Cursor 에이전트에게 엔지니어링 절차를 부여하는 스킬·플레이북·에이전트 묶음이다. 목표는 코드 생산량보다 적은 변경으로 검증 가능한 결과를 만드는 것이다.

다음은 저장소의 절차를 엔지니어링 관점에서 해석한 설명이다. 여러 모델의 동의나 절차 준수 자체가 품질을 보장하지는 않는다.

평소에는 /poteto-mode에 목표와 확인 방법을 전달한다. 모든 스킬을 사용자가 순서대로 나열할 필요는 없다.

/poteto-mode 재시도 시 내보내기 결과에 같은 행이 중복된다. 먼저 재현하고 원인을 찾은 뒤 수정해줘. 같은 입력과 재시도로 중복이 없어지는지 확인하고 실제 출력 근거를 보여줘.

poteto-mode는 대화 안에서 유지되는 모드다. 이후 일반적인 후속 요청에도 적용되며 사용자가 해제할 수 있다. 원문은 여러 트리거를 정의하므로 실제 작업 경로는 요청과 환경에 따라 달라진다.

병렬로 실행한다는 공통점보다, 무엇을 나누고 어떤 결과를 만들려는지가 중요하다.

1. 설계는 호출자 사용 방식에서 시작

   함수 내부 구현보다 호출자가 무엇을 전달하고 무엇을 받는지부터 정한다. 대안은 같은 설계의 미세 수정이 아니라 구조적으로 달라야 한다.

2. 심사는 후보가 완성된 뒤 진행

   arena의 교차 심사자는 완성된 후보와 평가 기준을 본다. 가능하면 부모와 다른 모델 계열을 사용한다. 부모도 모든 후보를 읽고 최종 판단을 책임진다.

3. 의견은 투표로 적용하지 않는다

   interrogate의 독립적인 일치는 신호이지만 최종 근거는 아니다. 각 의견을 Act on, Consider, Noted, Dismissed로 분류하고 이유를 남긴다. 리뷰 결과가 자동으로 수정되는 것은 아니다.

4. 구현 중 설계가 틀렸다면 다시 설계

   같은 우회가 여러 곳에 생기거나 호출자가 내부 규칙을 알아야 하는 경우 설계를 재검토한다. 작은 예외 하나만으로 전체 구조를 폐기하는 것은 아니다.

목적별로 찾아보되 실제 선택은 요청에 따라 poteto-mode가 수행한다. 아래는 README와 모드 정의의 용도를 요약한 목록이다.

원칙의 이름을 외우는 것보다 어떤 선택을 바꾸는지 이해하는 편이 유용하다.

이는 pstack의 규칙 요약이다. 특정 언어 사용을 강요하는 원칙과 보편적인 설계 원칙을 구분해야 한다. 예를 들어 Type System Discipline은 타입이 있는 언어에서 적용하는 규율이며 모든 프로젝트를 TypeScript로 바꾸라는 뜻은 아니다.

처음에는 작은 실제 작업 하나로 설정과 검증 경로가 작동하는지 확인한다.

1. Cursor에서 플러그인 설치

   채팅에서 /add-plugin pstack을 실행한다. 저장소 가이드에 나온 설치 방법이며, 이 웹페이지는 설치를 실행하지 않는다.

2. 모델과 추론 예산 설정

   /setup-pstack을 실행한다. 사용 가능한 서브에이전트 모델을 확인한 뒤 예산과 역할별 모델을 선택한다. 확인되지 않은 모델 이름을 그대로 설정하지 않는다.

3. 역할 설정 파일 생성

   설정은 ~/.cursor/rules/pstack-models.mdc에 alwaysApply 규칙으로 저장된다. 역할별 지정은 스킬 기본값을 덮어쓰며 해당 줄을 삭제하면 기본값으로 돌아간다.

4. 새 대화에서 작은 작업 실행

   설정 규칙은 새 세션에 적용된다. /poteto-mode로 완료 조건을 가진 작은 버그나 기능을 맡기고 절차·도구·검증 근거를 확인한다.

5. 앱 검증 수단 연결

   기존 harness나 verify-* 스킬이 없다면 /create-verification-skill로 프로젝트용 실행·검증 절차를 만든다. 생성 결과 자체도 실제 실행으로 증명해야 한다.

코드 작성법보다, 에이전트가 안정적으로 작업할 수 있도록 계약·격리·증거를 준비하는 과정이다.

예시: 파일 가져오기 중복 문제

1. 먼저 같은 실패를 만든다

   중복이 발생한 파일과 재시도 조건을 고정한다. 수정 전 저장 결과의 식별자·행 수·중복 행을 기록한다.

2. 데이터 소유권과 원인을 확인한다

   입력 중복인지, 저장 재시도인지, 동시 실행인지 구분한다. how로 흐름을 추적하고 필요하면 why로 기존 제약을 확인한다.

3. 구조 선택이 필요하면 비교한다

   멱등 키, 저장 경계, 실행 소유권 등 실제 대안을 architect로 검토한다. 서로 다른 후보가 같은 실패 조건을 어떻게 다루는지 비교한다.

4. 수정하고 같은 조건을 다시 실행한다

   작은 테스트로 재현 가능하면 tdd를 적용한다. 저장소를 실제로 읽어 중복이 없는지 확인하고 정상 입력·실패 후 재시도도 검증한다.

5. 별도 리뷰와 근거를 남긴다

   interrogate로 변경 의도와 diff를 검토한다. PR에는 재현 조건, 해결 원인, 실행 결과, 남은 위험을 적는다. 이 사례는 설명을 위한 가상 예시다.

/poteto-mode 가져오기 재시도 시 중복 저장을 수정해줘. 기준 브랜치에서 새 worktree를 사용해. 완료 조건은 같은 파일을 두 번 처리해도 저장 행이 늘지 않고, 실패 후 재시도에서도 누락·중복이 없는 것이다. 정상 처리 결과는 유지해. 실제 DB 읽기 결과를 근거로 제출하고 PR까지만 만들어. 병합과 배포는 하지 마.

빌드 성공은 실행 동작 전체를 증명하지 못한다. 무엇이 바뀌었는지에 맞는 실제 증거를 선택한다.

프로젝트 검증 스킬의 다섯 부분

검증 스킬은 .cursor/skills/verify-<app>/에 생성되며 features/의 기능 지도와 연결된다. 앱이 바뀌면 /maintain-verification-skill이 소스 조사와 실제 전체 실행을 통해 clean, changed, blocked 중 하나로 보고한다. 제품 회귀를 발견해도 문서로 덮거나 제품 코드를 수정하는 절차는 아니다.

시간을 채우게 하는 대신, 정해진 조건을 증명하게 한다. 결정 로그는 아침에 판단을 검토할 수 있는 기록이다.

/poteto-mode 새 worktree에서 모든 호출자를 새 파서로 이전해줘. 완료 조건은 옛 호출자 0개, 모든 파서 fixture 통과, 옛 API 제거다. 커밋과 PR 생성은 허용하지만 병합·배포·데이터 삭제는 하지 마. 결정 로그를 남겨. /loop로 완료 조건을 재확인하고, 정한 시간·실행 예산을 넘거나 해결 불가능한 장애가 생기면 상태와 근거를 남기고 중단해.

/show-me-your-work의 로그는 기본적으로 decisions.tsv 또는 .audit/<task-slug>.tsv에 남긴다. 검토가 필요한 큰 작업은 커밋에 포함할 수 있다. 후속 요약은 다른 모델 계열의 검토를 거쳐 주의할 판단을 제시하도록 설계되어 있다.

설치한 스킬과 실제로 실행 가능한 기능은 다르다. 프로젝트에서 사용할 경로별로 필요한 기능을 확인해야 한다.

병렬 실행은 작업량도 늘린다

arena는 N개의 후보 작성에 심사·합성·재검증이 추가된다. interrogate는 리뷰어 수만큼 같은 diff를 검토한다. swarm은 범위 분담으로 경과 시간을 줄일 수 있지만 총 모델 실행량이 줄어드는 것은 아니다.

고정 가격이나 구독 내 무제한 실행 여부는 이 저장소만으로 확정할 수 없다. small 같은 설정은 추론 노력 목표를 조정하며 결제 한도를 강제하지 않는다. 처음에는 작은 패널과 한 작업으로 실행량·지연·검증 성공률을 관측하는 것이 좋다.

버튼으로 에이전트를 호출하는 별도 경로

make-bot-ui는 브라우저의 버튼 요청을 로컬 서버가 받아 Grok Bot webhook으로 전달하도록 안내한다. 송신 키는 브라우저나 채팅에 노출하지 않고 서버에 보관한다. webhook 입력은 신뢰할 수 없는 외부 데이터로 취급한다. 이 경로는 pstack의 모든 작업을 자동으로 대시보드화하는 공통 API가 아니다.

모드가 상황별로 호출하는 도구와 직접 요청할 만한 도구를 묶었다.

자기 팀의 규칙으로 바꾸는 순서

1. 실제 작업에서 반복되는 선택을 찾는다

   automate-me는 작업 이력의 응답·위임·검증·코드·과정 선호를 찾고 확인한 뒤 개인 모드를 작성한다. 한 번의 불만을 영구 규칙으로 만들지 않는다.

2. 교훈은 승인된 변경으로 남긴다

   reflect는 병렬 검토 뒤 Accepted, Rejected, Backlog로 제안을 정리하고 스킬 수정 전에 승인을 기다리는 절차다.

3. 지시 변경도 비교 평가한다

   Eval 플레이북은 같은 과제를 비교하되 작업자가 평가받고 있다는 사실과 다른 후보를 모르게 한다. 산출물을 중립 라벨로 심사하고 지시 파일을 실제로 읽었는지도 확인한다.

4. 검증 가능한 구조로 정착시킨다

   같은 지시를 반복한다면 테스트·린트·검증 도구로 옮긴다. 스킬 변경은 기능 변경과 별도 PR로 검토하여 영향과 효과를 드러낸다.

2026년 9월 30일 확인한 cursor/plugins의 pstack 자료를 바탕으로 정리했다. 원문 정의, 해석, 실무 권고, 가상 예시를 본문에서 구분했다.

이 페이지는 원문을 바탕으로 작성한 한국어 해설이다. 저장소는 계속 변경될 수 있다. 설치·모델 이름·실행 권한은 도입 시 현재 원문과 실제 환경에서 다시 확인해야 한다. pstack을 설치하거나 작업을 실행하는 UI가 아니다.