제품 역량은(는) 무엇을 하나요?
이 스킬은 제품 의도를 명시적인 엔지니어링 제약 조건으로 변환합니다.
"무엇을 구축해야 하는가?"가 아니라 "구현을 시작하기 전에 정확히 무엇이 참이어야 하는가?"라는 간극이 있을 때 사용하세요.
사용 시기
- PRD, 로드맵 항목, 논의 또는 창업자 메모가 존재하지만 구현 제약 조건이 여전히 암묵적인 경우
- 기능이 여러 서비스, 리포지토리 또는 팀에 걸쳐 있으며 코딩 전에 역량 계약이 필요한 경우
- 제품 의도는 명확하지만 아키텍처, 데이터, 수명 주기 또는 정책 영향이 여전히 모호한 경우
- 시니어 엔지니어가 리뷰 중에 동일한 숨겨진 가정을 계속 반복하는 경우
- 다양한 환경과 세션에서 재사용 가능한 아티팩트가 필요한 경우
표준 아티팩트
리포지토리에 PRODUCT.md, docs/product/ 또는 프로그램 사양 디렉토리와 같은 지속적인 제품 컨텍스트 파일이 있는 경우 해당 위치를 업데이트하세요.
역량 매니페스트가 아직 존재하지 않는 경우 다음 템플릿을 사용하여 생성하세요:
docs/examples/product-capability-template.md
목표는 또 다른 계획 스택을 만드는 것이 아닙니다. 목표는 숨겨진 역량 제약 조건을 지속적이고 재사용 가능하게 만드는 것입니다.
불가침 규칙
- 제품 진실을 임의로 만들지 마세요. 미해결 질문을 명시적으로 표시하세요.
- 사용자에게 보이는 약속과 구현 세부 사항을 분리하세요.
- 고정 정책, 아키텍처 선호 사항, 여전히 열려 있는 사항을 명확히 구분하세요.
- 요청이 기존 리포지토리 제약 조건과 충돌하는 경우, 무마하지 말고 명확히 알리세요.
- 분산된 임시 노트보다 하나의 재사용 가능한 역량 아티팩트를 선호하세요.
입력
필요한 것만 읽으세요:
- 제품 의도
- 이슈, 논의, PRD, 로드맵 노트, 창업자 메시지
- 현재 아키텍처
- 관련 리포지토리 문서, 계약, 스키마, 라우트, 기존 워크플로우
- 기존 역량 컨텍스트
PRODUCT.md, 설계 문서, RFC, 마이그레이션 노트, 운영 모델 문서
- 전달 제약 조건
- 인증, 결제, 규정 준수, 출시, 하위 호환성, 성능, 리뷰 정책
핵심 워크플로우
1. 역량 재진술
요청을 하나의 정확한 문장으로 압축하세요:
- 사용자 또는 운영자가 누구인지
- 이 기능이 출시된 후 어떤 새로운 역량이 존재하는지
- 그 결과 어떤 결과가 변경되는지
이 문장이 약하면 구현이 표류할 것입니다.
2. 역량 제약 조건 해결
구현 전에 유지되어야 하는 제약 조건을 추출하세요:
- 비즈니스 규칙
- 범위 경계
- 불변 조건
- 신뢰 경계
- 데이터 소유권
- 수명 주기 전환
- 출시/마이그레이션 요구 사항
- 실패 및 복구 기대치
이러한 것들은 종종 시니어 엔지니어의 기억 속에만 존재합니다.
3. 구현 대면 계약 정의
SRS 스타일의 역량 계획을 생성하세요:
- 역량 요약
- 명시적 비목표
- 행위자 및 표면
- 필요한 상태 및 전환
- 인터페이스/입력/출력
- 데이터 모델 영향
- 보안/결제/정책 제약 조건
- 관찰 가능성 및 운영자 요구 사항
- 구현을 막는 미해결 질문
4. 실행으로 전환
정확한 핸드오프로 종료하세요:
- 직접 구현 준비 완료
- 먼저 아키텍처 검토 필요
- 먼저 제품 명확화 필요
필요한 경우 다음 ECC 네이티브 레인을 가리키세요:
project-flow-opsworkspace-surface-auditapi-connector-builderdashboard-buildertdd-workflowverification-loop
출력 형식
다음 순서로 결과를 반환하세요:
CAPABILITY
- 한 문단 재진술
CONSTRAINTS
- 고정 규칙, 불변 조건 및 경계
IMPLEMENTATION CONTRACT
- 행위자
- 표면
- 상태 및 전환
- 인터페이스/데이터 영향
NON-GOALS
- 이 레인이 명시적으로 소유하지 않는 것
OPEN QUESTIONS
- 여전히 필요한 차단 요소 또는 제품 결정
HANDOFF
- 다음에 수행할 작업과 이를 처리해야 할 ECC 레인
좋은 결과
- 제품 의도가 이제 중간 PR에서 숨겨진 제약 조건을 재발견하지 않고 구현하기에 충분히 구체화되었습니다.
- 엔지니어링 검토가 메모리나 Slack 컨텍스트에 의존하는 대신 지속적인 아티팩트를 가집니다.
- 결과 계획이 Claude Code, Codex, Cursor, OpenCode 및 ECC 2.0 계획 표면에서 재사용 가능합니다.