product-capability

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 산출물 하나를 우선합니다.

입력

필요한 것만 읽습니다.

1. Product intent
   • issue, discussion, PRD, roadmap note, founder message
2. Current architecture
   • 관련 repo docs, contracts, schemas, routes, existing workflows
3. Existing capability context
   • PRODUCT.md, design docs, RFCs, migration notes, operating-model docs
4. 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에서 재사용 가능하다