PRD 가져오기 (Get PRD)
개요
get-prd는 모호한 요청을 한 번의 연속 패스로 승인된 PRD로 전환합니다. 일반적으로 별도로 실행되는 세 가지 워크플로우를 병합합니다.
- 설계 트리 인터뷰 (Design-tree interviewing) — 모든 결정을 트리로 매핑하고, 라운드별로 프론티어를 작업하며, 각 질문에 추천을 제공합니다. 이는 인터뷰가 산만해지지 않고 수렴하도록 만드는 메커니즘입니다.
- 의도 추출 (Intent extraction) — 모든 단계에서 명시적인 신뢰도 수치와 함께 사용자가 실제로 원하는 것을 캡처합니다(사용자가 원해야 한다고 생각하는 것이 아님). 이는 에이전트가 조용히 공백을 채우는 것을 막는 규율입니다.
- 명세 작성 (Spec authoring) — 경계, 성공 기준, 승인 게이트가 포함된 구조화된 산출물에 요구사항을 기록합니다. 이는 다운스트림 계획에서 사용하는 전달물입니다.
이들을 병합하는 이유는 분리하면 맥락이 손실되기 때문입니다. 인터뷰가 하나의 스킬이고 명세 작성이 다른 스킬이면, 두 번째 스킬은 빈 상태로 시작합니다. 즉, 첫 번째 스킬이 이미 배운 내용을 다시 묻거나, 결코 주어지지 않은 답변을 조용히 가정합니다. 오래된 요약본에서 작성된 PRD는 PRD가 없는 것보다 더 나쁩니다. 권위적으로 보이기 때문입니다.
병합의 두 가지 결과는 다음과 같으며, 둘 다 의도적입니다.
- 이 스킬은 깁니다. 다른 스킬에 위임하지 않고 세 단계 모두의 전체 방법론을 포함합니다. 단계를 순서대로 따르십시오. 템플릿으로 건너뛰지 마십시오.
- 이 스킬은 인터뷰를 절대 위임하지 않습니다. 인터뷰 메커니즘은 여기에 있습니다. 질문을 하기 위해 다른 스킬을 호출하지 마십시오.
출력물은 docs/PRD.md (또는 docs/prd/<name>.md)에 저장된 포괄적인 PRD로, 사용자가 승인했으며 get-tasks 및 get-design에서 사용할 준비가 되었습니다.
새 사용자나 초기 단계 컨셉의 경우, get-prd는 아이디어 정제 발견 렌즈, 비기능적 제약 조건 매핑, 핵심 엔터티/데이터 관계 정의를 문서에 직접 통합하므로 별도의 스키마 또는 정제 스킬이 필요하지 않습니다.
사용 시기
다음과 같은 경우 이 스킬을 사용하십시오.
- 사용자가 새 애플리케이션, 시스템, 기능 또는 중요한 변경을 시작하고 요구사항 문서가 아직 존재하지 않는 경우
- 사용자가 "PRD 가져와", "bikin PRD", "buat PRD", "mau bikin sistem baru", 또는 "mau develop X"라고 말하는 경우
- 사용자가 명세를 위해 심문, 인터뷰 또는 스트레스 테스트를 요청하는 경우
- 요청이 관례적이고 불완전하게 명시된 경우 ("대시보드 만들어 줘", "더 빠르게 만들어") 그리고 '완료'가 무엇을 의미하는지 명시할 수 없는 경우
- 하루 이상 걸릴 무언가를 계획하거나 구축하려고 하고, 서면 요구사항이 존재하지 않는 경우
사용하지 말아야 할 경우:
- 버그 수정, 오타 수정, 이름 변경 및 기계적 작업
- PRD 또는 명세가 이미 존재하고 사용자가 그중 작은 부분만 변경하려는 경우 — 문서를 직접 수정하십시오.
- 순수한 정보 요청 ("이게 어떻게 작동하나요?")
- 사용자가 명시적으로 문서 작성을 건너뛰고 구축을 바로 시작하려는 경우 — 이를 존중하되, 위험을 한 번 표시하십시오.
- 비대화형 컨텍스트 (CI 파이프라인, 예약된 실행, 자율 루프). 이 스킬은 실시간 응답 사용자가 필요합니다. 비대화형 컨텍스트에서 요청이 불완전하게 명시된 경우, 추측하는 대신 차단 요인으로 플래그를 지정하십시오.
프로세스
get-prd는 8단계로 실행됩니다. 각 단계에는 종료 조건이 있습니다. 종료 조건이 충족되지 않은 단계로 넘어가지 마십시오.
0. 범위 게이트 (Scope gate) -> 이것은 하나의 기능입니까? 아니면 여러 개입니까?
1. 가설 시드 (Hypothesis seed) -> 그들이 원하는 것이 무엇이고, 나는 얼마나 확신하는가?
2. 트리 구축 (Build the tree) -> 어떤 결정이 존재하며, 프론티어에는 어떤 것이 있는가?
3. 라운드 질문 (Round questions) -> 프론티어를 한 라운드씩 질문하십시오.
4. 의도 프로브 (Intent probe) -> 원하는 것 vs. 원해야 하는 것
5. 재진술 (Restate) -> 사용자의 언어로 다시 말하십시오.
6. 간극 확인 (Gap check) -> 인터뷰에서 생성되지 않은 PRD에 필요한 것은 무엇인가?
7. 작성 및 게이트 (Write and gate) -> PRD, 그리고 명시적인 승인
인터뷰어를 위한 보편적 원칙
- 자연어 매칭: 항상 사용자가 선호하는 언어로 대화하십시오. 사용자가 인도네시아어로 대화를 시작하면 (예: "bikin PRD aplikasi absensi"), 인터뷰 전체를 인도네시아어로 따뜻하게 진행하면서 표준 업계 기술 용어 (acceptance criteria, schema, endpoint, payload)는 그대로 유지하십시오. 사용자가 영어로 말하면 영어로 진행하십시오. 다른 언어로 요청한 사용자에게 영어 인터뷰를 강요하지 마십시오.
- 공감적이고 위협적이지 않은 어조: 사용자는 종종 날것이고 형성되지 않은 아이디어를 가지고 옵니다. 기술 용어가 부족하다고 심문하거나 부족함을 느끼게 하지 마십시오. 인내심을 가지고 안내하십시오. 그들의 비즈니스 문제를 기술적 선택으로 변환하고 항상 권장 답변 (
-> Rekomendasi: ...)을 첨부하여 사용자가 처음부터 브레인스토밍할 필요 없이 반응만 하면 되도록 하십시오. - 모호한/초기 아이디어를 위한 3가지 황금 질문: 사용자가 짧은 한 문장 아이디어를 제시할 때 (예: "mau bikin SaaS seperti Notion untuk resep masakan"), 기술 스택을 논의하기 전에 세 가지 인간 중심 축을 중심으로 프론티어를 고정하십시오.
- 대상 페르소나 및 컨텍스트: 누가, 어디서, 어떤 상황에서 사용합니까?
- 북극성 사용자 여정: 이 애플리케이션에서 반드시 성공해야 하는 처음부터 끝까지의 가장 중요한 실행 흐름은 무엇입니까?
- MVP 범위 지정: 첫날에 반드시 있어야 하는 기능과 의도적으로 다음 단계로 미루는 기능은 무엇입니까?
0단계: 범위 게이트 (Scope Gate)
대부분의 요청은 하나의 기능을 설명합니다. 만약 그렇다면 한 줄로 말하고 1단계로 이동하십시오. 이 단계는 예외를 위해 존재합니다.
감지. 하나의 요청이 독립적으로 테스트 가능한 여러 기능을 묶을 때는 아무것도 작성하기 전에 분해하십시오.
- 요청이 고유한 소비자 또는 데이터 (identity, billing, notifications, reporting)를 가진 별개의 기능을 명명하는 경우
- 수락 기준이 별도로 제공되고 검증될 수 있는 그룹으로 클러스터링되는 경우
- 하나의 기능이 다른 기능의 요구사항을 다시 작성하지 않고 잘리거나 대체될 수 있는 경우
감지되면 인터뷰 라운드 전에 기능 맵을 제안하십시오. 작고 검토 가능해야 합니다. 프로젝트 계획이 아닌 모듈 테이블과 구축 순서입니다.
# 기능 맵: [이니셔티브 이름]
| 모듈 ID | 책임 | 의존 대상 |
|---|---|---|
| identity | 계정, 세션, SSO | - |
| billing | 요금제, 청구서, 결제 | identity |
| notifications | 이메일 및 웹훅 팬아웃 | identity |
| reporting | 사용량 대시보드 | billing, notifications |
구축 순서: identity -> billing, notifications -> reporting
맵의 규칙:
- 안정적인 모듈 ID. 케밥-케이스로 한 번 선택하고 절대 이름을 바꾸지 마십시오. 다운스트림 계획은 이 ID로 작업을 선택합니다.
- 의존성 방향, 순환 없음. 화살표는 한 방향을 가리킵니다. 두 모듈이 서로를 필요로 하면 하나의 모듈입니다.
- 인터페이스는 경계에 있습니다. 맵은
billing이identity에 의존함을 기록합니다. 둘 사이의 계약은 제공자 모듈의 PRD에 속합니다.
맵은 게이트됩니다. 단일 모듈에 대해 인터뷰하기 전에 모듈 경계, 의존성 방향, 구축 순서를 승인하도록 사용자에게 요청하십시오. 맵을 잘못 만드는 것은 비용이 많이 듭니다. 열 줄을 검토하는 것은 그렇지 않습니다.
그런 다음 1-7단계를 모듈별로 구축 순서대로 한 번씩 실행하여 각각 고유한 docs/prd/<module-id>.md를 생성하십시오. 여러 모듈 이니셔티브에 대해 단일체 PRD를 작성하지 마십시오.
종료 조건: 요청이 단일 기능이거나(명시적으로 언급), 기능 맵이 승인되었습니다.
1단계: 가설 시드 (Hypothesis Seed)
무엇이든 묻기 전에, 요청에 대한 현재 이해와 정직한 신뢰도 수치를 기록하십시오.
HYPOTHESIS: 당신은 스탠드업 미팅에서 "우리는 어떻게 지내고 있나요?"라는 질문에 답할 방법을 원하며, "대시보드"가 떠오른 관습이었습니다.
CONFIDENCE: ~30% - 누구를 위한 것인지, "메트릭"이 여기서 무엇을 의미하는지, 성공이 어떻게 보이는지 알 수 없음
규칙:
- 가설은 한 문장으로 작성하십시오. 한 문장으로 쓸 수 없다면 아직 이해가 안 된 것입니다.
- 신뢰도 수치는 0에서 100까지의 백분율입니다. 정직을 강제합니다. 다음 세 가지 질문에 대한 사용자의 반응을 예측할 수 없다면 숫자가 잘못된 것입니다.
- ~70% 미만이면 같은 줄에 아직 해결되지 않은 사항을 명명하는 짧은 이유를 추가하십시오. 이는 인터뷰가 무엇을 표면화해야 하는지 사용자에게 정확히 알려줍니다.
- 각 라운드 후에 가설과 신뢰도를 업데이트하십시오.
종료 조건: 신뢰도 수치가 포함된 가설이 기록되었습니다.
2단계: 설계 트리 구축 (Build the Design Tree)
무엇이든 묻기 전에 결정 공간을 매핑하십시오. 모든 결정은 그에 딸린 결정으로 분기됩니다.
목표: 개인 실험 추적기
|
+-- 무엇이 실험으로 간주됩니까? (단위 정의)
| |
| +-- 하나를 설명하는 필드는 무엇입니까? (스키마 범위 지정)
|
+-- 데이터는 어디에서 오나요? (입력 소스)
| |
| +-- 수동 입력입니까, 가져오기입니까? (상호작용 모델)
|
+-- 실험은 언제 "완료"됩니까? (수명 주기)
|
+-- 어떤 신호가 종료합니까? (성공 정의)
프론티어는 전제 조건이 이미 해결된 모든 결정, 즉 아직 듣지 못한 답변을 추측하지 않고 지금 질문할 수 있는 질문입니다.
이것이 작동하게 만드는 두 가지 규칙:
- 한 라운드에 전체 프론티어를 질문하십시오. 여러 질문이 독립적일 때 한 번에 하나씩 묻지 마십시오. 독립적인 질문은 함께 더 빨리 답변되며, 사용자는 결정 공간의 형태를 볼 수 있습니다.
- 답변이 다른 미해결 질문에 의존하는 질문은 이후 라운드에 속합니다. 지금 묻는 것은 잘못된 프레이밍을 고정시킵니다.
사실은 사용자의 일이 아니라 여러분의 일입니다. 프론티어 질문에 환경(파일 시스템, 기존 코드, 라이브러리의 API, 설정 값)의 사실이 필요하면 하위 에이전트를 보내 찾으십시오. 스스로 찾을 수 있는 것을 사용자에게 묻지 마십시오. 이를 위해 라운드를 차단하지 마십시오: 탐색은 해결되지 않은 전제 조건이므로, 그 아래에 있는 질문들만 기다립니다. 나머지 프론티어는 지금 질문하십시오. 결정은 사용자의 몫입니다. 사실은 여러분의 몫입니다.
종료 조건: 트리가 매핑되고 첫 번째 프론티어가 식별되었습니다.
3단계: 라운드 질문 (Round Questions)
현재 프론티어를 질문하십시오. 각 질문의 형식은 정확히 다음과 같아야 합니다.
**Q1 - <질문 제목>**: <질문 본문, 여러 문단일 수 있으며, 종종 후보 옵션이 제시됨>
-> <추천 답변 및 이를 생성한 추론>
규칙:
- 모든 질문에 번호를 매기십시오.
Q1,Q2, ... 라운드별로 번호를 다시 매기십시오. - 항상 추천을 첨부하십시오. 사용자는 잘못된 추천에 처음부터 답변을 생성하는 것보다 더 빠르게 반응합니다. 또한 눈에 띄게 틀릴 수 있는 가설에 스스로를 고정시킵니다.
- 답변을 기다렸다가 다음 라운드를 질문하십시오.
- 각 라운드 후에 프론티어를 다시 계산하십시오. 해결된 결정은 프론티어를 바깥쪽으로 밀고 그에 의존했던 질문을 차단 해제합니다.
- 수정 사항을 기록하십시오. 사용자가 추천을 무시할 때, 결정과 추론을 모두 기록하십시오. PRD의 "기술 결정" 섹션이 이를 참조하기 때문입니다.
추천이 중요한 이유와 그 실패 모드:
- 사용자는 잘못된 추측에 몇 초 만에 반응할 수 있지만, 무에서 답변을 생성하는 데는 몇 분이 걸릴 수 있습니다.
- 여러분의 가정을 표면화하며, 이것이 인터뷰의 요점입니다.
- 위험은 아첨입니다. 정중한 사용자가 기분 좋게 하기 위해 여러분의 추측에 동의하는 것입니다. 눈에 띄게 틀릴 의향이 있고, 때때로 사용자가 반발할 것으로 예상되는 방향을 추천함으로써 이를 완화하십시오. 모든 추천이 첫 번째 시도에 수락되면 아첨을 의심하십시오.
한 번에 모든 것을 묻지 않고 한 번에 한 라운드씩 묻는 이유:
- 세 번째 질문은 종종 첫 번째 질문에 대한 답변에 의존합니다. 한 번에 모든 것을 묻는 것은 잘못된 프레이밍을 고정시킵니다.
- 신중하게 생각하는 사용자의 에너지는 유한합니다. 라운드별로 사용하십시오.
- 열다섯 개의 질문 배치는 설문조사로 읽히며, 인터뷰가 아닙니다. 대충 훑어보게 됩니다.
종료 조건: 라운드의 질문에 답변이 완료되고 프론티어가 재계산되었습니다.
4단계: 의도 프로브 (Intent Probe) (원하는 것 vs. 원해야 하는 것)
가장 위험한 답변은 사용자가 실제로 원하는 것이 아니라 사려 깊은 답변처럼 들리는 것을 말하는 경우입니다. 다음을 주의하십시오.
- 구체적인 내용 없이 모범 사례 이야기와 패턴 매칭되는 답변 ("확장 가능하기를 원해요", "클린 아키텍처")
- 관습에 따르는 답변 ("대부분의 앱이 하는 방식", "표준 접근 방식")
- "아마 ~해야지...", "~해야 하는 것 같은데...", "좋은 엔지니어링 관행에 따르면..."과 같은 표현
- 목표로 사용되는 유행어 — "현대적인", "확장 가능한", "견고한"이 구체적인 결과 대신 답변인 경우
이러한 표현이 들리면 다음과 같이 질문하십시오.
"누구에게도 이것을 정당화할 필요가 없다면, 실제로 원하는 것은 무엇입니까?"
이 한 가지 질문은 종종 이전 다섯 가지 질문보다 더 많은 효과를 냅니다. 정교함을 암시하는 답변이 나타날 때마다 적어도 한 번은 실행하십시오. 말한 답변과 프로브된 답변을 모두 기록하십시오. PRD는 두 번째 것을 반영해야 합니다.
종료 조건: 정교함을 암시하는 답변이 나타난 경우 프로브가 적어도 한 번 실행되었고, 실제 답변이 기록되었습니다.
5단계: 의도 재진술 (Restate Intent)
트리가 거의 확정되었을 때, 사용자가 원한다고 생각하는 것을 다시 작성하십시오. 간결하게 유지하고, 사용자의 언어를 사용하며, 사용자가 한 줄씩 확인하거나 수정할 수 있도록 구성하십시오.
제가 이해하기로 당신이 원하는 것은 다음과 같습니다.
- 결과: <한 줄>
- 사용자: <한 줄 - 누가 혜택을 받는가>
- 이유: <한 줄 - 무엇이 바뀌었는가>
- 성공: <한 줄 - 어떻게 작동했는지 아는가>
- 제약: <한 줄 - 묶이는 제한>
- 범위 외: <한 줄 - 명시적으로 하지 않는 것>
예 / 아니오 / 수정?
규칙:
- "범위 외"는 협상 불가입니다. 불일치의 절반은 무엇을 구축하지 않는지에 대한 묵시적인 의견 차이입니다.
- 총 5~8줄입니다. 더 길면 인터뷰가 끝나지 않은 것입니다.
- 가능하면 사용자의 단어를 사용하십시오. 그들의 어휘가 공유 계약입니다.
종료 조건: 사용자의 언어로 된 구체적인 재진술이 기록되었습니다.
중단 조건 (The Stop Condition)
다음 두 가지 모두가 참일 때 인터뷰가 완료된 것입니다.
- 다음에 물어볼 세 가지 질문에 대한 사용자의 반응을 예측할 수 있습니까? 그렇다면 공유된 이해가 있는 것입니다.
- 프론티어가 완전히 비어 있습니까? 더 이상 질문할 결정이 없음을 의미합니다. 결정 공간이 완전히 매핑되었습니다.
두 조건 중 하나라도 충족되지 않으면 3단계로 돌아가서 새로운 프론티어를 질문하십시오.
6단계: 간극 확인 (Gap Check)
인터뷰가 완료되면 생성된 정보와 표준 PRD가 포함해야 하는 것 사이의 간극을 확인하십시오. 일반적인 누락 사항은 다음과 같습니다.
- 비기능적 요구사항: 성능 (응답 시간, 처리량), 보안 (인증, 권한 부여, 데이터 암호화), 가용성, 확장성, 유지보수성
- 기술 스택 결정: 언어, 프레임워크, 데이터베이스, 인프라, 타사 서비스. 인터뷰에서 이에 대해 논의하지 않았다면, 지금 기본값을 제안하거나 결정하기 위해 질문하십시오.
- 데이터 모델: 핵심 엔터티, 그들의 속성 및 관계. 이는
core entity / data relationship definitions로, 종종 스키마 또는 ER 다이어그램으로 캡처됩니다. - 에지 케이스 및 오류 처리: 사용자가 기대한 시나리오 외에 잘못될 수 있는 상황 (네트워크 오류, 잘못된 입력, 동시성 문제, 빈 상태).
- 종속성 및 통합 지점: 이 시스템이 의존하는 외부 시스템, API, 라이브러리 및 그들과의 계약.
- 마일스톤 및 로드맵 (MVP 이후): 초기 범위 이후의 추가 기능 또는 단계. MVP에만 집중하더라도 향후 방향을 아는 것은 현재 설계 결정에 영향을 미칩니다.
이러한 각 간극에 대해: 사용자가 이미 결정을 내렸다면 문서화하십시오. 그렇지 않다면, 기본값을 제안하거나 (신뢰도가 높은 경우) 추가 라운드 질문을 하십시오.
종료 조건: 모든 표준 PRD 섹션에 대한 정보가 있거나 누락된 정보가 명시적으로 연기되었습니다 ("향후 고려"로 표시).
7단계: 작성 및 게이트 (Write and Gate)
PRD를 구조화된 마크다운 파일로 작성하고 사용자에게 명시적인 승인을 요청하십시오.
파일 위치 및 명명 규칙:
- 단일 기능 요청의 경우:
docs/PRD.md - 여러 모듈 이니셔티브 (0단계에서 분해됨)의 경우:
docs/prd/<module-id>.md(예:docs/prd/identity.md)
PRD 템플릿:
다음 구조를 사용하되, 인터뷰에서 나온 정보로 각 섹션을 채우십시오. 모든 섹션이 인터뷰에서 명시적으로 다루어지지 않았다면 "결정 보류" 또는 "향후 고려 사항"으로 표시하고 추측하지 마십시오.
# PRD: [프로젝트/모듈 이름]
## 1. 개요
- **목표:** <한 줄 요약>
- **배경:** <이것이 왜 필요한지, 무슨 문제를 해결하는지>
- **성공 기준:** <어떻게 작동했는지 아는 방법, 측정 가능한 결과>
## 2. 대상 사용자
- **주요 사용자:** <누가 주로 사용하는가>
- **사용 사례:** <핵심 상호작용 흐름>
## 3. 범위
### 포함
- <기능 목록>
### 제외
- <명시적으로 범위를 벗어난 사항>
## 4. 기능 요구사항
- **F1:** <설명, 수락 기준>
- **F2:** <설명, 수락 기준>
## 5. 비기능 요구사항
- **성능:** <예: 페이지 로드 < 2초>
- **보안:** <예: HTTPS, RBAC>
- **가용성:** <예: 99.9% 가동 시간>
## 6. 기술적 결정
- <인터뷰에서 이루어진 주요 결정과 근거>
## 7. 데이터 모델
- <핵심 엔터티, 속성, 관계>
## 8. 종속성
- <외부 시스템, 라이브러리, API>
## 9. 향후 고려 사항
- <연기된 기능 또는 결정>
## 10. 승인
> **상태: ❓ 승인 대기 중**
>
> 위 내용을 검토하고 **예 / 아니오 / 수정**으로 응답해 주십시오.
> 예라고 응답하면 문서가 최종 확정되고 다운스트림 작업에 사용할 수 있습니다.
게이트:
- 명시적인 "예" 응답을 받을 때까지 PRD는 초안 상태입니다 (
상태: ❓ 승인 대기 중). - 사용자가 "아니오"라고 말하면, 불일치 사항을 명확히 하기 위해 인터뷰로 돌아가십시오.
- 사용자가 수정을 요청하면, 변경하고 다시 승인 요청을 하십시오.
- 승인 후
상태: ✅ 승인됨으로 업데이트하십시오.
종료 조건: PRD가 작성되어 docs/PRD.md (또는 해당 경로)에 저장되었으며, 사용자가 명시적으로 승인했습니다.
PRD 예시
예시 1: 작업 추적기 (간단한 단일 기능)
docs/PRD.md
# PRD: 작업 추적기
## 1. 개요
- **목표:** 사용자가 개인 작업을 생성, 보고, 완료 표시할 수 있는 간단한 작업 추적기.
- **배경:** 사용자는 여러 프로젝트에서 작업을 관리하기 위해 가볍고 복잡하지 않은 방법을 원합니다. 기존 도구는 너무 과합니다.
- **성공 기준:** 사용자가 작업을 생성하고, 보류 중 및 완료된 작업 목록을 보고, 작업을 완료로 표시할 수 있습니다.
## 2. 대상 사용자
- **주요 사용자:** 프리랜서 및 소규모 팀.
- **사용 사례:** 사용자가 새 작업을 추가하고, 모든 미완료 작업을 보고, 완료 시 작업을 체크합니다.
## 3. 범위
### 포함
- 작업 생성 (제목, 설명, 기한)
- 작업 목록 보기 (필터링: 모두, 보류 중, 완료됨)
- 작업을 완료됨으로 표시
- 작업 삭제
### 제외
- 사용자 계정/인증 (로컬 전용)
- 팀 협업 또는 할당
- 우선 순위 또는 태그
- 알림
## 4. 기능 요구사항
- **F1:** 사용자는 "제목"(필수), "설명"(선택), "기한"(선택) 필드가 있는 양식을 통해 작업을 생성할 수 있습니다.
- **F2:** 기본 보기에는 완료되지 않은 모든 작업이 최신순으로 표시됩니다.
- **F3:** 사용자는 확인란을 클릭하여 작업을 완료됨으로 표시할 수 있으며, 작업은 보기에서 사라집니다.
- **F4:** 사용자는 작업을 삭제할 수 있습니다 (삭제 전 확인).
## 5. 비기능 요구사항
- **성능:** 작업 목록 로드 < 1초.
- **보안:** 해당 없음 (로컬 전용).
- **가용성:** 오프라인에서 작동해야 함.
## 6. 기술적 결정
- **스토리지:** LocalStorage (간단하고 오프라인 지원).
- **프레임워크:** 바닐라 JavaScript (의존성 없음, 배우기 쉬움).
## 7. 데이터 모델
- **작업:** `{ id: string, title: string, description: string, dueDate: string | null, completed: boolean, createdAt: timestamp }`
## 8. 종속성
- 없음.
## 9. 향후 고려 사항
- 카테고리/태그
- 데이터 내보내기
## 10. 승인
> **상태: ❓ 승인 대기 중**
>
> 위 내용을 검토하고 **예 / 아니오 / 수정**으로 응답해 주십시오.
> 예라고 응답하면 문서가 최종 확정되고 다운스트림 작업에 사용할 수 있습니다.
예시 2: 알림 시스템 (여러 모듈, 인도네시아어 인터뷰)
이 예시는 여러 모듈과 인도네시아어 인터뷰를 보여줍니다. 0단계는 다음과 같은 기능 맵을 생성했을 것입니다.
# 기능 맵: 알림 시스템
| 모듈 ID | 책임 | 의존 대상 |
|---|---|---|
| notif-core | 알림 큐, 기본 템플릿, 전송 상태 추적 | - |
| notif-channel-email | SMTP/API를 통한 이메일 전송 | notif-core |
| notif-prefs | 사용자 알림 기본 설정 UI | notif-core |
구축 순서: notif-core -> notif-channel-email, notif-prefs
첫 번째 모듈의 PRD: docs/prd/notif-core.md
# PRD: notif-core
## 1. 개요
- **Tujuan:** Membangun antrian notifikasi internal, penjadwalan, dan tracking status pengiriman. Fondasi untuk semua channel notifikasi ke depannya.
- **Latar Belakang:** Saat ini aplikasi tidak memiliki mekanisme terpusat untuk mengirim notifikasi ke user. Setiap fitur mengimplementasikan cara kirim notifikasi masing-masing, menyebabkan duplikasi kode dan kesulitan pelacakan.
- **Kriteria Sukses:**
- Sistem dapat menerima permintaan notifikasi dari modul lain via API internal.
- Notifikasi diantrekan dan dikirim secara asynchronous.
- Status pengiriman setiap notifikasi tercatat (pending, sent, failed).
- Sistem mampu menangani minimal 100 notifikasi per detik.
## 2. Pengguna
- **Pengguna Utama:** Modul internal lain (e.g., modul pembayaran, modul aktivitas akun).
- **Use Case:** Modul pembayaran mengirim notifikasi "Pembayaran berhasil" ke notif-core. Notif-core mengantrekan dan mengirimkannya ke channel yang sesuai.
## 3. Lingkup
### Termasuk
- Internal REST API untuk menerima permintaan notifikasi (tipe notifikasi, data, target user).
- Antrian internal (in-memory atau Redis).
- Mekanisme retry otomatis untuk notifikasi gagal.
- Tracking status pengiriman (pending, sent, failed) dengan timestamp.
### Tidak Termasuk
- Channel spesifik (email, push notification, SMS). Ini akan dibangun di modul terpisah.
- User interface untuk log notifikasi.
- Scheduled/delayed notifications (akan ditambahkan nanti).
## 4. Persyaratan Fungsional
- **F1:** Modul internal lain dapat mengirim permintaan notifikasi ke `POST /api/v1/notifications` dengan payload `{ type: string, data: object, userId: string }`.
- **F2:** Permintaan yang valid akan langsung menghasilkan response `202 Accepted` dengan `notificationId`, dan notifikasi akan diproses secara asynchronous.
- **F3:** Sistem akan mencoba mengirim notifikasi ke semua channel yang terdaftar. Jika gagal, akan meretry maksimal 3 kali dengan jeda eksponensial.
- **F4:** Status pengiriman dapat dicek via `GET /api/v1/notifications/{id}/status`.
## 5. Persyaratan Non-Fungsional
- **Kinerja:** Menerima dan mengantrekan 100 notifikasi/detik (P95 < 100ms).
- **Keandalan:** Tidak ada notifikasi yang hilang. Antrian harus durable (gunakan Redis atau database).
- **Keamanan:** Endpoint internal hanya bisa diakses dari dalam jaringan (tidak terekspos ke publik).
## 6. Keputusan Teknis
- **Antrian:** Redis (sederhana, cepat, sudah ada di infrastructure).
- **Worker:** Background worker (pada Node.js, bisa menggunakan Bull/BullMQ).
- **Penyimpanan Status:** Gunakan database PostgreSQL (tabel `notifications`).
## 7. Model Data
- **notifications:** `{ id: uuid, userId: uuid, type: string, data: jsonb, status: enum('pending', 'sent', 'failed'), createdAt: timestamp, updatedAt: timestamp }`
- **notification_attempts:** `{ id: uuid, notificationId: uuid, channel: string, status: enum('success', 'failed'), errorMessage: text, attemptedAt: timestamp }`
## 8. Dependensi
- Redis (untuk antrian)
- PostgreSQL (untuk penyimpanan status dan tracking)
## 9. Pertimbangan Masa Depan
- Notifikasi terjadwal.
- Prioritas notifikasi.
- Webhook untuk notifikasi real-time.
## 10. Persetujuan
> **Status: ❓ Menunggu Persetujuan**
>
> Silakan review document di atas dan respon dengan **Ya / Tidak / Revisi**.
> Jika Ya, dokumen ini akan difinalisasi dan siap digunakan untuk perencanaan downstream.
이 예시는 get-prd가 인도네시아어로 진행된 인터뷰를 처리하고, 범위 게이트를 통해 여러 모듈을 식별하며, 각 모듈에 대한 구조화된 PRD를 생성하는 방법을 보여줍니다.
저자 및 유지 관리자
- 작성자: Rizqi N. (~rizqinrr)
관련 스킬
get-tasks— 이 스킬에 의해 생성된 PRD를 사용하여 실행 가능한 작업을 생성합니다.get-design— 이 스킬에 의해 생성된 PRD를 아키텍처 및 UI 설계에 사용합니다.