판단력을 길러 주는 제품 관리 스킬을 쓰고 관리하기

## 이유와 예시를 남겨 사용자의 판단력 길러 주기 ### 두 대상 모두 지원하기 제품 관리 스킬은 실무자가 유용한 작업을 완료하고 전문성을 높이는 데 도움이 되어야 합니다. 모든 스킬을 판단력을 기르는 사람과 워크플로를 실행하는 에이전트 모두를 위해 설계하세요. 한쪽을 위해 다른 쪽을 희생하는 방식으로 최적화하지 마세요. 권고 사항을 신뢰하고 설명하며 다른 상황에 적용할 수 있도록 워크플로 이면의 추론을 충분히 드러내세요. 사용자는 완성된 결과물을 받는 데 그치지 않고, 어떤 접근법이 왜 효과적인지 이해해야 합니다. ### 학습 구조 보호하기 - 건전한 결정을 내리는 데 필요한 추론이 사라진다면 설명을 줄이지 마세요. - 명시적인 안티패턴을 보존하세요. 이는 사용자가 실제 상황에서 무엇을 알아보고 피해야 하는지 가르쳐 줍니다. - 최종 결과뿐 아니라 추론 과정을 보여 주는 예시를 사용하세요. - 전문 용어가 처음 등장할 때 정의하고 상충 관계를 명시하세요. - 코칭 계층을 없애지 않으면서 워크플로를 실용적이고 에이전트가 실행할 수 있는 상태로 유지하세요. 효율성을 높일 때는 교훈, 예시, 실패 양상을 없애기 전에 반복, 군더더기, 부수적인 배경부터 제거하세요. 어떤 구절이 이해를 돕는 발판인지 불필요한 내용인지 분명하지 않다면 그 기능을 이해할 때까지 유지하세요. ### 다양한 상황에서 품질 입증하기 근거가 어떻게 결정으로 이어지는지 보여 주는 구체적인 예시를 하나 이상 포함하세요. 충분히 개발된 스킬에는 재사용 가능한 템플릿과, 소프트웨어 서비스 및 물리적 사업이나 운영 중심 사업처럼 유의미하게 다른 두 가지 비즈니스 환경의 완성된 예시를 추가하세요. 가상의 조직과 데이터를 사용하세요. ## 스킬마다 폴더를 따로 두고 자동으로 만든 목록은 손으로 고치지 않기 ### 정본 소스와 파생 결과물 분리하기 각 스킬을 일관된 이름의 전용 폴더에 두고, 정본 스킬 문서 하나와 스킬별 지원 자산 또는 스크립트를 함께 보관하세요. 재사용 가능한 오케스트레이션 명령은 개별 스킬과 분리해 저장하세요. 연구 자료, 사용자 문서, 미리보기 애플리케이션, 릴리스 결과물은 관리 주체가 명확한 별도 영역에서 유지하세요. 생성된 카탈로그, 인덱스, 패키지 사본, 배포 번들은 파생 산출물로 취급하세요. 이를 직접 편집하지 말고 정본 소스에서 다시 생성하세요. 스킬 폴더 이름에는 소문자 kebab-case를 사용하고 폴더 이름을 스킬에 선언된 이름과 일치시키세요. 가능하면 안정적인 경로를 유지하세요. 필요한 경우에만 스킬 이름을 변경하고, 그 뒤 모든 참조를 업데이트하세요. ### 소유권 경계 따르기 콘텐츠를 편집하기 전에 어느 리포지토리나 워크스페이스가 해당 콘텐츠를 소유하는지 확인하세요. 공유 라이브러리, 제품별 플레이북, 배포 리포지토리는 서로를 참조하면서도 각기 다른 정본을 가질 수 있습니다. 소유 위치에서 작업하고, 작업이 해당 경계를 명시적으로 변경하지 않는 한 다른 위치는 읽기 전용 참조로 취급하세요. 익숙한 디렉터리 이름만으로 구조를 추론하지 마세요. 구조를 결정하기 전에 해당 리포지토리의 정의, 기여 규칙, 스크립트, 기존 예시를 확인하세요. ### 가장 구체적인 기능 찾기 제품 관리 지침을 임의로 만들기 전에 사용 가능한 스킬을 살펴보고 가장 구체적으로 일치하는 것을 선택하세요. 일반적인 영역에는 탐색, Jobs to Be Done, 페르소나, 제품 전략, 우선순위 지정, 로드맵, 요구 사항 문서, 사용자 스토리, 인수 기준, 인공지능 제품 업무, 에이전트 워크플로, 이해관계자 조율이 포함됩니다. 이를 일반적인 소프트웨어 엔지니어링 작업이 아니라 코칭과 결과물 생성 워크플로로 다루세요. ## 스킬마다 예시와 흔한 실수를 넣고 질문은 한 번에 하나씩 하기 ### 일관된 문서 계약 사용하기 각 스킬에 목적, 입력, 핵심 개념, 적용, 예시, 일반적인 함정, 참고 자료와 같은 명확한 순서를 부여하세요. frontmatter에는 name, description, type 필드를 포함하세요. 대상 플랫폼에서 이러한 제한을 적용하는 경우 name은 64자 이내, description은 200자 이내로 유지하세요. 명확한 Markdown 제목과 짧은 문단을 사용하세요. 펜스로 묶인 코드 블록에는 언어 식별자를 추가하세요. 글은 간결하고 분명한 관점을 담되 필요한 추론, 조건, 예시를 희생하지 마세요. ### 입력을 관문이 아닌 초대로 만들기 입력 섹션에서는 사용자가 제공할 수 있는 내용을 쉬운 말로 설명하고 호출 예시를 포함해야 합니다. 요청에 이미 제공된 정보는 이미 답변된 것으로 취급하세요. 초기 입력은 일부만 있거나 전혀 없어도 허용하세요. 사용자를 막는 대신 안내형 흐름에서 누락된 정보를 수집하는 방법을 설명하세요. 지원되지 않는 환경에서 문자 그대로 표시될 실행 환경 전용 자리표시자나 템플릿 구문은 피하세요. ### 대화형 흐름을 의도적으로 설계하기 대화형 스킬에서는 다음을 따르세요. - 한 번에 질문 하나를 하거나 작고 일관된 질문 묶음을 사용하세요. - 각 답변이 다음 질문을 결정하게 하세요. - 상황에 맞는 다음 단계 권고를 번호와 함께 제시하세요. - 번호로 선택하는 방식과 사용자 지정 입력을 모두 허용하세요. - 사용자의 선택에 따라 관련 경로가 달라지면 워크플로를 조정하세요. 숨겨진 가정 없이 스킬 자체로 완결되고 에이전트가 사용할 수 있게 하세요. 명시적인 안티패턴을 하나 이상 포함하고 왜 실패하는지 설명하세요. ## 공유하기 전에 스킬 모음의 도구로 내용과 링크 확인하기 ### 라이브러리 자체의 검증 경로 사용하기 임시방편의 검사보다 리포지토리에 문서화된 탐색, 검증, 패키징, 전체 라이브러리 테스트 도구를 우선하세요. 변경 사항을 제출하기 전에 파일 탐색과 대상이 명확한 참조 검색을 사용하여 스킬 위치와 상호 참조를 확인하세요. 정본 스킬 경로가 유효한지, 메타데이터가 올바른지, 필수 섹션이 있는지, 예시와 참고 자료가 정확한지, 링크가 일관성을 유지하는지 검증하세요. 자동 테스트를 사용할 수 없다면 검증하지 않은 성공을 주장하지 말고 이러한 항목을 수동으로 확인하세요. 유지 관리되는 진입점을 통해 패키지 빌더와 카탈로그 생성기를 실행하세요. 미리보기 애플리케이션이 변경되었다면 관련 로컬 미리보기 경로를 실행하고 해당 문서를 확인하세요. ### 호환성과 안전한 자동화 유지하기 필요한 경우 파일 이름의 대소문자를 정확히 맞추는 것을 포함하여 플랫폼별 패키징 요구 사항을 준수하세요. 워크플로가 네트워크 접근을 명시적으로 요구하고 통제하는 경우가 아니라면 지원 스크립트를 결정론적이고 문서화된 상태로 유지하며 네트워크에 접근하지 않게 하세요. 스크립트와 패키징된 콘텐츠를 공유하거나 실행하기 전에 안전성을 검토하세요. 관리되는 마켓플레이스, 플러그인, 호환성 파일이 무관해 보인다는 이유만으로 제거하지 마세요. 정본 소스를 수정하는 대신 생성된 릴리스 결과물을 편집하지 마세요. ### 실제 정본 확인하기 카테고리, 스킬 유형, 패키지 구조를 변경하기 전에 로컬 기준과 관련 정본 스킬에 근거해 결정하세요. 개인적인 관례보다 유지 관리되는 검증 도구와 리포지토리 도구에서 얻은 근거를 우선하세요. 요청된 작업이 다른 리포지토리에 속한다면 현재 경계에서 쓰기를 중단하고 변경 작업을 소유 주체의 소스로 돌리세요. 참고 자료는 작업에 정보를 제공할 수 있지만 편집 대상이 되어서는 안 됩니다. ## 변경은 작게 하고 공개 전에 체크리스트로 확인하기 ### 검토하기 쉬운 기여 준비하기 변경 사항은 작고 유지 관리하기 쉬우며 명시된 목적의 범위 안에 있도록 하세요. 명확한 명령형 커밋 제목을 사용하세요. 검토 요청에는 변경 사항 요약, 관련 이슈 링크, 스킬 유형, 의미 있는 호환성 또는 동작 변경 사항이 포함되어야 합니다. 스킬을 추가하거나 이름을 바꿀 때는 카탈로그 항목, 개수, 표, 경로, 상호 링크를 업데이트하세요. 릴리스 전에 모든 참조가 유효한지 확인하세요. ### 완전한 릴리스 점검표 적용하기 - 정본 스킬 폴더와 메타데이터를 검증하세요. - 다운로드 가능한 패키지와 생성된 카탈로그를 소스에서 다시 빌드하세요. - 예시, 참고 자료, 탐색 링크가 계속 정확한지 확인하세요. - frontmatter 구문과 플랫폼별 패키지 사본을 검증하세요. - 미리보기 애플리케이션이 변경되면 인터페이스 문서와 릴리스 노트를 업데이트하세요. - 생성된 결과물, 무관한 파일, 의도하지 않은 광범위한 치환이 변경 사항에 들어가지 않았는지 확인하세요. ### 교육적 성과를 최종 기준으로 사용하기 릴리스 준비가 된 스킬은 교육적이고, 에이전트가 실행할 수 있으며, 자체 완결적이고, 실용적입니다. 여기에는 추론, 완성된 예시 하나 이상, 명시적인 안티패턴, 정의된 전문 용어, 드러난 상충 관계가 포함됩니다. 충분히 개발된 스킬에는 재사용 가능한 템플릿과 서로 대비되는 영역의 예시도 포함됩니다. 길이를 줄이기 위한 목적으로만 설명, 안티패턴, 예시를 제거하지 마세요. 스킬이 유용한 결과를 만들고 사용자의 판단력을 강화하며 지원되는 모든 환경에서 유지 관리 가능한 상태를 유지할 때만 릴리스를 승인하세요.