prd-to-plan

prd-to-plan skill 개요

prd-to-plan skill은 제품 요구사항 문서(PRD)를 얇고 end-to-end한 vertical slice들로 나눈 단계별 구현 계획으로 바꿔줍니다. 흔한 백로그 초안이나 레이어별 기술 체크리스트를 만드는 대신, prd-to-plan은 스키마, backend, UI, 테스트를 한 단계 안에서 함께 관통하는 tracer-bullet 방식의 phase를 만들고, 그 결과를 ./plans/에 Markdown으로 저장하도록 설계되어 있습니다.

prd-to-plan이 적합한 용도

prd-to-plan은 이미 PRD가 있고, 팀이나 에이전트가 실제로 구현에 착수할 수 있는 실행 계획이 필요할 때 가장 유용합니다. 특히 다음과 같은 경우에 잘 맞습니다.

• 기능 명세를 구현 phase로 바꾸려는 product engineer
• 코딩 시작 전에 Requirements Planning을 진행하는 tech lead
• 계획 산출물이 로컬 파일로 남아야 하는 AI-assisted workflow
• “backend 먼저”처럼 넓은 단계보다, 작고 데모 가능한 slice를 선호하는 팀

누가 prd-to-plan에서 가장 큰 가치를 얻는가

가장 잘 맞는 사용자는 아래 두 가지를 모두 갖춘 사람입니다.

• 어느 정도 구체화된 PRD
• 대상 codebase 또는 최소한 그 아키텍처에 대한 접근

아이디어가 한 줄뿐이라면 prd-to-plan을 쓰기엔 아직 이릅니다. 반대로 이미 정확한 ticket 단위까지 다 정해져 있다면, 오히려 쓰기엔 너무 늦었을 수 있습니다.

prd-to-plan의 진짜 역할

핵심 역할은 “PRD를 요약하는 것”이 아닙니다. 실제로는 “현재 시스템을 존중하면서도, 가장 안전한 순서로 작고 완결된 구현 단계를 어떻게 쪼갤 것인가?”에 답하는 것입니다. 그래서 아키텍처와 순서가 중요한 상황에서는, 단순 브레인스토밍 프롬프트보다 Requirements Planning용 prd-to-plan이 훨씬 실용적입니다.

일반 프롬프트와 다른 prd-to-plan의 차별점

가장 큰 차이는 tracer-bullet 접근 방식입니다.

• 각 phase는 스택을 관통하는 완결된 경로여야 함
• 각 phase는 그 자체로 테스트 가능하거나 데모 가능해야 함
• 계획의 앞부분에서 오래 유지될 아키텍처 결정을 먼저 잡아야 함
• 결과물은 너무 이른 시점의 파일 단위 구현 디테일을 피해야 함

이 조합 덕분에 보통은 실행하기 쉽고, 중간에 수정하기도 쉬운 계획이 나옵니다.

설치 전에 가장 중요하게 볼 점

이 prd-to-plan skill은 매우 가볍습니다. 저장소에서 핵심 신호는 helper script나 풍부한 참고 자료가 아니라 대부분 SKILL.md에 들어 있습니다. 빠르게 도입하기에는 좋지만, 그만큼 결과 품질은 PRD와 제공하는 맥락의 질에 크게 좌우됩니다. 팀에서 엄격한 템플릿, 산정 공식, Jira용 ticket 생성까지 필요하다면, 이후 단계를 위한 별도 workflow를 직접 덧붙일 필요가 있습니다.

prd-to-plan skill 사용 방법

prd-to-plan 설치 맥락

Skills ecosystem을 쓰고 있다면, mattpocock/skills 저장소에서 아래 명령으로 prd-to-plan을 설치할 수 있습니다.

npx skills add mattpocock/skills --skill prd-to-plan

설치 후 가장 먼저 읽어야 할 파일은 다음입니다.

• prd-to-plan/SKILL.md

이 skill은 구조가 단순해서, 보통 이 파일만 빠르게 읽어도 중요한 내용 대부분을 파악할 수 있습니다.

prd-to-plan에 필요한 입력

좋은 prd-to-plan usage를 위해서는 아래 세 가지를 함께 제공하는 것이 좋습니다.

1. PRD 본문 또는 그 파일 경로
2. codebase 맥락
3. 절대 바꿀 수 없는 아키텍처 제약

최소한 아래 정보는 있어야 계획이 유의미해집니다.

• user flow 또는 acceptance criteria
• 현재 stack과 주요 경계
• auth 모델
• data model 제약
• integration 및 외부 서비스
• “반드시 feature flag 뒤에서 배포해야 함” 같은 delivery 제약

이 정보가 없으면 계획이 그럴듯해 보여도 실제 상황과 어긋날 수 있습니다.

대략적인 PRD를 이 skill에 맞게 다듬는 방법

거친 PRD도 실행 계획에 쓸 수 있으려면, 빠진 실행 신호를 채워야 합니다.

• 기능 출시 후 사용자가 무엇을 할 수 있는지
• 어떤 데이터가 생성되거나 변경되는지
• 어떤 UI surface가 영향을 받는지
• 어떤 기존 시스템과 연동되어야 하는지
• 무엇이 데모 가능한 첫 slice로 간주되는지

예를 들어 “notifications 추가” 같은 요청은 너무 약합니다. 아래처럼 쓰는 편이 훨씬 낫습니다.

• v1은 in-app notifications만
• dashboard에 notification center 추가
• nav에 unread count 표시
• 이벤트는 comments와 approvals에서 발생
• read/unread state 저장
• email은 아직 제외

이 정도는 되어야 prd-to-plan이 추측이 아니라 실제 slice를 만들 수 있습니다.

prd-to-plan 프롬프트를 잘 쓰는 방법

좋은 호출 프롬프트는 계획 산출물의 형태와 저장소 맥락을 둘 다 분명하게 적습니다. 예를 들면 다음과 같습니다.

“Use prd-to-plan on the PRD below. Explore the repo first, identify durable architecture decisions, then produce a phased plan using thin vertical slices. Keep phases demoable, avoid file-level implementation detail, and save the final plan in ./plans/.”

이 방식이 단순히 “implementation plan 만들어줘”라고 하는 것보다 낫습니다. prd-to-plan이 가진 계획 수립 규율을 그대로 살릴 수 있기 때문입니다.

prd-to-plan 사용을 위한 추천 workflow

실무적으로는 아래 순서가 가장 무난합니다.

1. PRD를 대화에 붙이거나 파일 위치를 지정한다
2. 에이전트가 repo를 살펴보게 한다
3. 먼저 durable architecture decisions를 뽑게 한다
4. 그 결정이 맞는지 검토한다
5. 그다음 단계별 계획을 생성한다
6. 코딩에 들어가기 전에 phase 경계를 한 번 더 다듬는다

이렇게 두 단계로 나눠 검토하면, 처음 나온 완성본을 그대로 받아들이는 것보다 계획 오류를 훨씬 더 잘 잡아낼 수 있습니다.

codebase 탐색이 중요한 이유

이 skill은 slice를 나누기 전에 repo를 탐색하는 과정을 전제로 합니다. 중요한 이유는 phase 순서가 아래 요소에 좌우되기 때문입니다.

• 기존 route 패턴
• 현재 data model 구조
• 이미 존재하는 API 여부
• auth check가 어디에서 이뤄지는지
• repo가 어떤 테스트 스타일을 쓰는지

에이전트가 PRD만 보고 계획하면, 결과는 깔끔해 보여도 실제 codebase 기준으로는 비현실적일 수 있습니다.

slice를 나누기 전에 반드시 확인할 durable decision

prd-to-plan에서 가장 검토 가치가 큰 지점은 계획 상단에 배치되는 durable decision 집합입니다. 최소한 아래 항목은 확인해야 합니다.

• route 또는 URL 구조
• database schema 방향
• 핵심 entity와 관계
• auth 및 authorization 모델
• third-party 경계

이 부분이 틀리면, 뒤에 이어지는 모든 phase 순서도 어긋날 가능성이 큽니다.

prd-to-plan에서 좋은 vertical slice는 어떤 모습인가

좋은 slice는 좁지만 완결되어 있습니다. 예를 들면:

• 하나의 새 entity를 end-to-end로 만든다
• 제한된 API path 하나를 노출한다
• 특정 user role을 위한 UI path 하나를 렌더링한다
• 전체 happy path를 테스트한다

반대로 나쁜 slice는 수평적으로 쪼개집니다.

• “모든 database table 만들기”
• “모든 backend endpoint 구현하기”
• “UI 전체 완성하기”

이 skill은 각 phase가 실제로 동작하는 상태로 보여줄 수 있을 때 가장 강력합니다.

출력물에 prd-to-plan이 포함해야 하는 것

보통 ./plans/ 안에 다음 요소를 갖춘 Markdown 계획이 생성됩니다.

• durable architectural decisions를 짧게 정리한 header
• 여러 개의 phase
• 각 phase를 end-to-end slice로 설명한 본문
• 구현을 이끌 만큼의 충분한 구체성
• 그러나 파일명이나 취약한 내부 구조를 고정해버릴 정도로 과한 디테일은 아님

이 균형이 중요합니다. 실행 가능해야 하지만, 너무 이르게 특정 구현에 과적합되면 안 됩니다.

도입 전 저장소를 읽는 가장 빠른 순서

이 저장소는 관련 섹션이 매우 작기 때문에, 가장 빠른 읽기 순서는 아래와 같습니다.

1. SKILL.md
2. frontmatter description
3. process와 vertical-slice 규칙

여기에는 support script, 참고 자료, rules 폴더가 없으므로 도입 리스크는 낮습니다. 다만 숨겨진 자동화나 validation helper가 있을 것이라 기대하면 안 됩니다.

출력 품질을 높여주는 실전 팁

더 나은 prd-to-plan guide 결과를 원한다면:

• 기능 목록만이 아니라 sample user journey를 포함한다
• 나중 phase로 미뤄도 되는 항목을 명시한다
• “이번 sprint에는 schema migration 금지” 같은 제약을 적는다
• 반드시 재사용해야 하는 기존 module을 알려준다
• 불확실한 architecture assumption은 따로 표시하라고 요청한다

이런 입력은 근거 없는 확신을 줄이고, 더 유용한 phase 경계를 만드는 데 도움이 됩니다.

prd-to-plan skill FAQ

prd-to-plan은 초기 아이디어 탐색에도 좋은가

그렇지는 않습니다. prd-to-plan은 기능이 어느 정도 형태를 갖추고 있어야 순서를 설계할 수 있을 때 가장 잘 작동합니다. 아직 brief 자체가 탐색 단계라면, 먼저 PRD drafting부터 하고 요구사항이 계획 가능한 수준으로 안정된 뒤에 이 skill을 쓰는 편이 낫습니다.

prd-to-plan은 초보자도 쓰기 쉬운가

네, 다만 한 가지 주의점이 있습니다. 초보자는 아키텍처 가정을 너무 빨리 받아들이는 경우가 많습니다. 이 skill은 매끈한 계획을 내줄 수 있지만, durable decision이 실제 stack에 맞는지는 여전히 직접 검토해야 합니다. 잘 다듬어진 출력물을 검증된 출력물로 착각하기 쉽습니다.

AI에게 그냥 구현 계획을 요청하는 것과 무엇이 다른가

일반 프롬프트는 대개 크고 수평적인 phase를 만들고, 아키텍처 점검 지점을 건너뜁니다. 반면 prd-to-plan skill은 더 분명한 관점을 갖고 있습니다. codebase 탐색, durable decision, tracer-bullet slice를 요구합니다. 그래서 보통은 점진적으로 구현하기 쉬운 계획이 나옵니다.

언제 prd-to-plan을 쓰지 말아야 하나

다음 경우에는 prd-to-plan을 건너뛰는 편이 좋습니다.

• 아직 제대로 된 PRD가 없음
• 작업이 아주 작은 bug fix임
• 아키텍처는 이미 확정되었고 task decomposition만 필요함
• 정확한 ticket, estimate, sprint staffing 결과물이 필요함

이런 경우에는 다른 planning workflow가 더 적합한 편입니다.

prd-to-plan이 ticket이나 파일 단위 task도 생성하나

아니요. 이 skill은 핵심 slicing 단계에서 상세한 파일명이나 function별 구현 분해를 의도적으로 피합니다. 우선은 phase planning을 위한 도구입니다. 계획이 승인된 뒤에 ticket은 별도로 만들면 됩니다.

prd-to-plan은 큰 기능에만 적합한가

아닙니다. 순서 설계와 integration 리스크가 중요한 중간 규모 기능에도 잘 맞습니다. 기준은 단순한 크기가 아니라, 단순 체크리스트보다 end-to-end slicing이 더 유용한 상황인지 여부입니다.

PRD가 현재 codebase와 충돌하면 어떻게 하나

바로 그런 상황에서 prd-to-plan usage의 가치가 큽니다. 에이전트가 repo를 살펴보게 하고, phase를 확정하기 전에 durable decision 단계에서 충돌을 먼저 드러내게 하세요. codebase 맥락을 숨기면 계획의 신뢰도는 크게 떨어집니다.

prd-to-plan skill을 더 잘 활용하는 방법

계획보다 먼저 PRD부터 개선하라

prd-to-plan 결과를 가장 빠르게 개선하는 방법은 계획이 아니라 PRD 입력을 강화하는 것입니다.

• user role을 명확히 한다
• 첫 번째로 데모 가능한 결과를 정의한다
• non-goal을 표시한다
• data ownership과 integration을 구체화한다
• v1과 이후 개선 사항을 분리한다

대부분의 경우, 더 좋은 프롬프트보다 더 좋은 PRD가 훨씬 큰 차이를 만듭니다.

아키텍처 맥락을 더 강하게 제공하라

초기 계획이 너무 뻔하고 일반적으로 느껴진다면, 대개는 시스템 제약 정보가 부족했던 경우입니다. 아래 정보를 추가하세요.

• framework와 app 구조
• 기존 service 경계
• 현재 database 패턴
• auth flow
• deployment 제약
• testing 기대치

이 정보가 있어야 Requirements Planning용 prd-to-plan이 실제 구현 작업에 맞는 slice를 만듭니다.

가정을 명시적으로 드러내도록 요청하라

흔한 실패 패턴 중 하나는 숨겨진 가정입니다. 아래처럼 요청하면 skill의 실용성이 크게 올라갑니다.

• “계획 전에 불확실한 가정을 먼저 나열해줘”
• “검증이 필요한 decision을 표시해줘”
• “추론한 architecture와 확인된 architecture를 분리해줘”

이렇게 하면 검토가 훨씬 빠르고 안전해집니다.

phase 크기를 과감하게 줄여라

또 다른 흔한 실패는 phase가 너무 큰 것입니다. 계획에 소수의 거대한 phase만 있다면, 에이전트에게 다음을 요청하세요.

• 각 phase를 더 얇은 end-to-end slice로 나눌 것
• 각 slice가 독립적으로 데모 가능하도록 할 것
• 선택적 polish와 edge case는 뒤로 미룰 것
• 각 slice마다 학습 목표를 하나만 남길 것

이렇게 해야 tracer-bullet 방식이 무너지지 않습니다.

구현 디테일이 너무 빨리 나오지 않게 막아라

출력물이 너무 일찍 정확한 파일, class, low-level function 이름을 언급하기 시작하면 방향을 다시 잡아야 합니다. prd-to-plan은 우선 phase와 capability 수준에 머물 때 더 잘 작동합니다. slice 순서가 승인된 뒤라면, ticket 수준의 디테일은 언제든 추가할 수 있습니다.

계획은 두 번에 나눠 다듬어라

신뢰할 만한 검토 루프는 아래와 같습니다.

1. 1차 검토: architecture decision과 phase 순서를 검증한다
2. 2차 검토: 각 phase의 범위, 리스크, acceptance check를 다듬는다

순서를 바로잡기 전에 문장 표현부터 다듬지 마세요. 실제 planning 오류의 대부분은 형식보다 순서와 경계에서 발생합니다.

각 slice에 acceptance check를 붙여라

좀 더 실행 가능한 계획이 필요하다면, 각 phase마다 간단한 검증 문장을 넣어달라고 요청하세요. 예를 들면:

• 어떤 user path가 동작하는지
• 어떤 data 변화가 눈에 보이는지
• 어떤 API 동작을 테스트할 수 있는지
• 어떤 데모가 slice 완료를 증명하는지

이렇게 하면 ticket 수준 디테일을 강제하지 않으면서도, 추상적인 slice를 실제 구현 가능한 milestone으로 바꿀 수 있습니다.

prd-to-plan 다음에 별도 decomposition 단계를 붙여라

강력한 패턴은 먼저 prd-to-plan을 사용하고, 승인된 phase를 ticket, estimate, coding prompt로 바꾸는 별도 workflow를 이어서 돌리는 것입니다. 이렇게 해야 이 skill의 강점, 즉 구현 디테일보다는 먼저 순서와 slicing을 잡는 능력을 그대로 살릴 수 있습니다.

prd-to-plan의 가장 큰 한계를 알아두라

이 저장소는 좋은 planning 패턴을 제공하지만, 이를 강제하는 메커니즘까지 제공하지는 않습니다. bundled script, template, reference doc이 없기 때문에 출력 일관성을 자동으로 맞춰주지 않습니다. 팀 단위 재현성을 원한다면, 이 skill 주변에 자체 review checklist를 만들어 두는 것이 좋습니다.

• PRD가 충분히 완성되어 있었는가?
• Durable decision이 검증되었는가?
• Phase가 정말 vertical slice인가?
• 각 phase가 데모 가능한가?
• low-level detail이 적절히 뒤로 미뤄졌는가?

이 정도의 간단한 래퍼만 있어도, 일상적인 사용에서 prd-to-plan의 신뢰도는 크게 높아집니다.