prd-planner

prd-planner 스킬 개요

prd-planner가 하는 일

prd-planner는 한 번에 긴 프롬프트로 끝내는 방식이 아니라, 지속적으로 유지되는 파일 기반 워크플로로 product requirements document를 만드는 Requirements Planning 스킬입니다. 핵심 가치는 단순히 “PRD를 써준다”는 데 있지 않습니다. 조사 내용, 가정, 작업 진행 상황, 최종 요구사항, 기술 후속 내용을 각각 안정적인 파일로 분리해 두기 때문에, 진행 중 에이전트가 맥락을 잃어버릴 가능성을 줄여줍니다.

prd-planner가 잘 맞는 사용자

prd-planner는 PRD 초안을 한 번 뽑고 끝내는 수준 이상을 원하는 개인 개발자나 팀에 가장 잘 맞습니다. 특히 discovery, 엣지 케이스 검토, PRD 작성, 기술 설계까지 이어지는 흐름에서 추적 가능성이 중요할 때 유용합니다. 요구사항을 여러 차례 다듬어야 한다면, 일반적인 단발성 프롬프트보다 prd-planner 쪽이 더 안정적입니다.

해결하려는 작업

사용자들이 prd-planner를 도입하는 가장 흔한 이유는, 반복 수정에도 버틸 수 있는 구조화된 PRD 작성 흐름이 필요하기 때문입니다. 요구사항을 명확히 하고, 노트를 남기고, 실제로 쓸 수 있는 PRD를 만들고, 필요하면 기술 설계로 넘기는 흐름까지 포함합니다. 저장소에서도 이 스킬을 컨텍스트 전환, 놓치는 생각, 들쭉날쭉한 PRD 품질을 해결하는 방법으로 분명히 위치시키고 있습니다.

prd-planner가 다른 점

prd-planner의 가장 큰 차별점은 4-file 패턴입니다. 모든 내용을 한 응답에 몰아넣는 대신, 보통 docs/ 아래에 공통 scope prefix를 두고 계획, 노트, PRD, 기술 설계 파일을 각각 생성합니다. 그래서 나중에 다시 열어보고, 리뷰하고, 확장해야 하는 Requirements Planning 작업에 특히 잘 맞습니다.

prd-planner가 맞지 않는 경우

빠른 기능 요약 한 장, 가벼운 브레인스토밍, 혹은 순수한 솔루션 아키텍처 문서만 필요하다면 prd-planner는 적합하지 않습니다. 스킬 자체 설명에서도, 사용자가 PRD를 명시적으로 요청한 경우가 아니라면 architecture-only 요청은 architecting-solutions로 보내라고 안내합니다.

prd-planner 스킬 사용 방법

prd-planner 설치 맥락

이 저장소는 스킬 자체 안에서 범용 패키지 설치 방식을 제공하지 않습니다. 포함된 README.md에는 Claude skills 디렉터리로 로컬 심볼릭 링크를 거는 형태의 설치 예시가 나와 있습니다.

ln -s ~/Documents/code/GitHub/agent-playbook/skills/prd-planner/SKILL.md ~/.claude/skills/prd-planner.md

다른 skill loader를 사용한다면, 위 패턴을 여러분의 에이전트 플랫폼이 요구하는 디렉터리 구조나 등록 방식에 맞게 바꿔 적용하면 됩니다. GitHub에서 직접 살펴볼 때는 zhaono1/agent-playbook의 skills/prd-planner 경로에 있습니다.

먼저 읽어야 할 파일

빠르게 prd-planner install과 평가를 진행하려면, 아래 순서로 읽는 것이 좋습니다.

1. skills/prd-planner/SKILL.md
2. skills/prd-planner/README.md
3. skills/prd-planner/references/edge-case-analysis.md

SKILL.md에는 활성화 규칙, 워크플로 의도, 필요한 도구, 핵심 파일 패턴이 들어 있습니다. reference 파일은 실제로 쓸 만한 엣지 케이스 점검 가이드를 추가해 주며, PRD 품질을 체감할 정도로 끌어올려 줍니다.

prd-planner가 활성화되는 방식

이 스킬은 사용자가 PRD를 명시적으로 요청하거나, “product requirements document”라고 말하거나, 이에 해당하는 중국어 표현을 쓸 때 동작하도록 설계되어 있습니다. 이 점이 중요한 이유는, prd-planner가 범용 planning 스킬이 아니기 때문입니다. 프롬프트가 “PRD를 만들어줘”가 아니라 “아키텍처를 설계해줘”에 가까우면, 잘못된 워크플로가 트리거되거나 결과가 약해질 수 있습니다.

기대해야 하는 4-file 패턴

일반적인 prd-planner usage 흐름에서는 짧은 kebab-case scope를 사용해 docs/ 아래에 다음 네 개 파일을 생성합니다.

docs/{scope}-prd-task-plan.md
docs/{scope}-prd-notes.md
docs/{scope}-prd.md
docs/{scope}-tech.md

이것이 prd-planner의 핵심 운영 방식입니다. 파일 생성이나 지속적으로 남는 산출물이 필요 없다면, prd-planner는 아마 최적의 선택이 아닙니다.

prd-planner가 사용자에게 필요한 입력

prd-planner는 아래 정보를 주면 가장 잘 작동합니다.

• 기능 또는 제품 목표
• 대상 사용자
• 비즈니스 목표 또는 성공 지표
• 일정, 플랫폼, 컴플라이언스, 기존 스택 같은 제약 조건
• 이미 알고 있는 non-goal
• 관련 코드, 문서, 티켓, 예시 링크

이 정보가 없어도 PRD 초안은 만들 수 있지만, 그만큼 가정에 더 많이 의존하게 됩니다.

모호한 요청을 강한 프롬프트로 바꾸는 법

약한 프롬프트:

Create a PRD for notifications.

더 강한 프롬프트:

Create a PRD for in-app notifications for our B2B admin dashboard.
Users are account admins and support managers.
Goal: reduce missed follow-up tasks and improve response SLA compliance.
Constraints: web app first, existing React frontend and Node backend, no push notifications in v1.
Non-goals: email campaign tooling, mobile support.
Please use docs/notifications as the scope basis and call out edge cases, permissions, and rollout risks.

두 번째처럼 쓰면 prd-planner가 일반론이 아니라, 맥락이 살아 있는 구체적인 PRD를 만들기에 충분한 정보를 얻게 됩니다.

실무에서 권장되는 prd-planner 워크플로

실제로는 아래 순서가 가장 실용적입니다.

1. PRD를 명시적으로 요청합니다.
2. 비즈니스 맥락, 범위, 제약 조건을 제공합니다.
3. 스킬이 파일 세트를 생성하게 둡니다.
4. 최종 PRD만 보지 말고 먼저 notes 파일을 검토합니다.
5. 잘못된 가정을 초기에 바로잡습니다.
6. 엣지 케이스, acceptance criteria, 기술적 함의에 대해 2차 패스를 요청합니다.
7. 생성된 *-tech.md를 구현 계획으로 넘어가는 브리지로 활용합니다.

이 지점에서 prd-planner가 단일 프롬프트보다 강해집니다. 처음부터 다시 시작할 필요 없이, notes를 수정하고 synthesis를 다시 돌리며 반복 개선할 수 있기 때문입니다.

엣지 케이스 reference는 초반에 활용하기

가장 유용한 보조 파일은 references/edge-case-analysis.md입니다. 여기에는 요구사항 유형 분류와 함께 deletion strategy, loading state, pagination, validation, error handling 같은 항목을 코드베이스에서 어떻게 스캔할지에 대한 명령 예시가 포함되어 있습니다. 많은 약한 PRD가 바로 이런 빠진 동작들 때문에 실패하므로, Requirements Planning 관점에서 매우 실용적입니다.

출력 품질을 높여주는 저장소 기준 팁

이 스킬은 Read, Write, Edit, Bash, Grep, Glob, AskUserQuestion, WebSearch 같은 도구 사용을 허용합니다. 즉, prd-planner는 허공에서 텍스트만 생성하는 도구가 아니라, 실제 코드베이스를 살펴보고 필요한 질문을 던지는 흐름을 전제로 설계되어 있습니다. 환경에서 파일 쓰기나 셸 검색이 막혀 있다면, 의도된 가치의 상당 부분을 잃게 됩니다.

기존 제품에 가장 잘 맞는 프롬프트 패턴

기능이 기존 시스템에 속해 있다면, 요청에 코드베이스 위치를 직접 넣는 편이 좋습니다. 예를 들면:

Create a PRD for bulk user deactivation.
Relevant areas:
- `src/features/users/`
- existing soft delete behavior
- admin audit log requirements
Please inspect current list, detail, and permission patterns before drafting requirements.

이렇게 하면 prd-planner가 추상적인 제품 문서가 아니라, 실제 구현 제약에 맞닿아 있는 요구사항으로 방향을 잡게 됩니다.

결과물을 확정하기 전에 검토할 것

PRD를 최종본으로 받아들이기 전에, prd-planner가 아래 항목을 제대로 담았는지 확인해야 합니다.

• 사용자 역할과 권한
• 명시적인 non-goal
• 엣지 케이스와 실패 상태
• 롤아웃 또는 마이그레이션 고려사항
• 측정 가능한 성공 기준
• 현재 시스템 동작에 대한 의존성

겉으로 그럴듯한 PRD라도 이런 내용이 빠져 있으면 여전히 위험합니다.

prd-planner 스킬 FAQ

prd-planner는 초보자에게도 괜찮은가

그렇습니다. 만들고 싶은 기능은 이미 알고 있지만, 구조가 필요한 경우라면 특히 도움이 됩니다. 파일 패턴이 백지 상태의 부담을 줄여주기 때문입니다. 다만 제품 사고 자체가 부족한 상황을 대신 해결해 주는 지름길은 아닙니다. 입력이 약하면 요구사항도 얕아집니다.

일반적인 PRD 프롬프트와 prd-planner는 무엇이 다른가

보통의 프롬프트는 문서 하나를 반환합니다. 반면 prd-planner skill은 지속적으로 남는 planning artifact를 중심으로 설계되어 있어, 조사 내용, 진행 상황, 최종 산출물, 기술 후속 작업을 분리해 유지할 수 있습니다. 그 결과 수정 품질이 더 좋아지고, 중간에 맥락을 잃을 가능성도 줄어듭니다.

prd-planner는 신규 제품에만 쓰는가

아닙니다. 오히려 기존 제품에서 더 유용할 수도 있습니다. reference 자료가 현재 코드 패턴을 스캔해 보라고 유도하기 때문입니다. 덕분에 실제 구현 제약과 맞는 PRD를 만들 가능성이 높아집니다.

아키텍처 설계 전용으로 prd-planner를 써도 되나

이상적이진 않습니다. 스킬 설명에서도 architecture-only 요청은, 사용자가 실제로 PRD를 요청한 경우가 아니라면 architecting-solutions를 쓰라고 명시합니다. prd-planner for Requirements Planning 용도로 쓰고, 모든 설계 작업을 다 받아내는 범용 도구처럼 쓰지는 않는 편이 맞습니다.

prd-planner는 파일 쓰기 권한이 꼭 필요한가

의도된 워크플로를 원한다면 사실상 그렇습니다. 이 스킬의 핵심 가치는 파일을 쓰고, 그 파일을 기반으로 반복 개선하는 데서 나옵니다. 채팅 전용 환경에서도 프롬프팅 방식만 일부 차용할 수는 있지만, persistence 모델의 장점은 잃게 됩니다.

언제 prd-planner를 건너뛰어야 하나

한 문단짜리 짧은 브리프, user story 하나, 혹은 아직 scope가 안정되지 않은 탐색적 아이데이션만 필요할 때는 건너뛰는 편이 좋습니다. 4-file 프로세스의 오버헤드는 PRD를 리뷰하고, 수정하고, 엔지니어링에 넘길 상황일 때 가장 정당화됩니다.

prd-planner 스킬을 더 잘 활용하는 방법

prd-planner에 더 좋은 scope 정의 주기

가장 큰 품질 레버는 scope의 명확성입니다. 짧고 구분되는 scope 이름을 주고, 무엇이 v1에 포함되며 무엇이 범위 밖인지 분명히 정의하세요. 그래야 파일 이름도 깔끔해지고, 요구사항이 불필요하게 번지는 것도 줄일 수 있습니다.

기능명만이 아니라 비즈니스 의도를 넣기

“Build approvals”는 너무 모호합니다. 반면 “Build an approval flow for purchase requests over $5,000 to reduce manual finance review time by 40%”처럼 말하면, prd-planner가 더 나은 목표, user story, acceptance criteria로 전개할 재료를 얻게 됩니다.

알려진 제약 조건을 초반에 제공하기

스택, 컴플라이언스, 일정, 조직 경계, 기존 워크플로 같은 제약은 초반부터 알려주는 것이 좋습니다. 많은 사용자가 생각하는 것보다 이런 조건이 PRD를 훨씬 크게 좌우합니다. 제약이 빠지면 보기에는 좋아도 실제로는 쓸 수 없는 요구사항이 나오기 쉽습니다.

가정 기록을 명시적으로 요청하기

강한 prd-planner guide 패턴 중 하나는 에이전트에게 이렇게 지시하는 것입니다. “가정은 notes 파일에 따로 정리하고, 확인이 필요한 항목은 표시해줘.” 이렇게 해야 숨겨진 추측이 이미 확정된 사실처럼 최종 PRD에 섞여 들어가는 일을 막을 수 있습니다.

코드베이스를 반영한 엣지 케이스 분석 활용하기

소스에 접근할 수 있다면, 요구사항을 확정하기 전에 prd-planner가 validation, pagination, loading, permissions, delete behavior의 현재 패턴을 살펴보게 하세요. 제공된 reference 파일은 특히 이 부분에서 유용합니다. 막연한 “엣지 케이스도 고려하세요”를 실제 점검 항목으로 바꿔주기 때문입니다.

최종 PRD 전에 notes 파일부터 검토하기

많은 사용자가 *-prd.md만 읽지만, 실제 병목은 대개 *-prd-notes.md에 있습니다. notes 단계에서 잘못된 가정을 고치는 편이, 나중에 정교하지만 방향이 어긋난 PRD를 통째로 다시 쓰는 것보다 훨씬 비용이 적게 듭니다.

문장 다듬기보다 빠진 의사결정을 중심으로 반복하기

첫 결과를 받은 뒤에는 단순히 “더 자세히 써줘”라고 하지 않는 편이 좋습니다. 대신 아래처럼 구체적인 개선을 요청하세요.

• 더 선명한 성공 지표
• 명시적인 권한 규칙
• 실패 및 복구 시나리오
• 의존성 매핑
• 롤아웃 순서
• 이해관계자 확인이 필요한 오픈 질문

이런 식의 반복이 문서 길이만 늘리는 것이 아니라, 실제 의사결정의 품질을 높여줍니다.

자주 나오는 실패 패턴 주의하기

전형적인 약한 출력 패턴은 다음과 같습니다.

• 실제 사용자 맥락이 없는 너무 일반적인 페르소나
• 현재 시스템 동작을 무시한 요구사항
• 빠진 non-goal
• 엣지 케이스에 대한 처리 부재
• 템플릿처럼 읽히는 기술 설계
• 테스트할 수 없을 만큼 모호한 acceptance criteria

대부분은 모델 문제라기보다 입력 문제인 경우가 많습니다.

prd-planner를 이해관계자 리뷰 루프와 함께 쓰기

prd-planner usage는 첫 결과물을 완성본이 아니라 작업 초안으로 다룰 때 더 좋아집니다. 제품 팀은 PRD를, 엔지니어링은 기술 설계를, 모두가 가정을 각각 리뷰하도록 나누세요. 파일 기반 구조라서 이런 역할 분담과 리뷰 루프를 운영하기에 잘 맞습니다.

팀 표준 템플릿으로 정착시키기

팀이 이 워크플로를 마음에 들어 한다면, prd-planner 위에 여러분만의 scope naming 규칙, docs/ 관례, PRD 섹션 구조, 리뷰 체크리스트를 정해 두는 것이 좋습니다. 스킬 자체가 이미 기본 구조를 잘 제공하므로, 여기에 내부 표준을 더하면 결과물을 꾸준히 배포 가능한 수준으로 맞출 수 있습니다.