write-a-prd

write-a-prd 스킬 개요

write-a-prd는 막연한 기능 아이디어를 구조화된 PRD로 바꿔주는 데 특화된 스킬입니다. 일반적인 프롬프트가 자주 놓치는 세 가지, 즉 저장소 탐색, 집요한 명확화, 모듈 단위 설계 사고를 중심에 둡니다. 실제 코드베이스에 발을 딛지 않은 번듯한 문서가 아니라, 코드 현실에 맞는 Requirements Planning 워크플로가 필요한 엔지니어, 테크 리드, AI 보조 빌더에게 특히 잘 맞습니다.

write-a-prd가 실제로 하는 일

write-a-prd 스킬은 에이전트가 다음 흐름을 따르도록 안내합니다:

• 문제 설명을 충분히 구체적으로 수집하고,
• 저장소를 직접 살펴 가정을 검증하며,
• 핵심 의사결정이 명시될 때까지 사용자를 인터뷰하고,
• 테스트 가능한 깊이 있는 추상화에 초점을 맞춰 주요 모듈을 제안한 뒤,
• 결과를 GitHub issue에 올릴 수 있는 형태의 PRD로 정리합니다.

잘 맞는 사용자와 해결하려는 업무

단순히 “PRD 하나 써줘” 수준을 넘는 작업이라면 write-a-prd를 쓰는 편이 낫습니다. 특히 다음이 필요한 팀에 적합합니다:

• 기존 코드베이스를 기준으로 신규 기능 범위를 잡고 싶을 때,
• 구현 전에 숨어 있는 결정 사항을 드러내고 싶을 때,
• 제품 의도를 구현 가능한 요구사항으로 바꾸고 싶을 때,
• 리뷰 가능한 GitHub 중심의 기획 산출물을 만들고 싶을 때.

이 write-a-prd 스킬이 돋보이는 이유

차별점은 문서 포맷이 아닙니다. 핵심은 워크플로의 규율입니다:

• 최초 브리프를 그대로 믿지 않고 repo부터 검증하고,
• 모호함이 사라질 때까지 끈질기게 질문하며,
• 최종 문서에 들어가기 전에 먼저 모듈을 스케치하고,
• 테스트 가능한 깊은 모듈에 명시적으로 신경 씁니다.

그래서 write-a-prd는 단발성 PRD 프롬프트보다 Requirements Planning에 더 실용적입니다.

설치하거나 도입하기 전에 알아둘 점

이 스킬은 가볍습니다. 저장소 근거상 SKILL.md 파일 하나만 있고, 보조 스크립트나 템플릿 폴더, 추가 리소스는 없습니다. 빠르게 도입하기에는 좋지만, 그만큼 결과물 품질은 사용자가 제공하는 입력과 에이전트가 repo를 얼마나 꼼꼼히 살펴보는지에 크게 좌우됩니다. 고정 템플릿, 자동화, issue 등록 스크립트까지 기대한다면 이 스킬만으로는 부족합니다.

write-a-prd 스킬 사용 방법

write-a-prd 설치 맥락

upstream 기준으로 이 스킬 자체는 write-a-prd/SKILL.md에 들어 있는 지시문 파일 하나입니다. 그 파일 안에는 스킬 전용 설치 절차가 따로 문서화되어 있지 않습니다. Skills 호환 환경을 쓰고 있다면, 에이전트 플랫폼이 요구하는 방식으로 이 저장소를 설치하거나 활성화한 뒤 write-a-prd slug를 사용할 수 있게 만들면 됩니다.

설치 전에 평가하려면 가장 먼저 읽어야 할 파일은 다음입니다:

• SKILL.md

이 스킬에는 추가 README.md, metadata.json, rules/, resources/ 파일이 없습니다.

먼저 이 파일부터 읽으세요

처음 쓰기 전에 SKILL.md를 처음부터 끝까지 읽는 것이 좋습니다. 이 스킬은 해당 파일 하나에 사실상 모든 핵심 동작이 들어 있습니다:

• 언제 스킬이 트리거되어야 하는지,
• 어떤 인터뷰 흐름을 요구하는지,
• repo 탐색 단계를 어떻게 거치는지,
• 모듈 설계에서 무엇을 기대하는지,
• 최종 PRD 템플릿이 무엇인지.

write-a-prd에 필요한 입력

write-a-prd 스킬은 다음 정보를 줄수록 더 잘 동작합니다:

• 해결하려는 문제,
• 그 문제를 겪는 사용자,
• 현재의 우회 방식이나 고통 지점,
• 일정, 호환성, 컴플라이언스 같은 제약,
• 초기 해결 아이디어가 있다면 그것,
• 살펴봐야 할 저장소나 코드 영역,
• PRD에 어느 정도 구현 상세를 담고 싶은지.

약한 입력: “Add notifications.”

강한 입력: “We need in-app notifications for failed background jobs because users currently miss email alerts. The app is multi-tenant, jobs already emit failure events, and we need an MVP this sprint without mobile push support.”

거친 아이디어를 좋은 write-a-prd 프롬프트로 바꾸는 법

좋은 write-a-prd 프롬프트는 보통 비즈니스 맥락, 코드베이스 범위, 의사결정 제약을 한 메시지 안에 함께 담습니다. 다음을 포함하세요:

1. 원하는 결과,
2. 영향을 받는 사용자,
3. 관련 repo 경로,
4. 이미 알고 있는 제약,
5. 스킬이 풀어주길 바라는 열린 질문.

예시 구조:

• “Help me use write-a-prd for Requirements Planning.”
• “The problem is…”
• “Please inspect these areas of the repo…”
• “Assume these constraints…”
• “Challenge weak assumptions and produce a GitHub-issue-ready PRD.”

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

실제로는 다음 순서로 write-a-prd를 쓰는 것이 좋습니다:

1. 문제를 길고 구체적으로 설명합니다.
2. 초안 작성 전에 에이전트가 코드베이스를 살펴보게 합니다.
3. 템플릿으로 서둘러 넘어가지 말고 후속 질문에 충분히 답합니다.
4. 제안된 모듈과 테스트 경계를 검토합니다.
5. 그다음에야 최종 PRD 작성을 요청합니다.
6. 결과물을 GitHub issue로 올리거나 팀 포맷에 맞게 다듬습니다.

이 순서는 중요합니다. repo 검토나 인터뷰 단계를 건너뛰면 결과물은 일반적인 PRD 프롬프트와 훨씬 비슷해집니다.

인터뷰 단계가 결과물 품질을 어떻게 바꾸는가

write-a-prd의 가장 강한 부분은 사용자를 “relentlessly” 인터뷰하라고 명시한 점입니다. 실제로는 에이전트가 다음을 집요하게 검증해야 한다는 뜻입니다:

• 엣지 케이스,
• 사용자 역할,
• 운영상 제약,
• 마이그레이션 이슈,
• 성공 기준,
• 설계 결정 사이의 의존성.

에이전트가 후속 질문을 충분히 하지 않는다면, write-a-prd를 제대로 활용하지 못하고 있는 것입니다.

Requirements Planning에서 repo 탐색이 중요한 이유

Requirements Planning 관점에서 write-a-prd의 repo 탐색 단계는 추측성 문서를 실제 계획으로 바꿔주는 핵심입니다. 에이전트에게 다음을 확인하게 하세요:

• 비슷한 기능이 이미 존재하는지,
• 어떤 모듈이 영향을 받을 가능성이 큰지,
• 현재의 네이밍 및 아키텍처 관례가 무엇인지,
• 제안된 기능이 기존 추상화와 충돌하는지.

이 과정을 거치면 문서는 그럴듯하지만 코드 현실을 무시하는 전형적인 PRD 문제를 줄일 수 있습니다.

모듈 스케치 단계를 제대로 활용하는 법

write-a-prd는 주요 모듈을 명시적으로 요구하고, 테스트하기 쉽고 오용하기 어려운 깊은 모듈을 권장합니다. 따라서 에이전트에게 다음을 짚어달라고 하는 것이 좋습니다:

• 무엇을 캡슐화해야 하는지,
• 각 모듈이 어떤 인터페이스를 노출해야 하는지,
• 어디에서 변경이 발생할 가능성이 큰지,
• 무엇을 분리된 테스트 대상으로 삼아야 하는지.

이 단계는 PRD가 단순 이해관계자 정렬용이 아니라 구현을 이끄는 문서여야 할 때 특히 유용합니다.

최종 PRD에 들어가야 할 내용

upstream 템플릿 기준으로 보면 최종 PRD에는 최소한 다음이 포함될 것으로 예상할 수 있습니다:

• ## Problem Statement
• ## Solution

다만 SKILL.md의 전체 템플릿은 현재 확인된 저장소 발췌분보다 더 이어집니다. 따라서 내부 표준 포맷으로 굳히기 전에 파일을 직접 확인하는 편이 안전합니다. 팀에서 rollout, analytics, non-goals 같은 섹션을 요구한다면 에이전트에게 템플릿 확장을 명시적으로 요청하세요.

강한 write-a-prd 사용 프롬프트 예시

실무에서 바로 응용할 수 있는 프롬프트 형태는 다음과 같습니다:

“Use the write-a-prd skill to help me plan a feature for this repository. The problem is that admins cannot bulk reassign tickets during org restructures, so teams are doing manual updates. Please inspect the ticketing, permissions, and audit-log code paths first. Constraints: preserve existing RBAC behavior, record all bulk changes, and avoid long-running synchronous requests. Interview me until the scope is clear, propose the main modules, identify which modules should have tests, then draft a GitHub-issue-ready PRD.”

write-a-prd 스킬 FAQ

write-a-prd가 일반 PRD 프롬프트보다 더 나은가요?

대체로 그렇습니다. 특히 이미 코드베이스와 구현 제약이 있는 프로젝트라면 더 그렇습니다. 일반 프롬프트도 보기 좋은 문서는 만들 수 있지만, write-a-prd는 repo 현실, 아직 정리되지 않은 트레이드오프, 모듈 경계를 PRD에 반영해야 할 때 더 강합니다.

write-a-prd는 초보자에게도 적합한가요?

적합합니다. 다만 한 가지 조건이 있습니다. 초보자는 후속 질문에 차분하게 답해야 합니다. 이 스킬은 사고 구조를 정리하는 데 도움을 줄 수 있지만, 제품 판단 자체를 대신해주지는 않습니다. 코드베이스를 잘 모른다면 그 점을 분명히 말해 에이전트가 repo 탐색과 명확화에 더 많은 노력을 쓰게 하세요.

write-a-prd가 잘 맞지 않는 경우는 언제인가요?

다음 경우에는 write-a-prd를 건너뛰는 편이 낫습니다:

• 한 단락짜리 간단한 컨셉 노트만 필요할 때,
• 살펴볼 repo 자체가 없을 때,
• 작업이 아주 작은 버그 수정일 때,
• 결정은 이미 끝났고 문장만 다듬으면 될 때,
• 팀이 이 스킬이 제공하지 않는 고정형 엔터프라이즈 PRD 스키마를 요구할 때.

write-a-prd 스킬이 구현 계획까지 만들어주나요?

간접적으로는 그렇습니다. 본질적으로는 PRD 작성용이지만, 모듈 설계 단계가 구현으로 넘어가는 가벼운 아키텍처 브리지 역할을 합니다. 다만 작업 분해, 마일스톤, 티켓 세분화가 필요하다면 PRD 이후에 한 번 더 계획 수립 단계를 거쳐야 할 수 있습니다.

GitHub issue를 자동으로 등록해주나요?

이 스킬은 PRD를 GitHub issue로 제출해야 한다고 말하지만, 저장소 근거상 자동화 스크립트나 issue 등록 도우미는 보이지 않습니다. 따라서 결과물은 issue에 바로 붙여넣기 좋은 콘텐츠로 보되, 자동 등록 기능까지 보장된다고 생각하면 안 됩니다.

에이전트에 어느 정도의 repo 접근 권한을 줘야 하나요?

관련 기능 영역과 인접 모듈을 살펴볼 수 있을 정도는 줘야 합니다. 접근 범위가 너무 좁으면 이 스킬의 가장 큰 장점이 약해집니다. 접근이 제한된다면 파일 경로, 아키텍처 메모, 대표 코드 스니펫이라도 제공해 write-a-prd가 구체적인 근거를 바탕으로 추론할 수 있게 하세요.

write-a-prd 스킬 개선 방법

해결책 구호가 아니라 문제 진술을 더 날카롭게 주세요

가장 흔한 실패 패턴은 사용자 문제 대신 솔루션 이름으로 시작하는 것입니다. 더 좋은 입력은 다음을 설명합니다:

• 누가 막혀 있는지,
• 그들이 무엇을 하려는지,
• 현재 무엇이 실패하는지,
• 왜 지금 중요한지.

이런 정보가 있어야 write-a-prd가 “add X feature”보다 훨씬 나은 Requirements Planning 결과를 만들 수 있습니다.

제약은 초반에 명시적으로 못 박으세요

좋은 PRD는 초안 전에 제약이 드러날수록 강해집니다. 스킬에 다음을 미리 알려주세요:

• 성능 한계,
• 하위 호환성,
• 보안 규칙,
• rollout 일정,
• analytics 요구사항,
• 테스트 기대 수준.

이 정보가 없으면 그럴듯하지만 실제로는 쓰기 어려운 해결안이 나올 수 있습니다.

미해결 의사결정을 드러내라고 요청하세요

첫 초안이 너무 단정적으로 보인다면, write-a-prd에게 다음을 분리해서 보여달라고 하세요:

• 확정된 결정,
• 가정,
• 열린 질문,
• 나중으로 미룬 선택지.

이 방법은 팀 리뷰에 더 유용한 결과물로 바꾸는 가장 빠른 방법 중 하나입니다.

repo 탐색 단계를 더 탄탄하게 만드세요

“I reviewed the codebase”라는 말만 믿고 넘어가지 마세요. 다음을 구체적으로 요청하세요:

• 실제로 확인한 파일이나 모듈,
• 현재 동작에서 발견한 사실,
• 기존 아키텍처로부터 추론한 제약,
• 당신의 초기 요청과 repo 현실 사이의 불일치.

이렇게 해야 write-a-prd의 안내를 더 신뢰할 수 있습니다.

모듈 설계 결과를 더 강하게 만드세요

모듈 단계는 쉽게 피상적으로 끝날 수 있습니다. 제안된 각 모듈마다 다음을 포함해 달라고 요청하세요:

• 책임,
• 인터페이스 형태,
• 의존성,
• 왜 얕은 모듈이 아니라 깊은 모듈이어야 하는지,
• 독립 테스트가 필요한지 여부.

이렇게 해야 PRD가 제품 설명문을 넘어 실제 구현과 연결되는 문서가 됩니다.

첫 번째 PRD 초안 이후 반드시 한 번 더 다듬으세요

첫 초안이 최종본이 되는 경우는 드뭅니다. 좋은 개선 루프는 다음과 같습니다:

1. 빠진 제약이 없는지 검토하고,
2. 모호한 섹션을 표시하고,
3. 과하게 비대한 해결안을 의심해 보고,
4. non-goals와 성공 기준을 추가로 요청하고,
5. 약한 섹션만 다시 생성합니다.

대개 “전체 PRD를 다시 써줘”보다 이런 식의 표적 수정이 더 좋은 결과를 냅니다.

팀에서 요구하는 섹션은 명시적으로 추가하세요

이 스킬은 가볍기 때문에 팀의 하우스 스타일이 기본 포함되어 있다고 기대하면 안 됩니다. 팀에서 다음 섹션을 기대한다면:

• non-goals,
• rollout plan,
• metrics,
• risks,
• migration,
• support impact,

프롬프트에 직접 넣으세요. write-a-prd는 유연하지만, 요청하지 않으면 필요한 거버넌스 섹션을 전부 알아서 만들어주지는 않습니다.

이런 흔한 실패 패턴을 주의하세요

write-a-prd 결과물에서 자주 보이는 문제는 다음과 같습니다:

• 문제를 명확히 하기 전에 구현으로 뛰어드는 것,
• repo 근거가 부족한 것,
• 모듈 경계가 얕은 것,
• 테스트 기대치가 빠진 것,
• 기능 설명은 있지만 성공 조건이 없는 PRD.

대부분은 스킬을 버려야 해서가 아니라, 입력을 더 잘 주고 후속 리뷰를 더 엄격하게 하면 해결됩니다.