제품 기능 기획

제품 기능 기획은(는) 무엇을 하나요?

이 스킬은 제품 의도를 명시적인 엔지니어링 제약 조건으로 변환합니다.

질문이 "무엇을 구축해야 하는가?"가 아니라 "구현을 시작하기 전에 반드시 참이어야 하는 것은 무엇인가?"일 때 사용하세요.

사용 시기

• PRD, 로드맵 항목, 논의 또는 창업자 노트가 존재하지만, 구현 제약 조건이 여전히 암시적일 때
• 기능이 여러 서비스, 리포지토리 또는 팀에 걸쳐 있어 코딩 전에 기능 계약이 필요할 때
• 제품 의도는 명확하지만, 아키텍처, 데이터, 생애주기 또는 정책 영향이 여전히 모호할 때
• 시니어 엔지니어가 리뷰 중에 동일한 숨겨진 가정을 반복해서 말할 때
• 하네스와 세션에 걸쳐 지속될 수 있는 재사용 가능한 아티팩트가 필요할 때

표준 아티팩트

리포지토리에 PRODUCT.md, docs/product/ 또는 프로그램 사양 디렉토리와 같은 내구성 있는 제품 컨텍스트 파일이 있다면, 거기에 업데이트하세요.

기능 매니페스트가 아직 존재하지 않는다면, 다음 템플릿을 사용하여 생성하세요:

• docs/examples/product-capability-template.md

목표는 또 다른 기획 스택을 만드는 것이 아닙니다. 목표는 숨겨진 기능 제약 조건을 내구성 있고 재사용 가능하게 만드는 것입니다.

불가침 규칙

• 제품 진실을 발명하지 마세요. 미해결 질문을 명시적으로 표시하세요.
• 사용자에게 보이는 약속과 구현 세부 사항을 분리하세요.
• 고정 정책, 아키텍처 선호도, 여전히 열려 있는 사항을 명확히 구분하세요.
• 요청이 기존 리포지토리 제약 조건과 충돌한다면, 부드럽게 넘기지 말고 명확히 말하세요.
• 흩어진 임시 노트보다 하나의 재사용 가능한 기능 아티팩트를 선호하세요.

입력

필요한 것만 읽으세요:

1. 제품 의도
   • 이슈, 논의, PRD, 로드맵 노트, 창업자 메시지
2. 현재 아키텍처
   • 관련 리포지토리 문서, 계약, 스키마, 경로, 기존 워크플로우
3. 기존 기능 컨텍스트
   • PRODUCT.md, 디자인 문서, RFC, 마이그레이션 노트, 운영 모델 문서
4. 전달 제약 조건
   • 인증, 청구, 규정 준수, 롤아웃, 이전 버전과의 호환성, 성능, 리뷰 정책

핵심 워크플로우

1. 기능 재진술

요청을 하나의 정확한 문장으로 압축하세요:

• 사용자 또는 운영자는 누구인가
• 이 기능이 출시된 후 어떤 새로운 기능이 존재하는가
• 어떤 결과가 이로 인해 변경되는가

이 문장이 약하면 구현이 표류할 것입니다.

2. 기능 제약 조건 해결

구현 전에 유지되어야 하는 제약 조건을 추출하세요:

• 비즈니스 규칙
• 범위 경계
• 불변 조건
• 신뢰 경계
• 데이터 소유권
• 생애주기 전환
• 롤아웃/마이그레이션 요구 사항
• 실패 및 복구 기대치

이러한 것들은 종종 시니어 엔지니어의 기억에만 존재하는 것들입니다.

3. 구현 대면 계약 정의

SRS 스타일의 기능 계획을 생성하세요:

• 기능 요약
• 명시적 비목표
• 행위자와 표면
• 필요한 상태와 전환
• 인터페이스/입력/출력
• 데이터 모델 영향
• 보안/청구/정책 제약 조건
• 관찰 가능성 및 운영자 요구 사항
• 구현을 차단하는 열린 질문

4. 실행으로 전환

정확한 핸드오프로 마무리하세요:

• 직접 구현 준비 완료
• 먼저 아키텍처 리뷰 필요
• 먼저 제품 명확화 필요

유용하다면, 다음 ECC 네이티브 경로를 가리키세요:

• project-flow-ops
• workspace-surface-audit
• api-connector-builder
• dashboard-builder
• tdd-workflow
• verification-loop

출력 형식

다음 순서로 결과를 반환하세요:

기능
- 한 문단 재진술

제약 조건
- 고정 규칙, 불변 조건, 경계

구현 계약
- 행위자
- 표면
- 상태와 전환
- 인터페이스/데이터 영향

비목표
- 이 경로가 명시적으로 소유하지 않는 것

열린 질문
- 차단 요소 또는 여전히 필요한 제품 결정

핸드오프
- 다음에 일어나야 할 일과 이를 맡을 ECC 경로

좋은 결과

• 제품 의도가 이제 중간 PR에서 숨겨진 제약 조건을 재발견하지 않고 구현할 수 있을 만큼 구체적입니다.
• 엔지니어링 리뷰가 기억이나 Slack 컨텍스트에 의존하는 대신 내구성 있는 아티팩트를 갖습니다.
• 결과 계획이 Claude Code, Codex, Cursor, OpenCode 및 ECC 2.0 기획 표면에서 재사용 가능합니다.