| name | product-capability |
| description | PRD 의도, 로드맵 요청, 제품 논의를 구현 준비가 된 capability plan으로 변환합니다. 다중 서비스 작업이 시작되기 전에 제약, 불변식, 인터페이스, 미해결 결정을 드러내야 할 때 사용합니다. |
| origin | ECC |
Product Capability
이 스킬은 제품 의도를 명시적인 엔지니어링 제약으로 바꿉니다.
질문이 "무엇을 만들어야 하는가?"가 아니라 "구현이 시작되기 전에 정확히 무엇이 참이어야 하는가?"일 때 사용합니다.
사용 시점
- PRD, 로드맵 항목, 논의, 파운더 노트는 있지만 구현 제약이 아직 암묵적일 때
- 기능이 여러 서비스, 저장소, 팀을 가로질러 코딩 전에 capability contract가 필요할 때
- 제품 의도는 분명하지만 아키텍처, 데이터, 라이프사이클, 정책 영향이 아직 흐릴 때
- 시니어 엔지니어들이 리뷰 때마다 같은 숨은 가정을 반복해서 말할 때
- 여러 하니스와 세션을 건너 살아남는 재사용 가능한 산출물이 필요할 때
정식 산출물
저장소에 PRODUCT.md, docs/product/, program-spec 디렉터리 같은 장기 제품 컨텍스트 파일이 있으면 거기에 갱신합니다.
아직 capability manifest가 없다면 다음 템플릿으로 생성합니다.
docs/examples/product-capability-template.md
목표는 또 다른 계획 스택을 만드는 게 아니라 숨은 capability 제약을 장기적이고 재사용 가능하게 만드는 것입니다.
비타협 규칙
- 제품 진실을 지어내지 않습니다. 미해결 질문은 명시적으로 표시합니다.
- 사용자에게 보이는 약속과 구현 세부를 분리합니다.
- 무엇이 고정 정책인지, 무엇이 아키텍처 선호인지, 무엇이 아직 열려 있는지 구분합니다.
- 요청이 기존 저장소 제약과 충돌하면 부드럽게 덮지 말고 명확히 말합니다.
- 흩어진 메모보다 재사용 가능한 capability 산출물 하나를 우선합니다.
입력
필요한 것만 읽습니다.
- Product intent
- issue, discussion, PRD, roadmap note, founder message
- Current architecture
- 관련 repo docs, contracts, schemas, routes, existing workflows
- Existing capability context
PRODUCT.md, design docs, RFCs, migration notes, operating-model docs
- Delivery constraints
- auth, billing, compliance, rollout, backwards compatibility, performance, review policy
핵심 워크플로
1. capability 재진술
요청을 다음이 포함된 한 문장으로 압축합니다.
- 사용자 또는 운영자가 누구인지
- 출시 후 어떤 새 capability가 존재하는지
- 그것 때문에 어떤 결과가 바뀌는지
이 문장이 약하면 구현이 흔들립니다.
2. capability 제약 해석
구현 전에 성립해야 할 제약을 추출합니다.
- business rules
- scope boundaries
- invariants
- trust boundaries
- data ownership
- lifecycle transitions
- rollout / migration requirements
- failure and recovery expectations
이 항목들은 종종 시니어 엔지니어 머릿속에만 남아 있습니다.
3. 구현 지향 계약 정의
다음을 포함한 SRS 스타일 capability plan을 만듭니다.
- capability summary
- explicit non-goals
- actors and surfaces
- required states and transitions
- interfaces / inputs / outputs
- data model implications
- security / billing / policy constraints
- observability and operator requirements
- open questions blocking implementation
4. 실행으로 번역
정확한 handoff 상태로 마무리합니다.
- direct implementation ready
- architecture review needed first
- product clarification needed first
유용하면 다음 ECC 레인을 가리킵니다.
project-flow-ops
workspace-surface-audit
api-connector-builder
dashboard-builder
tdd-workflow
verification-loop
출력 형식
CAPABILITY
- one-paragraph restatement
CONSTRAINTS
- fixed rules, invariants, and boundaries
IMPLEMENTATION CONTRACT
- actors
- surfaces
- states and transitions
- interface/data implications
NON-GOALS
- what this lane explicitly does not own
OPEN QUESTIONS
- blockers or product decisions still required
HANDOFF
- what should happen next and which ECC lane should take it
좋은 결과
- 제품 의도가 이제 PR 중간에서 숨은 제약을 다시 발견하지 않고도 구현 가능할 만큼 구체적이다
- 엔지니어링 리뷰가 기억이나 Slack 맥락이 아니라 장기 산출물에 의존할 수 있다
- 생성된 계획이 Claude Code, Codex, Cursor, OpenCode, ECC 2.0에서 재사용 가능하다