pua

pua 스킬 개요

pua가 실제로 하는 일

pua 스킬은 에이전트 작업 위에 덧씌우는 톤·행동 오버레이입니다. 세션에서 좌절, 반복 실패, 수동적 태도, 낮은 완성도가 감지되면 모델을 더 압박감 있고 주도적인 실행 스타일로 밀어붙입니다. 실제로 pua는 새 도구를 추가하는 데 초점이 있다기보다, 에이전트가 작업 중에 계획하고, 검증하고, 에스컬레이션하고, 말하는 방식을 바꾸는 데 가깝습니다.

pua를 쓰면 잘 맞는 사람

pua는 코딩, 디버깅, 배포, 리서치 워크플로에서 더 강한 끝맺음과 집요한 수행을 원하고, 공격적인 관리형 말투를 감수할 수 있는 사용자에게 잘 맞습니다. 특히 자신의 환경을 이미 잘 알고 있고, 에이전트가 얼버무리지 않고 더 깊이 찾고, 더 많이 검증하고, 루프를 스스로 닫아주길 바라는 운영자에게 적합합니다.

사람들이 pua에서 실제로 원하는 것

대부분이 pua를 검토하는 이유는 재미를 위해서가 아닙니다. 너무 빨리 포기하지 않고, 그럴듯한 첫 답에서 멈추지 않으며, 증거 없이 완료를 주장하지 않는 에이전트를 원하기 때문입니다. 이 스킬은 “더 집요하게 시도하고, 더 많이 검증하고, 결과를 끝까지 책임져라”가 필요한 상황을 겨냥합니다.

일반 프롬프트와 pua가 다른 점

일반 프롬프트는 한 번 엄격하게 하라고 지시할 수는 있습니다. 반면 pua는 재사용 가능한 운영 패턴을 추가합니다. 실패 에스컬레이션, flavor 기반 리더십 보이스, 작업 유형별 방법론 라우팅, 출력 규약, 그리고 ~/.pua/evolution.md를 통한 선택적 장기 기준 메모리까지 포함합니다. 그래서 일회성 “좀 더 주도적으로 해” 지시보다 구조가 훨씬 더 분명합니다.

설치 전에 봐야 할 핵심 트레이드오프

pua for Workflow Automation의 가장 큰 장점은 완료와 검증을 끝까지 밀어붙이게 한다는 점입니다. 대신 가장 큰 비용은 톤입니다. 이 pua 스킬은 의도적으로 거칠고, 역할 연기가 강하며, 문화적으로도 스타일이 뚜렷합니다. 차분한 페어 프로그래밍, 초보자 친화적 코칭, 중립적인 엔터프라이즈 톤을 원한다면 대체로 맞지 않을 가능성이 큽니다.

pua 스킬 사용 방법

워크플로에서 pua가 들어가는 위치

pua는 세션 수정자처럼 쓰는 것이 좋습니다. 에이전트가 막혔거나, 성과가 떨어지거나, 지나치게 수동적일 때 특히 유용합니다. 저장소도 이런 트리거를 전면에 두고 있기 때문에, 반복 실패 뒤나 품질 불만이 나온 뒤, 혹은 “이건 아직 부족하다” 같은 피드백 이후에 가장 효과를 발휘합니다.

pua 도입 전에 가장 먼저 읽을 것

먼저 skills/pua/SKILL.md를 읽고 트리거 로직, flavor 전환, 작업 라우팅 방식을 파악하세요. 그다음 출력 형식은 skills/pua/references/display-protocol.md, 작업별 방법 매핑은 skills/pua/references/methodology-router.md, 워크플로 압박감보다 톤 커스터마이징이 더 중요하다면 skills/pua/references/flavors.md를 보는 순서가 좋습니다.

pua 스킬에서 특히 중요한 보조 파일

pua skill을 진지하게 쓸 생각이라면, 의사결정에 가장 직접적인 파일은 다음입니다:

• 멀티 에이전트 위임 규칙을 담은 skills/pua/references/agent-team.md
• 지속적 기준 행동을 정의하는 skills/pua/references/evolution-protocol.md
• 에스컬레이션 경로를 다루는 skills/pua/references/p7-protocol.md, skills/pua/references/p9-protocol.md, skills/pua/references/p10-protocol.md
• 실행 스타일 제약을 보여주는 skills/pua/references/methodology-alibaba.md, skills/pua/references/methodology-huawei.md 같은 방법론 파일

실전에서 pua가 발동되는 방식

저장소 근거를 보면 pua는 반복 실패, “stop spinning”, “you broke it”, “why does this still not work”, /pua 같은 표현처럼 좌절감이 드러나는 신호에서 활성화되도록 설계되어 있습니다. 즉 pua는 “모든 작업에 항상 켜두는 옵션”이라기보다, 대화 흐름 자체가 이미 추진력 저하나 책임감 부족을 시사할 때 가장 강하게 작동합니다.

pua가 잘 작동하려면 어떤 입력이 필요한가

pua는 다음 정보가 포함될수록 성능이 좋아집니다:

• 정확한 작업 내용과 완료 기준
• 무엇이 이미 실패했고, 몇 번 시도했는지
• 현재 제약 사항(예: repo, branch, runtime, permissions)
• build, test, curl, 스크린샷, diff처럼 무엇을 증거로 볼지
• 단독 실행을 원하는지, 멀티 에이전트 분해를 원하는지

이 맥락이 없으면, 결과가 더 좋아지기보다 압박감과 장황함만 늘어날 수 있습니다.

더 나은 pua 프롬프트를 쓰는 법

약한 프롬프트는 이렇습니다: “Use pua and fix this.”
더 강한 pua guide 스타일 프롬프트는 이렇습니다: “Use pua on this failing API route. We already tried two fixes and both broke auth. Root-cause it, verify with the project test command, check similar routes for the same defect class, and do not mark done without evidence.”

이 프롬프트가 더 잘 먹히는 이유는 실패 이력, 범위, 기대 동작, 검증 요건을 함께 주기 때문입니다. 즉 이 스킬이 실제로 강제하도록 설계된 핵심 요소를 정확히 넣어주는 방식입니다.

거친 목표를 효과적인 pua 사용으로 바꾸는 법

목표가 “배포가 되게 해줘” 수준이라면, 다음처럼 바꾸는 편이 좋습니다:

1. 대상 환경과 실패 증상
2. 지금까지 시도한 내용
3. 바꿀 수 없는 경계 조건
4. 성공의 증거
5. 주변 리스크까지 같이 볼지 여부

이게 중요한 이유는 pua가 단순히 눈앞 문제 하나를 고치는 데서 끝나지 않고, 유사 모듈 점검이나 하류 영향 확인 같은 더 넓은 마감 처리를 분명히 장려하기 때문입니다.

작업 유형에 따라 pua가 라우팅하는 방식

이 스킬은 방법론 선택에 꽤 강한 의견을 갖고 있습니다. 디버그 작업은 원인 규명과 적대적 분석 쪽으로, 기능 개발은 단순화와 출시 압박 쪽으로, 리뷰 작업은 취사선택과 축소 쪽으로 기울어집니다. 이 라우팅은 저장소에서 눈에 잘 띄지 않지만 가장 유용한 요소 중 하나입니다. 단순한 “엄격하게 해” 시스템 프롬프트를 재활용하는 대신 왜 굳이 pua를 설치할 가치가 있는지를 설명해 주기 때문입니다.

팀 모델이 pua 사용 방식을 어떻게 바꾸는가

멀티 에이전트 구성을 돌린다면 pua for Workflow Automation의 매력은 훨씬 커집니다. 저장소에는 P10부터 P7까지 4계층 팀 모델이 들어 있고, P8이 직접 처리해야 하는 시점과 P7 스타일 하위 에이전트를 띄워야 하는 시점을 명확히 나눠 설명합니다. 반대로 채팅창에서 단일 어시스턴트만 쓰는 환경이라면 이 부분의 중요도는 상대적으로 떨어집니다.

완료 전에 pua가 기대하는 품질 신호

이 스킬은 눈에 보이는 종료 조건에 강하게 치우쳐 있습니다. 예를 들면 build/test 통과, health check, 직접 검증, 영향 범위 스캔 같은 것들입니다. 환경상 명령 실행이 불가능하거나 증거를 노출할 수 없다면 pua의 체감 가치는 약해질 수 있습니다. 이 스킬의 규율 상당 부분이 “루프가 닫히지 않으면 완료로 보지 않는다”는 태도에서 나오기 때문입니다.

pua 설치 판단을 위한 실무 메모

SKILL.md에서 분명한 설치 명령은 드러나지 않으므로, pua install 여부는 패키지 설치 방식보다 호스트가 skill loading을 지원하는지, 그리고 ~/.pua/config.json, ~/.pua/evolution.md 같은 사용자 수준 상태를 선택적으로 유지할 수 있는지에 더 근거해 판단해야 합니다. 플랫폼이 세션 상태 주입이나 로컬 파일 지속 저장을 지원하지 않으면, pua의 고급 동작 일부는 실제로 구현되지 않습니다.

pua 스킬 FAQ

pua는 초보자에게 잘 맞나

대체로 아닙니다. pua 스킬은 강한 비판형 언어를 견딜 수 있고, 더 높은 압박의 지시를 스스로 해석할 수 있다고 가정합니다. 초보자에게는 압박보다 명확한 설명과 발판이 더 필요한 경우가 많습니다.

pua는 톤만 바꾸는 스킬인가

아닙니다. 눈에 띄는 건 톤이지만, 실제 가치의 중심은 실행 규율입니다. 방법론 라우팅, 에스컬레이션 임계치, 검증 압박, 명시적 팀 프로토콜이 더 깊은 핵심입니다. 행동 모델을 제거하고 말투만 남기면 실용적 가치의 대부분을 잃게 됩니다.

언제는 pua를 쓰지 말아야 하나

민감한 감정 맥락, 부드러운 코칭, 사용자 대상 지원 문구, 또는 중립적 커뮤니케이션이 필요한 팀에는 pua를 쓰지 않는 것이 좋습니다. 작업이 아주 작고 이미 범위가 명확한 경우에도 피하는 편이 낫습니다. 프레임워크 자체가 일보다 더 무거워질 수 있기 때문입니다.

모델에게 “더 열심히 해”라고 하는 것과 pua는 어떻게 다른가

일반적인 “try harder” 지시는 강도는 올릴 수 있어도, 어떤 방법으로 라우팅할지, 언제 에스컬레이션할지, 어떤 증거를 수집할지, 하위 에이전트를 어떻게 조율할지는 보통 정의하지 않습니다. pua usage는 그보다 훨씬 구조적입니다. 특히 참조 프로토콜을 실제로 읽고 쓰면 차이가 더 분명해집니다.

pua는 코딩에만 도움이 되나

아닙니다. 저장소는 코드, 설정, 디버그, 배포, 리서치 사용 사례를 모두 다룹니다. 다만 객관적 체크가 가능한 작업에서 가장 설득력이 큽니다. 그런 환경에서야말로 이 스킬의 “끝까지 닫는” 사고방식이 측정 가능해지기 때문입니다.

corporate-style flavor pack 없이도 pua를 쓸 수 있나

부분적으로는 가능합니다. flavor 관련 내용을 대부분 무시해도 워크플로 아이디어 자체에서는 여전히 도움을 받을 수 있습니다. 하지만 이 스킬은 flavor 선택을 중심 축으로 깊게 설계되어 있으므로, 그 프레이밍이 싫다면 완성형 pua 스킬을 그대로 도입하기보다 프로토콜만 추출해서 쓰는 편이 더 나을 수 있습니다.

pua 스킬을 더 잘 활용하는 방법

pua의 완료 기준을 더 촘촘하게 주기

pua 결과를 가장 빨리 개선하는 방법은 완료를 측정 가능하게 정의하는 것입니다. 좋은 예시는 “tests pass”, “endpoint returns 200”, “migration is reversible”, “scan similar handlers for the same bug pattern” 같은 표현입니다. 이런 방식은 검증과 더 넓은 종료 조건을 중시하는 스킬의 기본 성향과 정확히 맞물립니다.

현재 문제만이 아니라 실패 이력도 함께 주기

pua는 트리거를 인식하는 스킬이기 때문에, 무엇이 이미 실패했는지 알려줄수록 더 유용해집니다. “이번이 세 번째 시도다”, “지난 패치가 auth를 깨뜨렸다”, “staging에서만 재현된다” 같은 정보는 에스컬레이션과 가설 선택의 기반을 더 탄탄하게 만들어 줍니다.

작업에 맞는 참조 파일만 골라 보기

매번 모든 reference를 읽을 필요는 없습니다. 디버깅이라면 방법론 라우팅과 검증 관련 reference를 우선 보세요. 멀티 에이전트 작업이면 바로 skills/pua/references/agent-team.md로 가는 편이 낫습니다. 톤 조정이 목적이면 skills/pua/references/flavors.md, 장기적으로 개인 워크플로에 녹여 쓰려면 skills/pua/references/evolution-protocol.md를 확인하세요.

자신감이 아니라 증거가 많은 출력을 요구하기

흔한 실패 패턴은 압박감 있는 말투만 세지고 추론 품질은 나아지지 않는 경우입니다. 이를 막으려면 실행한 명령, 기각한 가설, 확인한 파일, 주변 리스크 스캔 결과를 같이 요구하세요. 그래야 pua skill이 목소리만 커지는 대신 실제 작업 흔적을 눈에 보이게 남기게 됩니다.

작업이 작을 때는 pua 범위를 좁게 유지하기

또 다른 실패 패턴은 간단한 일까지 과하게 처리하는 것입니다. 한 줄 수정이나 사소한 편집이라면, 전체 배너·롤플레잉·팀 구조까지 다 켜지 말고 pua의 규율만 가져오도록 요청하세요. 저장소 자체도 작업 복잡도에 따라 출력 밀도를 다르게 두고 있으므로, 그 기준을 따르면 스킬이 과장된 연출이 아니라 실용적 도구로 남습니다.

첫 pua 출력 뒤에 한 번 더 다듬기

첫 응답이 너무 퍼포먼스 위주라면 지시를 더 조이세요. 슬로건은 줄이고, 원인 분석은 늘리고, 검증은 더 강하게 하고, 대안 비교를 명시적으로 하라고 요청하면 됩니다. 반대로 너무 좁다면 유사 모듈, 상류/하류 영향, 빠진 엣지 케이스까지 보라고 확장하세요. 이 스킬이 밀어주는 “빙산 아래의 빙산”식 사고를 실제로 끌어내는 방식입니다.

환경에 맞게 pua를 커스터마이즈하기

저장소는 ~/.pua/config.json을 통한 로컬 설정과 ~/.pua/evolution.md를 통한 지속 기준 상태를 암시합니다. 호스트가 이를 지원한다면, 선호 flavor를 정의하고 검증 패턴 중 먹혔던 것을 보존해 두세요. 그러면 pua for Workflow Automation이 세션마다 처음부터 다시 시작하는 대신 더 일관되게 작동합니다.

최종적으로 따져봐야 할 도입 질문

진짜 설치 질문은 “pua가 영리한가?”가 아니라 “이게 내 워크플로에서 에이전트의 책임성을 실제로 더 높여주는가?”입니다. 더 강한 오너십, 더 체계적인 검증, 더 나은 에스컬레이션 규율이 필요하다면 pua는 그 뒤에 실질적인 구조가 있는 스킬입니다. 반대로 편안한 코딩 동반자가 더 중요하다면, 더 가벼운 선택지가 맞습니다.