p7

p7 스킬 개요

p7는 무엇에 쓰는 스킬인가

p7 스킬은 코드 작업을 위한 시니어 엔지니어형 실행 모드입니다. 범위가 정해진 구현 과제를 받으면 먼저 해결 방안을 설계하고, 영향도를 검토한 뒤, 코드를 작성하고, 마지막에 짧은 자기 점검으로 마무리하도록 설계되어 있습니다. 쉽게 말해 p7는 Code Generation이 필요하지만, 단순히 “코드만 바로 써줘” 같은 응답이 아니라 더 절차적이고 통제된 빌드 순서를 원할 때 적합합니다.

누가 p7를 써야 하나

p7는 이미 과제 오너, 아키텍처 방향, 혹은 상위 에이전트가 정해져 있고, 명확히 정의된 하위 작업을 안정적으로 수행할 실행자가 필요한 사용자에게 잘 맞습니다. 특히 멀티 에이전트 워크플로를 쓰고 있거나, 코드 수정 전에 명시적인 계획을 포함한 code generation을 원할 때 유용합니다.

p7가 실제로 해결하는 일

p7를 검토하는 대부분의 사용자는 구현 과정에서 추측을 줄이고 싶어 합니다. 핵심 가치는 단순한 코드 산출물이 아닙니다. p7가 맡는 일은 이렇습니다. 범위가 제한된 요청을 실행 가능한 접근안으로 바꾸고, 예상 영향을 따져본 다음, 구현하고, 마지막으로 짧은 자체 검증으로 결과를 압박 테스트하듯 점검하는 것입니다.

일반적인 코딩 프롬프트와 p7의 차이

p7의 가장 큰 차별점은 워크플로 구조입니다. p7는 범용 자율 아키텍트로 소개되지 않습니다. P8 감독 하에서 동작하는 실행 역할이며, 솔루션 주도형 패턴과 정해진 완료 형식을 따릅니다. 그래서 일반적인 “이 기능 만들어줘” 프롬프트보다 더 구조적이지만, 최상위 계획 에이전트보다는 범위가 좁습니다.

저장소가 실제로 제공하는 것

저장소에서 확인되는 근거는 많지 않지만 핵심은 분명합니다. SKILL.md가 역할, 트리거 문구, 출력 기대사항을 정의하고, 외부 프로토콜 파일을 참조합니다. 설치 여부를 판단하는 관점에서 보면 p7는 빠르게 이해하기 쉽지만, 일부 운영 세부사항은 더 넓은 /pua 시스템과 참조된 프로토콜에 의존합니다.

p7가 잘 맞는 경우와 안 맞는 경우 한눈에 보기

다음 상황이면 p7를 쓰는 편이 좋습니다:

• 구현과 reasoning을 고정된 순서로 진행하고 싶을 때
• 작업을 하위 과제로 위임할 수 있을 때
• 코드 변경 전에 영향 분석을 중요하게 볼 때

다음 상황이면 p7는 건너뛰는 편이 낫습니다:

• 먼저 제품 범위 정의나 아키텍처 오너십이 필요한 경우
• 폭넓은 탐색형 브레인스토밍이 필요한 경우
• 하위 작업을 명확히 정의할 만큼 컨텍스트가 충분하지 않은 경우

p7 스킬 사용 방법

p7 스킬 설치하기

실용적인 설치 경로는 다음과 같습니다:

npx skills add tanweai/pua --skill p7

설치 후에는 환경이 저장소 구조를 그대로 반영한다면 skills/p7/SKILL.md를 열어보고, 아니라면 GitHub 저장소의 skills/p7/SKILL.md 원본 파일을 직접 확인하세요.

먼저 읽어야 할 파일

p7를 볼 때 가장 효율적인 읽기 순서는 다음과 같습니다:

1. skills/p7/SKILL.md
2. 환경에 있다면 저장소 루트 수준의 /pua core skill
3. 설치 후 로컬에 존재한다면 references/p7-protocol.md

왜 중요하냐면, SKILL.md는 짧고 핵심 동작 일부를 프로토콜과 /pua core 규칙에 위임하기 때문입니다. 맨 위 파일만 훑어보면 중요한 실행 제약을 놓칠 수 있습니다.

실전에서 p7는 어떻게 트리거되나

소스에는 사용자가 P7模式 또는 方案驱动 같은 문구를 말할 때, 혹은 P8이 하위 작업 실행자로 p7를 호출할 때 사용된다고 명시되어 있습니다. 실전에서는 p7 모드를 이름으로 지정하고, 열려 있는 전략 문제보다 범위가 한정된 구현 과제를 주는 방식으로 호출하는 것이 맞습니다.

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

p7는 요청에 다음 정보가 들어 있을 때 가장 잘 작동합니다:

• 대상 저장소 또는 코드 영역
• 정확한 기능 추가, 버그 수정, 리팩터링 목표
• 언어, 프레임워크, 스타일, 금지 구역 같은 제약
• 기대하는 출력 형식
• 영향 분석 중 확인해야 할 위험 요소

이 정보가 빠져도 p7가 응답은 할 수 있지만, “솔루션 주도형” 단계가 지나치게 일반론적으로 흘러가 유용성이 떨어집니다.

거친 목표를 강한 p7 프롬프트로 바꾸기

약한 입력:

• “Use p7 to improve auth.”

더 강한 입력:

• “Use p7 for Code Generation on the login flow. In a Next.js app, add refresh-token rotation for existing JWT auth. Do not change database schema unless necessary. First propose the implementation plan and impact analysis, then implement server and client changes, then finish with a 3-question self-review.”

두 번째 버전이 p7 활용에 더 좋은 이유는 범위, 기술 스택, 제약, 출력 순서를 함께 제공하기 때문입니다.

실무형 p7 워크플로

추천할 만한 운영 순서는 다음과 같습니다:

1. 하위 작업 범위를 좁게 정의한다
2. 먼저 구현 계획을 요청한다
3. 영향 분석에서 위험한 가정을 검토한다
4. 범위를 확정하거나 조정한다
5. p7에 코드 생성을 맡긴다
6. 마지막 자기 점검에서 누락, 회귀, 미해결 질문을 확인한다

이 방식이 처음부터 바로 코드를 요청하는 것보다 p7 스킬의 본래 가치와 더 잘 맞습니다.

기대할 수 있는 출력 패턴

저장소 설명에 따르면 p7는 다음을 생성합니다:

• implementation plan
• code
• 3-question self-review
• [P7-COMPLETION] 형식으로 전달

툴링이 구조화된 에이전트 핸드오프를 지원한다면 이 완료 마커를 유지하세요. 지원하지 않더라도 동일한 콘텐츠 블록을 요청해 두는 편이 p7가 의도된 프로토콜에 맞게 동작하도록 하는 데 도움이 됩니다.

Code Generation용 p7 활용법

Code Generation 관점에서 p7는 설계 선택이 구현 품질에 직접 영향을 주는 작업에 특히 강합니다. 예를 들면 여러 파일을 함께 수정해야 하는 작업, 하위 영향이 있는 동작 변경, 인접 모듈을 깨뜨릴 수 있는 리팩터링 같은 경우입니다. 반대로 한 줄짜리 사소한 수정처럼 계획 수립의 오버헤드가 효과를 상쇄하는 작업에서는 매력이 덜합니다.

p7 도입 전 확인할 점

도입을 망설이게 하는 요소는 크게 두 가지입니다:

• 일부 프로토콜 세부사항이 SKILL.md에 완전히 포함되지 않고 참조 형태로만 제시됨
• p7가 core guardrail과 narration protocol을 포함한 더 넓은 /pua 생태계 용어와 규칙에 의존함

따라서 완전히 독립형인 스킬을 원한다면, 상위 시스템 컨텍스트까지 함께 로드하지 않는 이상 p7는 문서화가 다소 부족하게 느껴질 수 있습니다.

첫 실행 품질은 어떻게 평가하나

첫 실행에서는 p7가 다음을 제대로 했는지 확인하세요:

• 계획과 구현을 분리했는가
• 영향을 받는 파일, 모듈, 인터페이스를 짚었는가
• 당신이 준 제약을 지켰는가
• 형식적인 체크리스트가 아니라 의미 있는 자기 점검으로 마무리했는가

이 요소들이 빠져 있다면, 호출 방식이나 실행 환경에서 스킬이 의도대로 로드되지 않았을 가능성이 큽니다.

p7 스킬 FAQ

p7는 초보자에게도 쉬운가

보통 수준입니다. p7 스킬 자체는 이해하기 어렵지 않지만, 완전 초보를 가르치는 데 최적화된 형태는 아닙니다. 사용자가 작업을 구조화해 제시하고, 구현 계획을 검토하고, 영향 분석이 타당한지 판단할 수 있다는 전제를 깔고 있습니다.

P8 없이도 p7가 유용한가

네, 다만 한계는 있습니다. 소스 기준으로 p7는 P8 감독 하에 놓인 역할이므로, 이상적인 사용 방식은 위임된 실행자입니다. 그래도 독립적으로 쓸 수는 있습니다. 그럴 때는 그 역할을 직접 흉내 내면 됩니다. 즉, 범위가 명확한 하위 작업과 분명한 제약을 함께 주면 됩니다. 다만 최상위 오케스트레이션까지 기대하면 안 됩니다.

일반 프롬프트보다 p7가 더 나은 때는 언제인가

정의된 엔지니어링 작업을 절차적으로 실행해야 할 때 p7가 더 낫습니다. 일이 “먼저 계획, 다음 구현, 마지막 검토”의 흐름에서 이득을 본다면, p7는 일반 프롬프트가 자주 생략하는 구조를 제공합니다.

언제 p7를 쓰지 말아야 하나

다음 용도에는 p7를 쓰지 않는 편이 좋습니다:

• 모호한 제품 아이데이션
• 요구사항이 분명하지 않은 상태의 광범위한 아키텍처 선택
• 아직 로드하지 않은 저장소 특화 프로토콜 지식이 많이 필요한 작업
• 구조화된 계획이 시간만 늘리고 품질 이점은 적은 사소한 수정

p7에 설치 스크립트나 추가 리소스가 포함되어 있나

확인 가능한 저장소 근거 기준으로는, 스킬 디렉터리 화면에 별도 스크립트나 번들 지원 파일이 드러나지는 않습니다. 핵심 파일은 SKILL.md이고, 여기서 references/p7-protocol.md를 참조하므로 해당 파일이 설치 환경에 실제로 존재하는지 확인해 보세요.

p7는 출력 형식에 대한 성향이 강한 편인가

그렇습니다. 스킬 설명은 정해진 완료 래퍼와 특정 산출물 순서를 전제로 합니다. 팀 차원에서 일관된 에이전트 출력을 원한다면 잘 맞지만, 자유로운 대화형 코딩 스타일을 선호한다면 덜 적합할 수 있습니다.

p7 스킬 개선 방법

p7의 하위 작업 경계를 더 날카롭게 잡기

p7 결과를 가장 빠르게 개선하는 방법은 작업 범위를 좁히는 것입니다. “결제 리팩터링”처럼 넓게 쓰지 말고, 어떤 endpoint, component, module, failure mode가 관련되는지 지정하세요. p7는 실행자이므로 경계가 선명할수록 code generation 품질이 좋아집니다.

영향 분석 대상을 구체적으로 지정하기

그냥 “영향 분석도 해줘”라고만 하지 마세요. 무엇을 확인해야 하는지 이름을 붙여 주세요:

• API compatibility
• schema changes
• test impact
• performance risk
• migration needs
• rollback concerns

이렇게 해야 p7의 계획 단계가 실제로 더 쓸모 있어집니다.

저장소 단서를 처음부터 제공하기

가능성이 높은 파일을 안다면 처음부터 말해 주세요. 예:

• src/auth/session.ts
• app/api/login/route.ts
• tests/auth.spec.ts

이런 단서는 불필요한 탐색을 줄이고, 특히 큰 저장소에서 p7 사용 품질을 높여 줍니다. code generation 품질은 결국 올바른 표면을 건드리느냐에 크게 좌우됩니다.

컨텍스트가 얇다면 코드 전에 가정을 먼저 요구하기

흔한 실패 패턴은 맥락이 빈약한데도 너무 빨리 구현으로 들어가는 것입니다. 브리프가 불완전하다면 p7에 이렇게 지시하세요: “List assumptions and blockers before coding.” 그러면 이 스킬의 솔루션 주도형 성격을 살리면서, 확신이 낮은 출력을 억지로 뽑아내는 일을 줄일 수 있습니다.

자기 점검을 수정 도구로 활용하기

3-question self-review를 장식처럼 넘기지 마세요. 다음 항목을 읽어내는 용도로 쓰면 좋습니다:

• 숨은 가정
• 미흡한 엣지 케이스 처리
• 빠진 테스트나 검증 단계

그다음 이 빈틈을 다시 p7의 두 번째 패스에 입력하세요. 스킬 자체를 바꾸지 않고도 p7 결과를 개선하는 가장 간단한 방법 중 하나입니다.

수용 기준으로 p7 프롬프트 강화하기

더 나은 p7 for Code Generation 결과를 원한다면 성공 조건을 포함하세요. 예를 들면:

• “existing tests must still pass”
• “no breaking API changes”
• “support both mobile and desktop UI”
• “keep public function signatures stable”

수용 기준이 들어가면 p7는 단순히 코드를 잘 쓰는 모델을 넘어, 더 신뢰할 수 있는 실행자로 바뀝니다.

초기에 잡아야 할 흔한 실패 패턴

다음 징후를 주의해서 보세요:

• 구현을 이끌기엔 계획이 너무 일반적인 경우
• 코드가 명시된 제약을 건너뛰는 경우
• 자기 점검에서 실제 트레이드오프를 언급하지 않는 경우
• 제공하지 않은 상위 시스템 컨텍스트를 당연하게 가정하는 경우

이런 문제는 대개 p7 자체가 쓸모없다는 뜻이 아니라, 프롬프트 품질이나 컨텍스트 로딩 문제에 가깝습니다.

스킬로서 p7는 어떻게 더 좋아질 수 있나

저장소가 프로토콜 내용을 더 많이 인라인으로 노출하거나, 스킬 폴더 안의 지원 파일로 더 직접적으로 연결해 준다면 p7는 훨씬 도입하기 쉬워질 것입니다. 호출 예시, 기대되는 완료 구조, 독립 실행 사용법 같은 구체적인 사례가 추가되면 신규 사용자 입장에서 초기 설정 부담도 크게 줄어듭니다.