product-capability

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

목표는 또 다른 계획 스택을 만드는 것이 아닙니다. 숨겨진 케이퍼빌리티 제약 사항을 지속 가능하고 재사용 가능하게 만드는 것입니다.

타협할 수 없는 규칙

• 제품의 진실을 발명하지 마세요. 해결되지 않은 질문은 명시적으로 표시하세요.
• 사용자에게 보이는 약속과 구현 세부 사항을 분리하세요.
• 무엇이 고정된 정책이고 무엇이 아키텍처 선호도이며 무엇이 여전히 미결정인지 명확히 하세요.
• 요청이 기존 저장소 제약 사항과 충돌하는 경우, 이를 얼버무리지 말고 명확하게 말하세요.
• 흩어져 있는 임시 메모보다 하나의 재사용 가능한 케이퍼빌리티 아티팩트를 선호하세요.

입력 정보

필요한 것만 읽으세요:

1. 제품 의도
   • 이슈, 논의, PRD, 로드맵 노트, 창업자 메시지
2. 현재 아키텍처
   • 관련 저장소 문서, 계약, 스키마, 라우트, 기존 워크플로우
3. 기존 케이퍼빌리티 컨텍스트
   • PRODUCT.md, 디자인 문서, RFC, 마이그레이션 노트, 운영 모델 문서
4. 인도 제약 사항
   • 인증, 빌링, 규정 준수, 롤아웃, 하위 호환성, 성능, 리뷰 정책

핵심 워크플로우

1. 케이퍼빌리티 재정의

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

• 사용자 또는 운영자가 누구인가
• 이것이 출시된 후 어떤 새로운 케이퍼빌리티가 존재하는가
• 그로 인해 어떤 결과가 변하는가

이 문장이 약하면 구현이 빗나갈 수 있습니다.

2. 케이퍼빌리티 제약 사항 해결

구현 전에 반드시 유지되어야 하는 제약 사항을 추출하세요:

• 비즈니스 규칙
• 범위 경계 (Scope boundaries)
• 불변성 (Invariants)
• 신뢰 경계 (Trust boundaries)
• 데이터 소유권
• 라이프사이클 전환
• 롤아웃 / 마이그레이션 요구 사항
• 실패 및 복구 기대치

이것들은 흔히 시니어 엔지니어의 기억 속에만 존재하는 것들입니다.

3. 구현 중심 계약 정의

다음이 포함된 SRS 스타일의 케이퍼빌리티 계획을 작성하세요:

• 케이퍼빌리티 요약
• 명시적인 비목표 (Non-goals)
• 액터 및 표면 (Actors and surfaces)
• 필수 상태 및 전환
• 인터페이스 / 입력 / 출력
• 데이터 모델 영향
• 보안 / 빌링 / 정책 제약 사항
• 관측 가능성 및 운영자 요구 사항
• 구현을 가로막는 미결 질문

4. 실행으로 변환

정확한 핸드오프로 끝내세요:

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

유용한 경우 다음 ECC 네이티브 레인을 지목하세요:

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

출력 형식

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

CAPABILITY
- 한 문단으로 된 재정의

CONSTRAINTS
- 고정된 규칙, 불변성 및 경계

IMPLEMENTATION CONTRACT
- 액터 (Actors)
- 표면 (Surfaces)
- 상태 및 전환
- 인터페이스/데이터 영향

NON-GOALS
- 이 레인에서 명시적으로 소유하지 않는 것

OPEN QUESTIONS
- 차단 요인 또는 여전히 필요한 제품 결정

HANDOFF
- 다음 단계 및 이를 담당할 ECC 레인

좋은 결과

• 제품 의도가 PR 도중에 숨겨진 제약 사항을 재발견하지 않고도 구현할 수 있을 만큼 구체화됨.
• 엔지니어링 리뷰가 기억에 의존하는 대신 지속적인 아티팩트를 갖게 됨.
• 결과 계획이 Claude Code, Codex, Cursor, OpenCode 및 ECC 2.0 계획 표면 전반에서 재사용 가능함.