product-capability

product-capability 개요

product-capability는 애매한 제품 의도를 구현 가능한 capability plan으로 바꾸는, 기획에서 스펙으로 이어지는 skill입니다. 기능 목표는 이미 정해졌지만, 코드 작성 전에 제약, 인터페이스, 라이프사이클 규칙, 데이터 영향, 미결정 사항을 더 명확히 해야 할 때 가장 유용합니다.

가장 잘 맞는 경우: 아직 너무 모호한 PRD

PRD, 로드맵 항목, 창업자 메모, 제품 스레드가 있더라도 엔지니어링 관점의 형태가 아직 드러나지 않았다면 product-capability skill을 쓰세요. 특히 멀티 서비스 작업, 팀 간 의존성, 또는 리뷰어가 “이걸 만들기 전에 정확히 무엇이 성립해야 하나요?”라고 계속 묻는 기능에서 효과적입니다.

일반적인 프롬프트보다 더 주는 것

단순한 “스펙을 작성해 줘” 프롬프트와 달리, product-capability는 지속 가능한 capability contract를 중심으로 설계됩니다. 제품 약속과 구현 제약을 분리하고, 추측하지 말고 미해결 질문을 드러내며, 채팅 기록 속에 묻히지 않고 세션을 넘어 재사용할 수 있는 산출물을 만드는 데 초점이 있습니다.

설치할 가치가 있는 경우

리뷰 사이클마다 팀이 숨은 가정을 다시 발견하느라 시간을 많이 쓴다면 product-capability install을 설치할 만합니다. 반대로 작업이 대부분 단일 파일 수준이고 리스크가 낮거나, 이미 강한 기존 아키텍처 문서로 충분히 정의되어 있다면 이 skill은 가벼운 프롬프트보다 가치가 낮을 수 있습니다.

product-capability skill 사용법

워크스페이스에 설치하고 로드하기

다음 명령으로 skill을 설치하세요:

npx skills add affaan-m/everything-claude-code --skill product-capability

그다음에는 먼저 SKILL.md를 여세요. product-capability usage를 사용할 때는 저장소가 기대하는 지속적인 제품 컨텍스트 파일도 함께 확인해야 합니다. 특히 PRODUCT.md, docs/product/, 또는 program-spec 디렉터리를 살펴보세요. 그런 파일이 없다면 skill이 참조하는 템플릿 경로를 사용하세요.

대충 쓴 요청을 강한 입력으로 바꾸기

이 skill은 기능 이름만 던질 때보다, 제품 목표와 배경 맥락까지 함께 줄 때 가장 잘 작동합니다. “팀 공유 기능 추가”처럼 약한 브리프는 빈칸이 너무 많습니다. 더 강한 브리프는 이렇습니다. “웹과 API 전반에서 팀 공유 capability plan을 설계하되, 권한, 감사 이벤트, 초대 라이프사이클, 워크스페이스가 다운그레이드될 때의 동작까지 포함해 주세요.”

Requirements Planning을 위한 product-capability 권장 워크플로

먼저 제품 진술부터 시작한 다음, capability의 경계, 불변 조건, 가정, 미해결 질문, 구현상 영향을 요청하세요. 가장 좋은 product-capability guide 출력은 단순한 기능 목록이 아니라, 작업이 시작되기 전에 무엇이 사실이어야 하는지를 설명합니다. 요청 범위가 서비스나 팀을 넘는다면, 소유권과 계약 경계를 명시적으로 짚어 달라고 하세요.

먼저 읽고, 그다음 확장하기

이 저장소는 의도적으로 가볍게 구성되어 있으므로, 가장 먼저 읽을 만한 파일은 SKILL.md입니다. 여기서 규칙과 산출물의 목표를 이해한 뒤, 예시를 그대로 복사하지 말고 자신의 repo 구조에 맞게 조정하세요. 이미 환경에 표준 product 문서 위치가 있다면, 병렬 계획 파일이 생기지 않도록 그 경로에 맞춰 출력을 정렬하는 것이 좋습니다.

product-capability skill FAQ

product-capability는 PRD에만 쓰나요?

아니요. product-capability skill은 로드맵 항목, 논의 노트, 창업자 방향성에도 잘 맞습니다. 핵심은 의도를 구현 가능한 계약으로 옮길 만큼의 제품 신호가 있고, 그 제약을 억지로 지어내지 않아도 된다는 점입니다.

일반적인 프롬프트 작성과 무엇이 다른가요?

일반 프롬프트는 요약이나 초안 계획을 만들어낼 수 있습니다. 반면 product-capability는 범위가 더 좁습니다. 엔지니어링에 중요한 사실을 보존하고, 미지의 부분을 명시하며, 재사용 가능한 산출물을 만들도록 설계되어 있습니다. 그래서 놓친 제약의 비용이 큰 경우에 더 적합합니다.

초보자도 쓰기 쉬운가요?

네, 기능과 그 맥락을 설명할 수 있다면 충분합니다. product-capability를 쓰는 데 아키텍처 전문 지식은 필요하지 않지만, 아는 사실을 가능한 한 정확히 제공해야 합니다. 중요한 입력을 빼면 출력도 결국 검토가 필요합니다.

언제는 쓰지 말아야 하나요?

사소한 작업, 독립적인 UI 수정, 또는 상세 스펙이 이미 지배하는 업무에는 product-capability를 쓰지 마세요. 마케팅 문구처럼 다듬어진 카피나 구현 코드가 목적일 때도 Requirements Planning 자료로는 맞지 않습니다.

product-capability skill 개선 방법

가장 중요한 사실부터 넣기

품질을 가장 크게 끌어올리는 방법은 사용자에게 보이는 동작, 시스템 경계, 알려진 제약을 처음부터 명확히 적는 것입니다. 데이터 흐름, 접근 규칙, 롤백 기대치, 의존 시스템, 그리고 구현을 바꿀 수 있는 정책이나 컴플라이언스 이슈를 포함하세요.

암시하지 말고 미지의 부분을 드러내기

강한 product-capability 입력은 확인된 요구사항과 열린 질문을 분리합니다. 어떤 작업이 동기식인지, 감사 로그가 필요한지, 진실의 원본(source of truth)을 어느 서비스가 소유하는지 아직 결정되지 않았다면, 그 사실을 직접 적으세요. 그래야 skill이 불확실성을 매끈하게 덮어버리지 않습니다.

의사결정 가능한 산출물을 요청하기

초안이 너무 넓다면, 범위를 좁히고, 절대 바뀌면 안 되는 항목을 나열하고, 설계 결정을 막는 트레이드오프를 강조해 달라고 요청하세요. 이런 식으로 반복하면 더 많은 세부사항을 어디든 추가해 달라고 하는 것보다 product-capability usage 출력이 대체로 더 좋아집니다.

같은 capability 프레임을 재사용하기

반복되는 제품 업무라면 세션마다 같은 capability 구조를 유지해서 리뷰어가 계획을 일관되게 비교할 수 있게 하세요. 입력이 팀의 실제 운영 모델을 더 잘 반영할수록, product-capability skill은 일반적인 계획 문구가 아니라 실제로 쓸모 있는 가이드를 더 잘 만들어냅니다.