lee-chance/pstack

코드를 작성하기 전에 타입, 시그니처, 모듈 구조를 스케치한 다음 구현이 채워지는 동안 루프에 참여하세요. /architect, 'architect this', 'design this'에 사용하거나, 코드로 바로 뛰어드는 것이 잘못된 형태로 고착될 수 있는 비자명한 작업에 사용하세요.

동일한 작업에 N개의 병렬 후보를 생성하고, 베이스를 선택하고, 패자의 가장 강한 부분을 그것에 접목하세요. /arena, 'arena this', 'throw it in the arena'에 사용하거나, 비자명한 아티팩트에 대한 한 번의 시도가 잘못된 형태로 고착될 때 사용하세요.

"automate me", "create/update/refresh my -mode skill", "내 선호도나 작업 스타일을 스킬로 전환/캡처"에 사용하거나, 에이전트가 사용자의 작업 방식을 따르도록 하고 싶을 때 사용하세요. create-skill + unslop을 통해 개인 -mode 스킬을 작성하거나 수정하며, 선택적으로 최근 트랜스크립트에서 새로운 증거를 가져옵니다.

보고하거나 조치하기 전에 성능 측정 (제한자, 튜닝, 한계, 오류, 반복성, 관련성, 작업 발생 여부)을 검증하세요. 벤치마크를 실행하거나 측정한 속도 향상 또는 회귀를 보고할 때 사용하세요.

변경 사항이 배포되기 전에 diff를 넘어 다른 곳에서 무엇을 깨뜨릴 수 있는지 찾고, 작성하는 대신 실제 코드를 실행하여 안전한 이유의 하나의 사실을 증명하세요. 'blast radius of X', '이것이 무엇을 깨뜨릴 수 있는가', 또는 아직 신뢰하지 않는 작은 diff를 검토할 때 사용하세요.

마지막 메시지를 전문 용어 없이 평범한 인간 언어로 다시 진술하세요.

이 저장소에서 에이전트가 계속 반복하는 실수를 찾고 각각을 불가능하게 만드세요. 아키텍처를 먼저 시도하고, 그 다음 타입, 그 다음 수정 사항을 명명하는 오류가 있는 린트, 그 다음 테스트를 시도하고, 마지막으로 문서를 작성하세요. 각 검사가 실제 과거 실수에 대해 실패함을 증명하세요. 운영자가 수정할 때마다 이것을 반복하세요. /correct에 사용하세요.

버그 비용이 가장 크고 테스트가 가장 적게 도달하는 곳에서 코드를 형식적으로 검증하는 프로젝트 로컬 스킬을 생성하세요. 어떤 언어든, 어떤 검증 도구든 적합한 것으로. /create-formal-verification-skill, "model-check this race", "prove this invariant", 또는 동시성, 재시도, 상태 머신, 파서, 또는 unsafe 코드가 테스트보다 더 많이 필요할 때 사용하세요.

사용자가 하는 방식으로 앱을 구동하는 프로젝트 로컬 검증 스킬을 생성하세요 — 어떤 언어, 프레임워크 또는 플랫폼이든. /create-verification-skill, "make a control skill for this repo", 또는 프로젝트에 UI/CLI/서비스 동작을 증명하는 스크립트 방법이 없을 때 사용하세요.

더 좁은 것이 맞지 않을 때 감사 가능한 플레이북을 설계하세요: 대규모 마이그레이션, 야심 찬 다중 부분 변경, 또는 인간이 떠난 후 검토하는 작업. 작업에 맞게 엄격성을 조정하고, 가설 루프를 실행하고, 결정을 로깅합니다. /figure-it-out 또는 'figure it out'에 사용하세요.

"how does X work", 무언가를 변경하기 전의 코드 워크스루, 배치 / 소유권 / 계층 질문 ("이것이 어디에 살아야 하는가", "어떤 패키지가 이것을 소유하는가", "이것이 올바른 레이어인가")에 사용하세요. 하위 시스템 아키텍처, 런타임 흐름, 온보딩 정신 모델을 설명합니다. 동기에는 why를 사용하세요.

사용자의 목표가 무엇이고 어떤 문제를 해결하려고 하는지 당신 자신의 말로 다시 진술하세요. /in-your-own-words에 사용하세요.

"interrogate", "adversarial review", "multi-model review", "challenge this", "stress test this code", "find blind spots", 또는 "tear this apart"에 사용하세요. 적대자는 변경이나 설계를 깨뜨리려고 시도하며, 실행으로 증명된 발견 사항만 살아남습니다.

사용자의 마지막 메시지 이후 이 채팅에서 변경된 내용을 평범한 단어와 작은 비주얼로 따라잡도록 하세요. 응답만으로 결정하는 데 필요한 것과 함께 그들을 기다리는 모든 항목을 나열하세요. /ketchup에 사용하세요.

/ketchup처럼 사용자를 따라잡도록 하되, 일어난 일에 대한 슬라이드의 짧은 자막 비디오와 그 아래 텍스트로 대기 중인 호출을 보여주세요. /ketchup-video에 사용하세요.

코드가 변경된 후 프로젝트의 형식 검증을 코드와 다시 정렬하세요: 검증된 코드를 터치한 커밋을 찾고, 모델, 하니스 또는 속성을 지금 코드를 설명하도록 업데이트하고, 다시 실행하고, 각 실패가 검증의 드리프트인지 코드의 버그인지 말하세요. /maintain-formal-verification-skill, "is the model still true to the code", 또는 검증된 코드를 터치했지만 다시 확인하지 않은 병합 및 리팩토링 후에 사용하세요.

프로젝트의 검증 스킬과 기능 맵을 정직하게 유지하는 주기적 패스: 기능당 병렬 소스 리더, 모든 기능을 구동하는 하나의 라이브 세션, 최대 하나의 증명된 수정 PR. /maintain-verification-skill 또는 "audit the verify skill"에 사용하세요.

웹훅을 통해 Grok Bot을 깨워야 하는 커스텀 UI (페이지, 대시보드, 버튼)를 빌드하거나, 사용자가 웹훅 발신자 키를 제공해야 하거나, Tailscale에서 해당 UI를 노출할 때 사용하세요.

Comment Sicko를 생성하고, 수락된 발견 사항을 수정하고, 주장된 제약 조건에 대한 인코딩을 제공하세요.

사용자를 pstack 설정, /poteto-mode, 작업에 대한 스킬, playbook 또는 원칙 선택으로 안내합니다. 질문과 함께 /poteto-help를 입력하세요.

간결하고 상세한 응답, 신중한 하위 에이전트 사용, 불필요한 표현 제거, 단순한 코드, 검증된 작업을 위한 poteto의 에이전트 스타일. poteto, /poteto-mode 또는 이 스타일로 작업해 달라는 요청에 사용.

하나의 전제를 공유하는 둘 이상의 수정이 동일한 게이트에서 실패했을 때 적용. 전제를 기록하고 그것을 가정하는 또 다른 수정을 작성하기 전에 직접 테스트.

검증, 에러 처리 또는 프레임워크 어댑터를 연결할 때 적용. 시스템 경계(CLI, config, network, external APIs)에 가드를 집중; 내부 타입을 신뢰하고 비즈니스 로직을 순수 함수로 유지.

대량 작업뿐만 아니라 중요하지 않은 작업에도 적용: 편집, 마이그레이션, 분석, 체크. 손으로 작업하는 대신 그것을 수행하거나 증명하는 도구를 빌드 (codemod, script, generator, 또는 서브에이전트가 따르는 스킬). 도구는 리뷰어가 재실행할 수 있는 아티팩트.

동일한 지시사항을 두 번째로 작성하거나 반복되는 수정을 발견할 때 적용. 더 많은 텍스트 대신 lint, 메타데이터 플래그, 런타임 체크 또는 스크립트로 규칙을 인코딩.

코드베이스에 선례가 없는 새로운 UI 인터랙션이나 아키텍처 결정에 직면할 때 적용. 커밋하기 전에 2-3개의 경쟁 프로토타입을 만들고 나란히 비교.

제품, UX 또는 기능 범위 트레이드오프가 나올 때 적용. 구현 편의성보다 사용자 기쁨을 선택; 더 많은 거친 것보다 더 적은 세련된 기능을 배포.

측정하기 전에, 그리고 측정한 숫자를 신뢰, 보고 또는 조치하기 전에 적용: 속도 향상, 회귀, 처리량, 지연 시간 또는 eval 결과. 그것을 제한하는 것을 찾고, 생각하는 작업이 아닌 다른 것을 측정했다는 것을 배제.

디버깅할 때 적용. 각 증상을 시스템이 처음 잘못된 곳까지 추적하고 거기서 수정. 가드는 처리하는 상태가 합법적일 때만 수정.

로직 작성 전에 적용: 핵심 타입과 데이터 구조 선택, 스캐폴드 대 기능 작업 순서화, 동시 액터가 무엇을 공유하는지 질문. 다운스트림 코드가 명확해지도록 데이터 구조를 올바르게 함.

컨텍스트가 채워질 때 적용: 큰 출력, 긴 파일, 반복된 읽기, 팬아웃 계획. 대량을 서브에이전트로 라우팅; 원시 페이로드가 아니라 요약을 메인 스레드에 유지.

리팩토링, diff 크기 평가, 추상화, 레이어 또는 신호 스레딩 추가 유혹이 있을 때 적용. 삭제와 문제를 해결하는 가장 작은 변경을 선호.

충돌, 재시작, 재시도 중에 실행되는 명령, 라이프사이클 단계 또는 처리 루프를 설계할 때 적용. 부분 이전 실행에 관계없이 동일한 최종 상태로 수렴.

레거시 API를 삭제하기 전에 모든 호출자를 마이그레이션하기

추적하기 어려운 코드를 검토하거나 형성할 때 적용. 질문과 답변 사이의 레이어와 독자의 머릿속 숨겨진 상태를 세고; 하나의 호출자 래퍼를 접고 가변 범위를 줄임.

상태 있는 로직을 작성하거나, 코드가 많이 분기하거나 파일 전체에 걸쳐 형태 가정을 반복할 때 적용.

되돌릴 수 있는 작업에 대해 'X를 해야 하나요?'라고 질문하고 싶을 때 적용.

명시적 단계 경계를 가진 계획된 재작성 및 마이그레이션 중에 적용. 대상 아키텍처로 수렴; 일회용 호환성 코드로 부드러운 중간 상태를 보존하지 마세요.

작업 완료 후, 완료를 선언하기 전에 적용. 프록시, 자체 보고 또는 '컴파일됨'이 아니라 실제 아티팩트(기능 실행, 실제 값 읽기, diff 검사)에 대해 검증.

기존 설계에 새 요구사항을 통합할 때 적용.

공유 상태를 직렬화하기 전에 분리하기

검증 가능한 단위로 시퀀싱하기

추가, 리팩토링 또는 재작성 순서를 정할 때 적용. 먼저 데드 코드, 중복 검증기, 스텁 참조를 제거한 다음, 더 단순한 기반 위에 빌드.

구현이 아닌 동작을 테스트하기

타입을 설계하거나, 함수 시그니처를 검토하거나, 정적 타입 언어로 코드를 작성할 때 적용. 불법 상태를 표현 불가능하게 만들고, 의미론적 프리미티브를 브랜드하고, 경계에서 외부 데이터를 파싱하고, 변형을 소진하고, 권위있는 스키마에서 파생.

자신의 채팅 기록, 라이브 상태 및 공유 기록 (사용자 보고서, 이전 수정, 인시던트)에서 최근 작업 컨텍스트를 재구성한 다음 지금 상황과 다음에 해야 할 일에 대한 간결한 현재 상태 브리프를 반환하세요. 'recall my work on X', 'catch me up', 'what have I been working on', 'where did I leave off', 작업 시작 또는 재개 전에 사용하세요.

활성 트랜스크립트에 대해 세 개의 병렬 리뷰 서브에이전트를 생성하고, 학습을 표면화하고, 각각을 기존 스킬에 대한 구체적인 편집으로 라우팅하세요. 사용자가 reflect라고 말할 때 사용하세요.

역할당 pstack이 사용하는 모델과 어떤 추론 예산으로 구성하세요. 사용 가능한 모델을 감지하고 스킬 기본값을 재정의하는 항상 적용되는 규칙을 작성합니다. /setup-pstack, "configure pstack models", "pstack budget", 또는 pstack의 모델 선택 변경에 사용하세요.

작업을 더 크게가 아니라 더 깊게 만든 다음 프롬프트를 다시 작성하세요. /sharpen에 사용하세요.

장기 실행 또는 무인 작업에 대한 검토 가능한 결정 추적 유지: 결정당 하나의 행이 있는 TSV 로그 (무엇, 왜, 증거, 결과). 기본적으로 로컬; 리뷰어가 결과를 신뢰하기 위해 추적이 필요할 때 커밋하세요. /show-me-your-work, 자율 또는 다단계 실행, 또는 인간이 떠난 후 검토하는 작업에 사용하세요.

제품 플로우, 프로토콜 또는 서비스와 같이 상태 간을 이동하는 시스템의 TLA+ 모델을 확인하고 Mermaid statechart로 그립니다. 보고서는 규칙을 위반하는 각 상태로 가는 최단 경로를 제공합니다. /statechart, 또는 버그를 상태를 통한 경로로 보여주기 위해 사용하세요.

N개의 병렬 워커를 팬 아웃하고, 드레인하고, 하나의 보고서를 반환하세요. /swarm, 'swarm this', 또는 병렬 커버리지, 경주, gauntlet 및 탐색에 사용하세요.

사용자가 명시적으로 TDD, 실패하는 테스트 또는 회귀 테스트를 요청할 때만 사용하거나, 버그에 명백한 저렴한 로컬 테스트 대상이 있을 때 사용하세요. 테스트 경로가 불명확하거나, 비싸거나, 통합이 많거나, 요청되지 않은 경우 건너뛰세요.

사람이 실제로 이해할 수 있도록 작업 본문을 평범하게 설명하세요. how와 why 스킬을 실행하고 그들이 찾은 것을 하나의 명확한 설명으로 엮습니다. 'teach me this', 'help me really understand X', 'explain this change or subsystem to me'에 사용하세요.

계층화된 기술 문서 표준: Diátaxis 구조, Google 개발자 스타일 문장, STE 지침 규칙, Global English 구문. /technical-writing 또는 문서, RFC, readme, PR 설명 또는 커밋 메시지 작성 또는 검토 시 사용하세요.

TypeScript 모범 사례. 모든 .ts 또는 .tsx 파일을 읽거나 편집할 때 사용하세요.

모든 쓰기에서 AI 징후를 자릅니다.

'why does X work this way', 'why we picked Y', 설계 근거, 회귀, 사후 분석, 또는 데이터 지원 임계값에 사용하세요. 사용 가능한 MCP를 발견하고 각 증거 카테고리 (소스 제어, 이슈 트래커, 장문 문서, 실시간 채팅, 인프라 관찰 가능성, 오류 추적, 제품 분석 웨어하우스)를 병렬로 쿼리한 다음 인용된 결정과 트레이드오프에 대한 읽기를 반환합니다. 런타임 동작에는 how를 사용하세요.