| name | product-capability |
| description | PRD 의도, 로드맵 요청 또는 제품 논의를 구현 가능한 케이퍼빌리티 계획으로 변환합니다. 다중 서비스 작업 시작 전에 제약 사항, 불변성, 인터페이스 및 미결정 사항을 노출합니다. 사용자가 모호한 계획 산문 대신 ECC 네이티브 PRD-to-SRS 레인이 필요할 때 사용하세요. |
| origin | ECC |
제품 케이퍼빌리티 (Product Capability)
이 스킬은 제품 의도를 명시적인 엔지니어링 제약 사항으로 변환합니다.
"우리가 무엇을 만들어야 하는가?"가 아니라 "구현이 시작되기 전에 정확히 무엇이 사실이어야 하는가?"가 핵심 질문일 때 이 스킬을 사용하세요.
사용 시점
- PRD, 로드맵 항목, 논의 또는 창업자 메모가 존재하지만 구현 제약 사항이 여전히 암시적일 때
- 기능이 여러 서비스, 저장소 또는 팀에 걸쳐 있어 코딩 전에 케이퍼빌리티 계약이 필요할 때
- 제품 의도는 명확하지만 아키텍처, 데이터, 라이프사이클 또는 정책 관련 영향이 여전히 모호할 때
- 시니어 엔지니어들이 리뷰 중에 동일한 숨겨진 가정들을 계속해서 언급할 때
- 다양한 하네스와 세션에서 살아남을 수 있는 재사용 가능한 아티팩트가 필요할 때
표준 아티팩트 (Canonical Artifact)
저장소에 PRODUCT.md, docs/product/ 또는 프로그램 사양 디렉토리와 같은 지속적인 제품 컨텍스트 파일이 있는 경우 거기에서 업데이트하세요.
케이퍼빌리티 매니페스트가 아직 존재하지 않는 경우 다음 템플릿을 사용하여 생성하세요:
docs/examples/product-capability-template.md
목표는 또 다른 계획 스택을 만드는 것이 아닙니다. 숨겨진 케이퍼빌리티 제약 사항을 지속 가능하고 재사용 가능하게 만드는 것입니다.
타협할 수 없는 규칙
- 제품의 진실을 발명하지 마세요. 해결되지 않은 질문은 명시적으로 표시하세요.
- 사용자에게 보이는 약속과 구현 세부 사항을 분리하세요.
- 무엇이 고정된 정책이고 무엇이 아키텍처 선호도이며 무엇이 여전히 미결정인지 명확히 하세요.
- 요청이 기존 저장소 제약 사항과 충돌하는 경우, 이를 얼버무리지 말고 명확하게 말하세요.
- 흩어져 있는 임시 메모보다 하나의 재사용 가능한 케이퍼빌리티 아티팩트를 선호하세요.
입력 정보
필요한 것만 읽으세요:
- 제품 의도
- 이슈, 논의, PRD, 로드맵 노트, 창업자 메시지
- 현재 아키텍처
- 관련 저장소 문서, 계약, 스키마, 라우트, 기존 워크플로우
- 기존 케이퍼빌리티 컨텍스트
PRODUCT.md, 디자인 문서, RFC, 마이그레이션 노트, 운영 모델 문서
- 인도 제약 사항
- 인증, 빌링, 규정 준수, 롤아웃, 하위 호환성, 성능, 리뷰 정책
핵심 워크플로우
1. 케이퍼빌리티 재정의
요청을 하나의 정확한 문장으로 압축하세요:
- 사용자 또는 운영자가 누구인가
- 이것이 출시된 후 어떤 새로운 케이퍼빌리티가 존재하는가
- 그로 인해 어떤 결과가 변하는가
이 문장이 약하면 구현이 빗나갈 수 있습니다.
2. 케이퍼빌리티 제약 사항 해결
구현 전에 반드시 유지되어야 하는 제약 사항을 추출하세요:
- 비즈니스 규칙
- 범위 경계 (Scope boundaries)
- 불변성 (Invariants)
- 신뢰 경계 (Trust boundaries)
- 데이터 소유권
- 라이프사이클 전환
- 롤아웃 / 마이그레이션 요구 사항
- 실패 및 복구 기대치
이것들은 흔히 시니어 엔지니어의 기억 속에만 존재하는 것들입니다.
3. 구현 중심 계약 정의
다음이 포함된 SRS 스타일의 케이퍼빌리티 계획을 작성하세요:
- 케이퍼빌리티 요약
- 명시적인 비목표 (Non-goals)
- 액터 및 표면 (Actors and surfaces)
- 필수 상태 및 전환
- 인터페이스 / 입력 / 출력
- 데이터 모델 영향
- 보안 / 빌링 / 정책 제약 사항
- 관측 가능성 및 운영자 요구 사항
- 구현을 가로막는 미결 질문
4. 실행으로 변환
정확한 핸드오프로 끝내세요:
- 직접 구현 준비 완료
- 아키텍처 리뷰 먼저 필요
- 제품 확인 먼저 필요
유용한 경우 다음 ECC 네이티브 레인을 지목하세요:
project-flow-opsworkspace-surface-auditapi-connector-builderdashboard-buildertdd-workflowverification-loop
출력 형식
결과를 다음 순서로 반환하세요:
CAPABILITY
- 한 문단으로 된 재정의
CONSTRAINTS
- 고정된 규칙, 불변성 및 경계
IMPLEMENTATION CONTRACT
- 액터 (Actors)
- 표면 (Surfaces)
- 상태 및 전환
- 인터페이스/데이터 영향
NON-GOALS
- 이 레인에서 명시적으로 소유하지 않는 것
OPEN QUESTIONS
- 차단 요인 또는 여전히 필요한 제품 결정
HANDOFF
- 다음 단계 및 이를 담당할 ECC 레인
좋은 결과
- 제품 의도가 PR 도중에 숨겨진 제약 사항을 재발견하지 않고도 구현할 수 있을 만큼 구체화됨.
- 엔지니어링 리뷰가 기억에 의존하는 대신 지속적인 아티팩트를 갖게 됨.
- 결과 계획이 Claude Code, Codex, Cursor, OpenCode 및 ECC 2.0 계획 표면 전반에서 재사용 가능함.
