pm-skills 분석

1. 짧은 분석 요약

phuryn/pm-skills는 일반적인 앱 저장소라기보다 AI 에이전트가 제품관리 업무를 더 구조적으로 수행하도록 만드는 “스킬/커맨드 마켓플레이스”에 가깝습니다.

README 기준으로 이 저장소는 9개 PM 플러그인, 68개 스킬, 42개 체인 워크플로우를 제공한다고 설명합니다. GitHub 저장소 화면 기준으로는 약 24k stars, 2.4k forks, 62 commits가 표시됩니다. 루트에는 pm-product-discovery, pm-product-strategy, pm-execution, pm-market-research, pm-data-analytics, pm-go-to-market, pm-marketing-growth, pm-toolkit, pm-ai-shipping 같은 도메인별 플러그인 폴더가 있고, .claude-plugin/marketplace.json이 이들을 하나의 마켓플레이스로 묶습니다. (GitHub)

라이선스는 LICENSE 파일 기준 MIT License입니다. 저작권 표기는 2026년 Pawel Huryn으로 되어 있고, 복제·수정·배포·상업적 이용이 가능하지만 저작권 및 허가 문구를 포함해야 하며 보증은 제공되지 않습니다. (GitHub)

직접 실행 테스트는 하지 않았습니다. 아래 글은 GitHub 페이지, README, LICENSE, marketplace 설정, 플러그인 예시 파일, 검증 스크립트, GitHub Actions 설정을 읽고 작성한 코드/문서 기반 분석입니다.

---

PM 업무를 AI에게 맡기는 게 아니라, PM 사고방식을 파일로 포장한 저장소

처음에는 조금 익숙한 저장소라고 생각했다.

요즘 GitHub에는 AI용 프롬프트 모음이 많다.
“PRD를 써준다.”
“전략을 만들어준다.”
“고객 인터뷰를 요약한다.”
“런칭 플랜을 만든다.”

여기까지는 이제 별로 놀랍지 않다.

그런데 phuryn/pm-skills를 따라가 보니, 이 저장소의 핵심은 프롬프트 모음이 아니었다. 더 정확히는 제품관리 업무를 AI가 따라갈 수 있는 작업 단위로 쪼개고, 그것을 스킬과 커맨드, 플러그인이라는 구조로 패키징한 저장소였다.

말하자면 PM을 위한 “프롬프트 북”이라기보다, AI 에이전트에게 주입하는 제품관리 운영체제의 파일 시스템에 가깝다.

약간 거창하게 들릴 수 있다. README도 실제로 “AI Operating System for Better Product Decisions”라는 표현을 쓴다. 하지만 코드를 보면 이 표현이 아주 허공에 떠 있지는 않다. 적어도 구조만 보면 그렇다. (GitHub)

이 프로젝트는 무엇인가

pm-skills는 Claude Code, Claude Cowork, Codex CLI, 그리고 일부 다른 AI 보조 도구에서 사용할 수 있는 PM 업무용 스킬 마켓플레이스다.

README는 이 저장소를 68개 PM 스킬과 42개 체인 워크플로우를 9개 플러그인으로 묶은 마켓플레이스라고 설명한다. 분야는 제품 발견, 전략, 실행, 시장 조사, 데이터 분석, GTM, 마케팅 성장, PM 도구, AI로 작성된 코드의 출시 점검까지 넓게 잡혀 있다. (GitHub)

여기서 중요한 단어는 “스킬”과 “커맨드”다.

스킬은 특정 PM 업무를 수행하기 위한 지식과 절차다. 예를 들어 prioritize-assumptions는 가설을 Impact × Risk 매트릭스로 정리하고, 어떤 가설을 먼저 검증해야 하는지 판단하도록 돕는다. 실제 SKILL.md에는 ICE, RICE, Opportunity Score 같은 프레임워크가 들어 있고, 사용자가 가설 목록이나 리서치 데이터를 제공하면 이를 먼저 읽으라는 지시도 포함되어 있다. (GitHub)

커맨드는 여러 스킬을 엮은 워크플로우다. 예를 들어 /discover는 아이디어 발산, 가정 식별, 가정 우선순위화, 실험 설계, 디스커버리 플랜 작성까지 이어진다. 이 커맨드는 단순히 “아이디어 10개 내줘”가 아니라, 중간 체크포인트를 두고 사용자가 선택하거나 방향을 바꿀 수 있게 설계되어 있다. (GitHub)

플러그인은 이런 스킬과 커맨드를 도메인별로 묶은 설치 단위다.

이 구분이 꽤 중요하다.
많은 AI 프롬프트 저장소는 “좋은 프롬프트 목록”에서 멈춘다.
이 저장소는 한 단계 더 가서 “업무 흐름”을 파일 구조로 만든다.

저장소를 따라가 보기

루트 구조는 꽤 명확하다.

저장소 최상단에는 .claude-plugin, .docs/images, .github/workflows, tests, 그리고 9개의 pm-* 플러그인 폴더가 있다. GitHub 페이지에서 확인되는 주요 폴더는 다음과 같다. (GitHub)

.claude-plugin/
.docs/images/
.github/workflows/
pm-ai-shipping/
pm-data-analytics/
pm-execution/
pm-go-to-market/
pm-market-research/
pm-marketing-growth/
pm-product-discovery/
pm-product-strategy/
pm-toolkit/
tests/
AGENTS.md
CHANGELOG.md
CLAUDE.md
CONTRIBUTING.md
LICENSE
README.md
validate_plugins.py

일반적인 웹앱 저장소였다면 src, app, server, package.json, pyproject.toml 같은 진입점을 먼저 찾았을 것이다. 그런데 이 저장소에는 그런 형태의 애플리케이션 코드는 중심이 아니다.

핵심 진입점은 두 종류다.

첫 번째는 .claude-plugin/marketplace.json이다. 이 파일은 마켓플레이스의 이름, 버전, 설명, 소유자 정보, 그리고 9개 플러그인의 이름과 경로를 정의한다. 실제 파일에는 pm-product-discovery, pm-product-strategy, pm-execution, pm-market-research, pm-data-analytics, pm-go-to-market, pm-marketing-growth, pm-toolkit, pm-ai-shipping이 등록되어 있다. (GitHub)

두 번째는 각 플러그인 폴더 내부의 .claude-plugin/plugin.json, skills/*/SKILL.md, commands/*.md다.

예를 들어 pm-product-discovery/.claude-plugin/plugin.json은 플러그인 이름, 버전, 설명, 작성자, 키워드, 홈페이지, 라이선스를 담고 있다. 이 플러그인은 제품 발견, 아이디어 발산, 실험, 가정 검증, 기능 우선순위화, 고객 인터뷰 합성을 위한 스킬이라고 설명되어 있다. (GitHub)

이 저장소에서 “코드”라고 부를 만한 부분은 주로 validate_plugins.py다. 이 파일은 각 플러그인의 구조가 규칙을 지키는지 검사한다. plugin.json 필수 필드, 스킬의 YAML frontmatter, 커맨드의 description, README 섹션, 커맨드가 참조하는 스킬의 존재 여부 등을 확인한다. (GitHub)

즉, 제품은 파이썬 코드가 아니라 마크다운 파일들이다.
파이썬은 그 제품이 망가지지 않도록 검사하는 관리 도구다.

설치와 실행 방식

README는 설치 대상을 크게 네 가지로 나눈다.

Claude Cowork에서는 GitHub 마켓플레이스를 추가하는 방식으로 설치한다. Claude Code CLI에서는 claude plugin marketplace add phuryn/pm-skills로 마켓플레이스를 추가한 뒤, 필요한 플러그인을 claude plugin install로 설치한다. Codex CLI도 같은 마켓플레이스 파일을 읽을 수 있다고 설명되어 있으며, codex plugin marketplace add phuryn/pm-skills와 codex plugin add 명령을 안내한다. (GitHub)

다만 README는 중요한 차이도 명시한다.

Codex CLI에서는 스킬은 사용할 수 있지만, Claude식 /slash 커맨드는 Codex slash command로 동작하지 않는다고 설명한다. 대신 사용자가 자연어로 워크플로우를 설명하거나, 커맨드 파일을 읽어 Codex용 스킬로 변환하게 할 수 있다고 안내한다. (GitHub)

Gemini CLI, OpenCode, Cursor, Kiro 같은 도구는 skills/*/SKILL.md를 복사해서 “스킬만” 사용하는 방식으로 설명되어 있다. README는 커맨드가 Claude-specific이라고 선을 긋는다. (GitHub)

이 지점이 이 저장소의 현실적인 경계다.

이 프로젝트는 “어디서나 동일하게 실행되는 앱”이 아니다.
AI 도구별로 해석 가능한 부분이 다르다.
Claude에서는 스킬과 커맨드가 더 자연스럽고, 다른 도구에서는 스킬 문서의 재사용에 가까워진다.

핵심 파이프라인

이 저장소의 파이프라인은 대략 이렇게 흐른다.

사용자는 /discover, /strategy, /write-prd, /plan-launch, /north-star 같은 커맨드를 입력한다. README의 Start Here 섹션도 새 아이디어면 /discover, 전략적 명확성이 필요하면 /strategy, PRD를 쓰려면 /write-prd로 시작하라고 안내한다. (GitHub)

커맨드는 필요한 스킬을 호출한다. /discover의 경우 아이디어 브레인스토밍, 가정 식별, 가정 우선순위화, 실험 설계를 순서대로 수행한다. 중간에 사용자가 어떤 아이디어를 계속 가져갈지 고르게 하고, 최종적으로 디스커버리 플랜을 마크다운 문서로 작성하도록 한다. (GitHub)

스킬은 각 단계의 판단 기준을 제공한다. prioritize-assumptions는 Impact × Risk 매트릭스를 사용하고, 가설별로 Impact와 Risk를 평가한 뒤, 실험이 필요한 항목을 가려낸다. 여기서 실험은 의견이 아니라 행동을 측정해야 하며, 명확한 성공 지표와 임계값이 있어야 한다고 지시한다. (GitHub)

출력은 대부분 문서다. PRD, 디스커버리 플랜, 인터뷰 스크립트, OKR, 로드맵, 테스트 시나리오, 출시 패킷 같은 형태다.

[Inference] 이 저장소의 실제 “런타임”은 Python 서버나 Node 앱이 아니라, Claude Code/Cowork/Codex 같은 에이전트 환경이다. 저장소 자체는 실행 앱이라기보다 에이전트가 읽고 따르는 절차 문서 패키지다.

기술적으로 흥미로운 부분

가장 흥미로운 부분은 모델 API 호출이 아니다.

오히려 이 저장소에는 OpenAI API 키, Anthropic API 키, 데이터베이스 연결, 서버 배포 설정 같은 것은 핵심 구조에 보이지 않는다. README와 확인한 파일 기준으로 외부 API를 직접 호출하는 앱 코드는 중심이 아니다. AI/LLM 의존성은 코드 내부 호출이 아니라 호스트 AI 도구가 이 스킬과 커맨드를 해석한다는 방식으로 존재한다.

기술적으로 더 중요한 것은 형식이다.

스킬은 SKILL.md다.
커맨드는 commands/*.md다.
플러그인은 .claude-plugin/plugin.json으로 식별된다.
마켓플레이스는 .claude-plugin/marketplace.json이 묶는다.

이 구조 덕분에 PM 지식이 “글”로만 남지 않고, 에이전트가 읽을 수 있는 작업 단위가 된다.

validate_plugins.py는 이 구조가 깨지지 않도록 검사한다. 이 스크립트는 plugin.json의 필수 필드, 스킬 frontmatter의 name과 description, 디렉터리명과 스킬명 일치 여부, 커맨드 frontmatter, README의 예상 섹션, 커맨드가 참조하는 스킬의 존재 여부를 확인한다. (GitHub)

GitHub Actions도 이 검증을 CI에 묶는다. .github/workflows/tests.yml은 pull request와 main 브랜치 push에서 Python 3.11과 3.13 매트릭스로 python validate_plugins.py를 실행하고, 이어서 python -m unittest discover -s tests -v를 실행한다. (GitHub)

이건 작지만 중요한 설계다.

마크다운 기반 저장소는 시간이 지나면 쉽게 무너진다. 파일명은 바뀌고, frontmatter는 빠지고, 커맨드는 없는 스킬을 참조한다. 이 저장소는 그 문제를 어느 정도 예상하고 있다.

PM 지식의 “체인화”

README는 커맨드가 서로 이어지도록 설계되었다고 설명한다. 어떤 커맨드가 끝나면 다음에 실행할 만한 관련 커맨드를 제안한다고 되어 있다. (GitHub)

이것이 이 저장소의 제품적 아이디어다.

PM 업무는 단일 문서 생성으로 끝나지 않는다.
아이디어를 냈으면 가정을 찾아야 한다.
가정을 찾았으면 무엇을 먼저 검증할지 골라야 한다.
검증할 것을 골랐으면 실험을 설계해야 한다.
실험 결과가 나오면 PRD, 로드맵, 지표, 출시 계획으로 이어진다.

일반 챗봇에게 “PRD 써줘”라고 하면 그럴듯한 문서가 나온다.
하지만 실제 PM 업무에서는 그 전에 해야 할 일이 있다.

이 저장소는 그 “전에 해야 할 일”을 노골적으로 드러낸다.

특히 /discover는 이 점이 잘 보인다. 커맨드 파일은 사용자가 탐색하려는 것이 기존 제품인지 새 제품인지 먼저 구분하고, 사용자가 이미 알고 있는 것과 이 디스커버리가 어떤 의사결정에 영향을 주는지 묻는다. 이후 아이디어 발산, 가정 식별, 가정 우선순위화, 실험 설계를 거쳐 최종 디스커버리 플랜을 만든다. (GitHub)

이건 단순 템플릿보다 조금 더 강하다.
AI에게 “문서 결과물”이 아니라 “사고 순서”를 주기 때문이다.

pm-ai-shipping이 따로 눈에 띄는 이유

9개 플러그인 중 개인적으로 가장 흥미로웠던 것은 pm-ai-shipping이다.

이 플러그인은 전통적인 PM 업무라기보다, AI가 만든 코드를 출시 가능한 상태로 점검하는 데 초점을 둔다. README는 AI 에이전트가 코드를 빠르게 작성하지만 의도, 권한, 비밀값, 검증 규칙에 대한 기록을 남기지 않는다는 문제의식에서 출발한다고 설명한다. (GitHub)

/ship-check 커맨드를 보면 이 방향이 더 분명하다. 이 커맨드는 앱 문서화, 에이전트 운영 컨텍스트 생성, 보안 감사, 성능 감사, 테스트 커버리지 맵 도출, 최종 shipping packet 작성을 하나의 순서로 묶는다. 문서화가 먼저이고, 감사는 그 문서화된 의도와 실제 구현을 비교하는 방식으로 이어진다. (GitHub)

intended-vs-implemented 스킬은 이 플러그인의 핵심 아이디어를 잘 보여준다. 이 스킬은 일반적인 린터가 코드 내부 일관성은 볼 수 있어도 “원래 의도한 대로 동작하는가”는 알 수 없다고 설명한다. 그래서 permissions.md, architecture.md, variables.md 같은 문서화된 의도를 먼저 읽고, 실제 코드의 enforcement point와 비교하라고 지시한다. (GitHub)

[Inference] 이 부분은 PM 도구라기보다 AI 개발 시대의 리뷰 프로세스에 가깝다. PM이 “기능이 나왔는가”만 보는 것이 아니라, “문서화된 의도와 실제 구현이 일치하는가”를 점검하는 역할로 확장되는 흐름을 반영한다.

좋은 점

첫 번째 장점은 구조화다.

이 저장소는 PM 프레임워크를 단순히 나열하지 않는다. 발견, 전략, 실행, 시장 조사, 데이터 분석, GTM, 마케팅 성장, 도구, AI 출시 점검으로 도메인을 나누고, 각 도메인 안에서 스킬과 커맨드를 분리한다. .claude-plugin/marketplace.json은 이 9개 플러그인을 하나의 설치 가능한 마켓플레이스로 묶는다. (GitHub)

두 번째 장점은 워크플로우 감각이다.

예를 들어 /discover는 한 번에 결과물을 뱉는 커맨드가 아니다. 중간 체크포인트를 두고 사용자가 선택하거나 방향을 바꿀 수 있게 한다. PM 업무에서 중요한 것은 정답 생성보다 의사결정 과정이라는 점을 꽤 잘 반영한다. (GitHub)

세 번째 장점은 유지보수 장치다.

마크다운 기반 스킬 저장소는 쉽게 산만해진다. 그런데 이 저장소는 validate_plugins.py로 스킬과 커맨드의 기본 형식을 검사하고, GitHub Actions에서 Python 3.11과 3.13으로 검증과 unittest를 실행한다. (GitHub)

네 번째 장점은 라이선스다.

MIT License라서 외부 활용, 수정, 배포, 상업적 이용이 비교적 자유롭다. 다만 라이선스 문구와 저작권 고지는 유지해야 하고, 소프트웨어는 “as is”로 제공된다. (GitHub)

아쉬운 점

첫 번째 아쉬움은 실행 환경 의존성이다.

이 저장소는 자체적으로 돌아가는 독립 앱이 아니다. Claude Code, Claude Cowork, Codex CLI 같은 호스트 환경이 필요하다. README도 Codex에서는 Claude식 /slash 커맨드가 그대로 동작하지 않는다고 설명한다. (GitHub)

즉, 사용자는 “저장소를 clone하고 실행”하는 경험이 아니라, “내 AI 도구에 스킬과 플러그인을 설치”하는 경험을 해야 한다. 이 차이를 모르면 처음에 혼란스러울 수 있다.

두 번째는 실제 출력 품질 검증이 저장소만으로는 어렵다는 점이다.

스킬과 커맨드의 구조는 읽을 수 있다. 하지만 특정 회사의 실제 PRD, 고객 인터뷰, A/B 테스트 데이터에 넣었을 때 결과가 얼마나 좋은지는 별도의 실행 테스트가 필요하다.

[Unverified] 나는 이 저장소를 실제 Claude Code나 Codex CLI에 설치해 실행하지 않았다. 따라서 명령 실행 안정성, 실제 응답 품질, 긴 컨텍스트에서의 일관성은 확인하지 못했다.

세 번째는 PM 프레임워크의 해석 문제다.

README는 Teresa Torres, Marty Cagan, Alberto Savoia, Dan Olsen, Roger Martin, Ash Maurya 등 여러 저자의 작업을 참고했다고 설명한다. (GitHub)
이런 프레임워크를 AI 스킬로 옮기는 것은 유용하지만, 동시에 단순화의 위험이 있다. 프레임워크는 맥락 없이 적용하면 체크리스트가 된다.

[Inference] 이 저장소는 숙련 PM에게는 좋은 보조 장치가 될 수 있지만, PM 경험이 거의 없는 사용자가 그대로 따르면 “생각하는 척하는 문서 생산기”가 될 가능성도 있다. 이건 저장소의 결함이라기보다, 모든 프레임워크 자동화 도구가 갖는 위험이다.

실제로 쓰려면 봐야 할 부분

설치 난이도는 사용하는 AI 도구에 따라 달라진다.

Claude Cowork 사용자는 README에 나온 GitHub 마켓플레이스 추가 방식으로 접근할 수 있다. Claude Code 사용자는 CLI 명령으로 마켓플레이스를 추가하고 플러그인을 설치한다. Codex CLI 사용자는 스킬은 활용할 수 있지만 slash command 동작 방식은 다르다. 다른 도구는 skills/*/SKILL.md를 복사해서 쓰는 접근에 가깝다. (GitHub)

환경변수나 API Key는 저장소 자체의 중심 주제는 아니다. 외부 LLM API 호출을 직접 구현한 앱이 아니기 때문이다.

비용은 저장소가 아니라 호스트 AI 도구의 사용량에서 발생한다.

[Inference] 실제 비용은 PRD 생성, 리서치 요약, 대량 피드백 분석, 코드 감사처럼 긴 입력과 긴 출력이 필요한 작업에서 커질 가능성이 있다. 저장소 자체에는 비용 제어 로직이 보이지 않는다.

데이터 저장 방식도 저장소 자체에는 별도 DB가 없다. 출력은 대체로 마크다운 문서나 사용자 워크스페이스에 생성되는 결과물로 설계되어 있다. /discover 커맨드는 최종 discovery plan을 마크다운 파일로 저장하라고 지시한다. (GitHub)

보안 측면에서는 사용자가 어떤 데이터를 AI 도구에 넣는지가 더 중요하다. 고객 인터뷰, NPS 응답, 내부 로드맵, 가격 전략, 경쟁사 분석, 출시 계획은 민감할 수 있다.

[Inference] 팀에서 사용한다면 “어떤 문서를 AI 도구에 넣어도 되는가”에 대한 정책이 먼저 필요하다. 저장소가 MIT라고 해서 입력 데이터의 보안 문제가 사라지는 것은 아니다.

한국어 서비스로 응용한다면

한국어 서비스로 바꾼다면 단순 번역만으로는 부족하다.

PRD, OKR, 로드맵, 고객 인터뷰, GTM, 가격 전략 같은 기본 틀은 그대로 쓸 수 있다. 하지만 한국어 SaaS, 커머스, 교육, 금융, B2B 영업 환경에서는 사용하는 표현과 조직 문화가 다르다.

예를 들어 /plan-launch를 한국 시장용으로 바꾼다면 카카오톡 채널, 네이버 검색, 커뮤니티, 세일즈 미팅, 대기업 보안 검토, 전자계약, 세금계산서 같은 요소를 반영해야 한다.

pm-data-analytics의 SQL 생성이나 cohort 분석도 국내 서비스에서 자주 쓰는 이벤트 네이밍, 결제 주기, 휴면 기준, 광고 채널 구분을 넣으면 더 쓸 만해진다.

[Inference] 한국어 PM 스킬 마켓플레이스를 만든다면 원본 구조는 유지하고, 각 스킬의 예시와 판단 기준을 국내 제품 조직의 업무 언어로 바꾸는 편이 좋다. “번역본”보다 “현지화된 PM 운영 템플릿”에 가깝게 가야 한다.

내가 만든다면 이렇게 바꿀 것 같다

MVP로 줄인다면 전부 가져오지 않을 것이다.

가장 먼저 만들 기능은 세 가지다.

첫째, /discover다.
아이디어에서 가정, 가정에서 실험으로 넘어가는 흐름은 초기 제품팀에 바로 도움이 된다.

둘째, /write-prd와 /red-team-prd다.
PRD를 만드는 것보다 중요한 것은 PRD의 위험한 가정을 찾아내는 것이다. 이 저장소의 pm-execution에는 PRD, OKR, 로드맵, 프리모템, stakeholder map, user stories, test scenarios 같은 실행 관련 스킬과 커맨드가 포함되어 있다. (GitHub)

셋째, /ship-check다.
AI로 코드를 빠르게 만드는 팀이라면 “문서화된 의도와 실제 구현의 차이”를 보는 워크플로우는 꽤 현실적이다. (GitHub)

나중에 붙일 기능은 데이터 분석, GTM, 마케팅 성장이다.
처음부터 모든 PM 업무를 자동화하려고 하면 사용자는 어디서 시작해야 할지 모른다.

제품화한다면 “스킬 목록”보다 “현재 내 상황에서 다음에 할 일”을 추천하는 인터페이스가 중요해 보인다.

예를 들어 사용자가 “새 기능 아이디어가 있다”고 하면 /discover로 보내고, “고객 피드백이 200개 있다”고 하면 /analyze-feedback로 보내고, “출시 전이다”라고 하면 /plan-launch나 /ship-check로 보내는 식이다.

운영 리스크

가장 큰 리스크는 잘못된 확신이다.

AI가 PM 프레임워크를 사용하면 결과물이 논리적으로 보인다. 표도 있고, 우선순위도 있고, 실험도 있고, 성공 기준도 있다. 하지만 그 입력이 부실하면 출력도 부실하다.

두 번째 리스크는 조직 맥락 누락이다.

PM 의사결정은 회사 전략, 팀 역량, 기술 부채, 영업 상황, 고객과의 약속에 묶여 있다. 스킬은 구조를 줄 수 있지만, 회사 내부의 권력 관계와 제약까지 자동으로 알지는 못한다.

세 번째 리스크는 민감 정보다.

고객 인터뷰, 매출 데이터, 가격 전략, 경쟁사 대응, 출시 일정은 외부 AI 도구에 넣기 전에 검토가 필요하다.

네 번째 리스크는 라이선스 오해다.

MIT License는 활용 범위가 넓지만, 보증을 제공하지 않는다. 상업적 활용은 가능하더라도 원 저작권 및 라이선스 고지를 유지해야 한다. (GitHub)

현실성 검토

개인 프로젝트로는 꽤 쓰기 좋다.

특히 혼자 제품을 만들거나, 사이드 프로젝트를 검증하거나, 브런치/블로그/SaaS 아이디어를 정리하는 사람에게는 /discover, /strategy, /north-star, /write-prd 같은 흐름이 도움이 될 수 있다.

팀 내부 도구로도 가능성이 있다.

다만 팀에서 쓰려면 그냥 설치해서 쓰는 것보다, 회사의 PRD 양식, 실험 설계 방식, 데이터 지표 정의, 보안 정책을 반영해 커스터마이즈하는 편이 낫다.

상용 서비스로 확장하려면 한 단계 더 필요하다.

현재 구조는 AI 에이전트용 파일 패키지에 가깝다. 상용 SaaS로 만들려면 사용자 관리, 워크스페이스, 문서 저장소, 권한 관리, 버전 관리, 감사 로그, 입력 데이터 보안, 비용 제어, 결과물 리뷰 플로우가 필요하다.

한국어 서비스로 바꾸려면 번역보다 현지화가 중요하다.

국내 조직에서 쓰는 PRD, OKR, 회의록, 릴리즈 노트, 고객 인터뷰, 영업 자료 양식에 맞게 스킬을 조정해야 한다. 특히 B2B SaaS라면 보안 검토, PoC, 계약, 세금계산서, 고객사 의사결정 구조 같은 항목이 들어가야 한다.

비용은 긴 문서 처리에서 커질 가능성이 있다.

고객 인터뷰 여러 건, 대량 피드백, 큰 코드베이스 감사, 출시 패킷 생성은 토큰 사용량이 커질 수 있다. 이 저장소 자체에는 비용 제한 장치가 보이지 않는다.

유지보수 리스크는 스킬 품질 관리다.

다행히 이 저장소는 validate_plugins.py와 CI를 갖고 있다. 하지만 형식 검증은 내용 품질 검증과 다르다. 좋은 PM 판단을 유지하려면 각 스킬의 예시, 기준, 프레임워크 적용 방식이 계속 업데이트되어야 한다.

다음 생각

이 저장소가 흥미로운 이유는 “AI가 PRD를 써준다”가 아니다.

그건 이제 너무 흔하다.

흥미로운 지점은 PM 업무를 스킬, 커맨드, 플러그인, 마켓플레이스라는 단위로 나누고, AI 에이전트가 따라갈 수 있는 구조로 만든 데 있다.

물론 이 구조만으로 좋은 제품 의사결정이 나오지는 않는다.
나쁜 입력, 얕은 리서치, 조직 맥락 부재는 여전히 문제다.

하지만 적어도 이 저장소는 AI에게 “그럴듯한 문서 하나”를 요구하지 않는다.
대신 이렇게 말한다.

먼저 아이디어를 넓혀라.
그다음 가정을 찾아라.
가장 위험한 가정을 골라라.
실험으로 검증해라.
문서화된 의도와 실제 구현이 맞는지도 봐라.

이 정도면 프롬프트 모음이라고 부르기엔 조금 아깝다.
작은 PM 작업 시스템이라고 부르는 편이 더 정확해 보인다.

---

3. 활용 가능성

이 저장소는 한국어 기술 블로그 콘텐츠로 쓰기 좋습니다. “AI PM 도구”라는 표면보다, PM 지식이 에이전트 실행 단위로 바뀌는 방식을 설명하기 좋습니다.

SaaS 아이디어로도 확장 가능합니다. 예를 들면 “한국어 PM Copilot”, “AI PRD 리뷰어”, “스타트업 디스커버리 워크벤치”, “AI로 만든 코드의 출시 점검 도구” 같은 방향입니다.

교육 서비스로도 맞습니다. PM 주니어에게 단순 템플릿을 주는 대신, 왜 아이디어 다음에 가정을 찾고, 왜 가정 다음에 실험을 설계해야 하는지 실습형으로 가르칠 수 있습니다.

AI 에이전트 서비스로 만들 경우에는 pm-ai-shipping이 특히 좋습니다. AI가 만든 코드의 문서화, 권한 검토, 테스트 커버리지 맵, 출시 패킷 생성은 앞으로 수요가 생길 만한 영역입니다.

---

4. 주의할 점

이 저장소는 독립 실행형 앱이 아닙니다. Claude Code/Cowork, Codex CLI 등 호스트 도구의 동작 방식에 의존합니다.

실제 실행 테스트는 하지 않았기 때문에, 설치 안정성이나 결과 품질은 별도 검증이 필요합니다.

MIT License라 상업적 활용은 가능하지만, 저작권 및 라이선스 고지는 유지해야 합니다. 또한 보증은 제공되지 않습니다. (GitHub)

고객 데이터, 내부 전략, 가격 정책, 코드베이스를 AI 도구에 넣을 때는 회사 보안 정책을 먼저 확인해야 합니다. 특히 팀 내부 도구로 쓰려면 “어떤 데이터를 넣을 수 있는가”를 명확히 해야 합니다.

가장 실용적인 스킬 순위

1. create-prd

무엇을 하는가

아이디어나 기능 설명을 받아 다음 8개 영역의 PRD를 만듭니다.

Summary
Contacts
Background
Objective
Market Segments
Value Propositions
Solution
Release

특히 문제, 대상 사용자, 성공 지표, 핵심 기능, 기술 조건, 검증되지 않은 가정, 출시 범위를 하나의 문서로 정리합니다. 결과가 충분히 크면 PRD-[product-name].md 형태로 저장하도록 설계되어 있습니다. (GitHub)

언제 많이 쓰는가

• 아이디어를 개발팀에 전달할 때
• MVP 범위를 결정할 때
• 기존 기획서를 다시 구조화할 때
• 기능 개발 전에 요구사항을 명확하게 만들 때

StoryMine 적용 예제

pm-execution의 create-prd 스킬을 사용해
StoryMine 보상형 웹소설·웹툰 앱의 MVP PRD를 작성해줘.

대상 사용자:
웹소설과 웹툰을 자주 읽는 18~40세 사용자

핵심 기능:
- 작품 탐색
- 웹소설·웹툰 열람
- 댓글, 좋아요, 공유
- 활동 점수 계산
- 미확정 보상
- INK Point 확정
- 보상 내역
- 부정 이용 탐지

조건:
- 블록체인 토큰은 MVP에서 제외
- 모바일 앱 기준
- 확인되지 않은 내용은 가정으로 분리
- P0, P1, P2로 기능을 구분
- 각 P0 기능에 성공 조건을 작성

예상 결과

P0
- 회원가입 및 로그인
- 작품 목록과 상세 페이지
- 콘텐츠 뷰어
- 정상 읽기 검증
- 일일 활동 점수
- 미확정 보상
- 보상 내역

P1
- 댓글 및 좋아요
- 작품 추천
- 알림

P2
- 토큰 전환
- 외부 지갑
- NFT

분석

이 스킬은 문서 틀을 만드는 데 강하지만, 세부 개발 백로그까지 자동으로 완성하는 스킬은 아닙니다. PRD 작성 뒤에는 user-stories와 test-scenarios를 연결하는 것이 좋습니다.

---

2. identify-assumptions-new

무엇을 하는가

신규 제품이 실패할 수 있는 가정을 다음 8개 영역에서 찾습니다.

Value
Usability
Viability
Feasibility
Ethics
Go-to-Market
Strategy & Objectives
Team

PM, 디자이너, 엔지니어 관점에서 각각 실패 원인을 검토하고, 각 가정의 신뢰도와 검증 방법도 제안합니다. (GitHub)

언제 많이 쓰는가

• 앱 아이디어는 있는데 성공 가능성을 모를 때
• 개발 전에 가장 위험한 요소를 찾을 때
• 블록체인·리워드·AI처럼 불확실성이 큰 서비스
• 투자나 개발 리소스를 투입하기 전

StoryMine 적용 예제

pm-product-discovery의 identify-assumptions-new 스킬로
StoryMine 아이디어의 핵심 가정을 분석해줘.

가정 영역:
- 사용자가 포인트 때문에 실제로 더 많이 읽을 것인가
- 보상이 없어져도 사용자가 계속 남을 것인가
- 정상 읽기와 반복 채굴을 구분할 수 있는가
- 작품 공급 비용과 보상 비용을 감당할 수 있는가
- 작가와 출판사가 이 모델을 받아들일 것인가
- 리워드가 콘텐츠 품질보다 활동량만 늘리지 않는가

각 가정에 대해:
- 가정 내용
- 실패 시 영향
- 현재 신뢰도
- 검증에 필요한 데이터
- 가장 저렴한 검증 방법
을 작성해줘.

예상 결과 예시

영역핵심 가정실패 영향

Value	사용자는 보상 때문에 읽기 빈도를 늘린다	보상 시스템의 존재 이유 상실
Viability	콘텐츠 매출이 보상 비용보다 크다	적자 구조
Feasibility	실제 읽기와 자동 넘기기를 구분할 수 있다	채굴 어뷰징 발생
Ethics	보상 설계가 중독적 사용을 과도하게 유도하지 않는다	사용자·규제 위험
GTM	출판사와 작가가 보상형 유통을 수용한다	콘텐츠 공급 실패

분석

사용자가 진행하는 보상형 앱, 코인 채굴 앱, 거래소 봇처럼 위험 요소가 많은 프로젝트에는 create-prd보다 먼저 실행하는 편이 좋습니다. 기획서를 정교하게 작성했더라도 핵심 가정이 틀리면 전체 설계가 무의미해질 수 있기 때문입니다.

---

3. prioritize-assumptions

무엇을 하는가

앞에서 찾은 가정을 Impact × Risk 기준으로 분류합니다.

낮은 영향 + 낮은 위험 → 나중에 검증
높은 영향 + 낮은 위험 → 구현 진행
낮은 영향 + 높은 위험 → 아이디어 제외 검토
높은 영향 + 높은 위험 → 먼저 실험

실험이 필요한 가정에는 행동 기반 측정법, 성공 지표, 통과 기준을 붙입니다. 저장소는 의견보다 실제 행동을 측정하고, 최소한의 노력으로 검증 학습을 얻도록 지시합니다. (GitHub)

사용 예제

prioritize-assumptions 스킬을 사용해
다음 StoryMine 가정을 우선순위화해줘.

1. 사용자는 포인트를 받으면 하루 읽기 시간이 늘어난다.
2. 사용자는 댓글 보상을 위해 의미 있는 댓글을 작성한다.
3. 정상 읽기와 자동 스크롤을 구분할 수 있다.
4. 출판사는 보상 풀의 일부를 부담할 의사가 있다.
5. 사용자는 포인트를 쿠폰으로 교환하고 싶어 한다.
6. 친구 추천 보상이 신규 사용자를 유입시킨다.

Impact × Risk 매트릭스로 분류하고,
상위 3개에는 가장 저렴한 실험과 통과 기준을 작성해줘.

예상 우선순위

1. 정상 읽기와 자동 채굴을 구분할 수 있는가
2. 보상이 실제 읽기 시간을 증가시키는가
3. 보상 비용을 부담할 수 있는 수익구조가 있는가
4. 쿠폰 교환 수요
5. 친구 추천 효과
6. 댓글 작성 증가

분석

identify-assumptions-new가 위험을 많이 찾는 스킬이라면, prioritize-assumptions는 그중 이번 주에 검증할 것만 고르는 스킬입니다. 두 스킬을 항상 묶어서 사용하는 것이 좋습니다.

---

4. brainstorm-experiments-new

무엇을 하는가

신규 서비스의 핵심 가정을 실제 행동으로 검증할 실험을 설계합니다.

먼저 다음 형태의 XYZ 가설을 만듭니다.

최소 X%의 Y 사용자가 Z 행동을 할 것이다.

그다음 랜딩 페이지, 설명 영상, 이메일 캠페인, 대기자 모집, 선주문, 수동 MVP 등을 사용해 최소 비용으로 검증합니다. 각 실험에는 가설, 방법, 지표, 성공 기준이 포함됩니다. (GitHub)

StoryMine 적용 예제

brainstorm-experiments-new 스킬을 사용해
StoryMine의 핵심 가정을 검증할 실험을 설계해줘.

핵심 가정:
포인트 보상이 있으면 사용자의 주간 콘텐츠 열람 시간이 증가한다.

조건:
- 앱 전체를 개발하지 않는다.
- 2주 이내에 실행 가능해야 한다.
- 설문 응답보다 실제 행동을 측정한다.
- 실험별 비용, 대상 인원, 성공 기준을 표시한다.

예상 실험

실험 1: 수동 보상 실험

대상: 기존 웹소설 독자 30명
기간: 7일
방법:
- 첫 3일은 보상 없이 사용
- 다음 4일은 검증된 읽기 10분당 포인트 지급
측정:
- 일평균 읽기 시간
- 완독률
- 다음 날 재방문율
통과 기준:
- 읽기 시간이 20% 이상 증가
- 보상 기간 재방문율이 15% 이상 증가

실험 2: 랜딩 페이지

보상형 웹소설 앱 소개
→ 가입 대기 명단
→ 보상 방식 선택
→ 실제 가입 전환율 측정

분석

이 스킬은 “좋은 아이디어 같다”는 설문 결과보다 실제 가입, 결제, 시간 투자, 반복 사용 같은 행동을 중시합니다. 개발 비용이 큰 앱일수록 PRD 작성 전에 한 번 실행하는 가치가 큽니다.

---

5. user-stories

무엇을 하는가

PRD의 기능을 개발 가능한 작은 백로그로 분리합니다.

다음 두 기준을 사용합니다.

3 C's
- Card
- Conversation
- Confirmation

INVEST
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable

기본 형식은 다음과 같습니다.

As a [사용자 역할],
I want to [행동],
so that [얻는 가치].

그리고 디자인 링크, 인수 조건, 예외 상황 등을 추가합니다. (GitHub)

StoryMine 예제

pm-execution의 user-stories 스킬을 사용해
StoryMine의 미확정 보상 기능을 개발 가능한 사용자 스토리로 분해해줘.

사용자 역할:
- 일반 독자
- 운영자
- 콘텐츠 관리자

각 스토리에 포함:
- 제목
- 사용자 스토리
- 상세 설명
- 사전 조건
- 인수 조건
- 예외 상황
- API 또는 데이터 요구사항

예상 결과 예시

제목: 읽기 활동에 대한 미확정 보상 확인

사용자 스토리:
독자로서,
나는 정상 읽기로 획득한 미확정 포인트를 확인하고 싶다.
그래야 오늘의 활동이 보상에 반영되었는지 알 수 있다.

인수 조건:
1. 정상 읽기 조건을 충족하면 미확정 포인트가 생성된다.
2. 같은 회차를 반복해서 열어도 중복 지급되지 않는다.
3. 미확정 포인트에는 확정 예정 시간이 표시된다.
4. 부정 이용 검토 중인 포인트는 별도 상태로 표시된다.
5. 검증에 실패한 포인트는 지급되지 않고 사유가 기록된다.

분석

PRD가 “무엇을 만들 것인가”라면 사용자 스토리는 “개발팀이 어느 단위로 만들 것인가”를 정의합니다. Codex에 실제 구현을 맡길 때 특히 중요합니다.

---

6. test-scenarios

무엇을 하는가

사용자 스토리와 인수 조건을 QA가 실행할 수 있는 테스트 시나리오로 변환합니다.

각 테스트에는 다음이 들어갑니다.

Test Objective
Starting Conditions
User Role
Test Steps
Expected Outcomes
Edge Cases

정상 흐름뿐 아니라 잘못된 입력, 경계값, 오류 상황도 포함하도록 설계되어 있습니다. (GitHub)

StoryMine 예제

test-scenarios 스킬을 사용해
다음 사용자 스토리의 테스트 시나리오를 만들어줘.

사용자 스토리:
독자로서 정상 읽기를 완료하면 미확정 포인트를 받고 싶다.

인수 조건:
- 회차의 80% 이상 읽어야 한다.
- 최소 3분 이상 체류해야 한다.
- 동일 회차 보상은 하루 1회만 가능하다.
- 비정상적으로 빠른 페이지 이동은 보상하지 않는다.

테스트 구분:
- 정상 흐름
- 경계값
- 중복 요청
- 네트워크 실패
- 앱 강제 종료
- 자동 스크롤 및 어뷰징
- 서버 시간 조작

예상 시나리오

테스트: 체류 시간 미달

시작 조건:
- 사용자는 로그인 상태
- 해당 회차 보상 이력 없음

절차:
1. 회차를 연다.
2. 콘텐츠의 90%까지 이동한다.
3. 2분 59초 후 회차를 종료한다.
4. 보상 내역을 확인한다.

예상 결과:
- 미확정 포인트가 생성되지 않는다.
- 서버에 체류 시간 미달 사유가 기록된다.
- 사용자에게 조건 미충족 안내가 표시된다.

분석

user-stories → test-scenarios 조합은 기획서와 실제 구현 사이의 해석 차이를 줄여 줍니다. 사용자 요청에서 자주 나오는 “백엔드까지 완벽하게 구현하고 테스트해줘” 같은 작업에는 이 두 스킬을 먼저 적용하는 것이 좋습니다.

---

7. prioritize-features와 prioritization-frameworks

무엇을 하는가

prioritize-features는 기능을 다음 기준으로 평가해 상위 5개를 선정합니다.

Impact
Effort
Risk
Strategic Alignment

선택된 기능뿐 아니라 제외된 기능과 제외 이유도 정리합니다. prioritization-frameworks는 Opportunity Score, ICE, RICE, MoSCoW, Kano 등 9개 우선순위 프레임워크의 공식과 사용 상황을 제공합니다. (GitHub)

사용 예제

prioritize-features 스킬로 StoryMine MVP 기능을 평가해줘.

후보:
- 웹소설 뷰어
- 웹툰 뷰어
- 댓글 보상
- 좋아요 보상
- 공유 보상
- 일일 미션
- 레벨 시스템
- 추천인 보상
- 포인트 쿠폰 교환
- 토큰 출금
- 외부 지갑 연결
- 작가 대시보드
- 관리자 어뷰징 탐지

목표:
8주 안에 리워드가 콘텐츠 재방문율을 높이는지 검증

Impact, Effort, Risk, Strategic Alignment 기준으로 평가하고
MVP 상위 5개와 제외 기능을 알려줘.

예상 MVP 상위 기능

1. 콘텐츠 뷰어
2. 정상 읽기 검증
3. 미확정 포인트
4. 보상 내역
5. 운영자 어뷰징 검토

토큰 출금, 외부 지갑, 레벨 시스템, 추천인 보상은 핵심 가정 검증에 직접 필요하지 않아 후순위가 될 가능성이 높습니다.

---

8. product-strategy

무엇을 하는가

다음 9개 영역의 Product Strategy Canvas를 만듭니다.

Vision
Market Segments
Relative Costs
Value Proposition
Trade-offs
Key Metrics
Growth
Capabilities
Defensibility

특히 “무엇을 할 것인가”뿐 아니라 “무엇을 하지 않을 것인가”를 명시하고, 성장 방식과 장기적인 방어력을 함께 검토합니다. (GitHub)

사용 예제

product-strategy 스킬을 사용해
StoryMine의 제품 전략을 작성해줘.

조건:
- 초기 시장은 한국 웹소설 독자
- MVP는 포인트 방식
- 블록체인 토큰은 후속 단계
- 콘텐츠 확보 예산이 제한적
- 리워드 어뷰징 위험이 높음

포함:
- 첫 번째 핵심 세그먼트
- 기존 플랫폼과의 차별화
- 하지 않을 것
- 핵심 지표
- 성장 구조
- 경쟁사가 복제하기 어려운 요소

분석

create-prd가 제품 한 버전의 실행 문서라면 product-strategy는 여러 버전에 걸친 방향을 정합니다.

product-strategy
→ create-prd

순서가 일반적으로 더 자연스럽습니다.

---

9. competitor-analysis

무엇을 하는가

웹 조사를 통해 직접 경쟁사 5개를 찾고 다음 내용을 비교합니다.

• 시장과 고객 범위
• 포지셔닝
• 기능
• 가격
• GTM 전략
• 강점과 약점
• 차별화 기회
• 잠재적 미래 위협

저장소의 스킬은 단순 기능표가 아니라 경쟁 구도와 차별화 기회까지 종합하도록 정의되어 있습니다. (GitHub)

사용 예제

competitor-analysis 스킬을 사용해
보상형 웹소설·웹툰 플랫폼의 경쟁 환경을 조사해줘.

비교 대상:
- 직접 경쟁 서비스
- 웹소설 플랫폼
- 웹툰 플랫폼
- 읽기 보상 앱
- 행동 보상형 Web3 앱

비교 항목:
- 핵심 고객
- 콘텐츠 확보 방식
- 리워드 구조
- 수익모델
- 가격
- 어뷰징 방지
- 사용자 유지 전략
- StoryMine이 차별화할 수 있는 영역

모든 최신 정보에 출처와 확인 날짜를 표시해줘.

분석

경쟁사 조사는 최신 웹 데이터가 필요합니다. 따라서 스킬을 실행할 때 “웹에서 현재 정보를 확인하고 확인되지 않는 내용은 추정하지 말라”는 조건을 추가하는 편이 안전합니다.

---

10. metrics-dashboard와 north-star-metric

무엇을 하는가

north-star-metric은 비즈니스를 다음 세 게임 중 하나로 분류합니다.

Attention
Transaction
Productivity

그다음 고객이 얻는 핵심 가치를 나타내는 단일 North Star Metric과 3~5개의 입력 지표를 선정합니다. metrics-dashboard는 여기에 데이터 출처, 계산식, 시각화 방식, 목표, 경보 기준을 추가합니다. (GitHub)

StoryMine 예제

north-star-metric과 metrics-dashboard 스킬을 순서대로 사용해
StoryMine MVP의 지표 체계를 설계해줘.

주의:
- 단순 가입자 수나 총 발행 포인트를 North Star로 사용하지 않는다.
- 실제 고객 가치와 연결된 지표를 선택한다.
- 어뷰징 활동은 제외한다.
- 각 지표의 정확한 계산식을 정의한다.

[Inference] 가능한 결과 예시

North Star 후보:
주간 검증 완료 콘텐츠 열람 회차 수

입력 지표:
- 주간 활성 독자 수
- 독자당 검증 열람 회차
- 첫 열람 후 7일 재방문율
- 보상 확정률
- 작품 탐색 → 열람 전환율

건강 지표:
- 부정 활동 비율
- 보상 취소율
- 콘텐츠 신고율
- 포인트 비용 / 활성 사용자

분석

보상 앱은 총 지급 포인트나 클릭 수가 크게 보일 수 있지만, 그것이 실제 고객 가치와 일치하지 않을 수 있습니다. 따라서 NSM과 어뷰징 방지용 건강 지표를 함께 설정해야 합니다.

---

11. pre-mortem과 strategy-red-team

두 스킬은 비슷해 보이지만 목적이 다릅니다.

스킬핵심 질문

pre-mortem	출시가 실패했다고 가정하면 무엇이 원인이었는가
strategy-red-team	현재 계획을 지탱하는 핵심 가정은 무엇이며, 어떤 조건에서 무너지는가

pre-mortem은 위험을 Tigers, Paper Tigers, Elephants로 구분하고 출시 전 해결, 빠른 후속 조치, 모니터링 항목으로 나눕니다. strategy-red-team은 핵심 주장마다 Fails if, 이번 주 확보할 증거, 중단 기준, 가장 저렴한 실험을 작성합니다. (GitHub)

사용 예제

strategy-red-team 스킬로 StoryMine PRD를 공격적으로 검토해줘.

각 핵심 가정에 대해:
- Claim
- Fails if
- Evidence to get this week
- Kill criterion
- Cheapest test

를 작성해줘.

일반적인 위험 목록은 제외하고
이 기획이 실제로 중단되어야 하는 핵심 가정만 5개 이내로 선정해줘.

예상 핵심 중단 조건

Fails if:
보상을 제공해도 7일 재방문율이 유의미하게 증가하지 않는다.

Kill criterion:
보상 그룹의 재방문율이 비보상 그룹보다 5%p 이상 높지 않다.

Cheapest test:
30~50명을 대상으로 2주간 수동 포인트 지급 실험.

---

12. shipping-artifacts와 intended-vs-implemented

무엇을 하는가

개발이 진행된 뒤 사용하는 스킬입니다.

shipping-artifacts는 코드베이스에서 다음 문서를 만듭니다.

architecture.md
사용자·권한 흐름
permissions.md
variables/secrets 문서
tests.md

이메일, Cron, SEO, 내장 AI 에이전트 등이 있을 때만 조건부 문서를 추가합니다. intended-vs-implemented는 문서에 적힌 의도와 실제 코드의 권한 검사, 데이터 필터, 입력 검증을 비교합니다. (GitHub)

Next.js 프로젝트 적용 예제

pm-ai-shipping의 shipping-artifacts와
intended-vs-implemented 스킬을 사용해
현재 Next.js 프로젝트를 출시 전 검토해줘.

1. documentation/에 시스템 문서를 생성한다.
2. 사용자 역할과 권한을 정리한다.
3. 환경변수와 비밀정보 사용 위치를 정리한다.
4. 문서의 권한 규칙과 실제 서버 코드를 비교한다.
5. 문서와 코드가 다른 부분만 증거 파일과 줄 번호로 보고한다.
6. 확인할 수 없는 내용은 finding이 아니라 unverified question으로 분리한다.

분석

사용자가 Codex로 Next.js, SQLite/PostgreSQL, 관리자 기능까지 한 번에 구현하는 경우 이 스킬의 가치가 큽니다. 코드가 실행되는 것과 기획된 권한·보상 규칙이 정확히 적용되는 것은 별개의 문제이기 때문입니다.

사용자에게 가장 적합한 기본 조합

[Inference] 사용자가 자주 만드는 MVP 앱 기획과 실제 개발 흐름에는 다음 10단계가 가장 실용적입니다.

1. brainstorm-ideas-new
2. identify-assumptions-new
3. prioritize-assumptions
4. brainstorm-experiments-new
5. product-strategy
6. competitor-analysis
7. create-prd
8. user-stories
9. test-scenarios
10. shipping-artifacts

이를 세 구간으로 줄이면 다음과 같습니다.

제품 검증
brainstorm-ideas-new
→ identify-assumptions-new
→ prioritize-assumptions
→ brainstorm-experiments-new

기획·개발
product-strategy
→ create-prd
→ user-stories
→ test-scenarios

출시 검토
pre-mortem
→ shipping-artifacts
→ intended-vs-implemented

Codex에서 한 번에 요청하는 프롬프트

Codex에서는 Claude용 /discover, /write-prd 같은 명령이 Slash Command로 직접 실행되지 않으므로, 스킬 이름과 실행 순서를 자연어로 지정하는 방식이 권장됩니다. (GitHub)

설치된 pm-skills 플러그인을 사용해
StoryMine 모바일 앱의 제품 기획 워크플로를 실행해줘.

다음 스킬을 순서대로 사용한다.

1. brainstorm-ideas-new
2. identify-assumptions-new
3. prioritize-assumptions
4. brainstorm-experiments-new
5. product-strategy
6. create-prd
7. user-stories
8. test-scenarios
9. pre-mortem

규칙:
- 각 단계의 결과를 별도 Markdown 파일로 저장한다.
- 이전 단계 결과를 다음 단계의 입력으로 사용한다.
- 검증된 사실, 가정, 제안을 명확히 구분한다.
- 최신 시장 정보는 웹에서 확인하고 출처를 표시한다.
- MVP는 8주 내 개발 가능한 범위로 제한한다.
- 블록체인 토큰과 외부 지갑은 MVP에서 제외한다.
- 최종적으로 개발 우선순위와 권장 폴더 구조를 제시한다.

가장 먼저 익혀야 할 핵심만 고르면 identify-assumptions-new → prioritize-assumptions → create-prd → user-stories → test-scenarios 다섯 개입니다. 이 조합만으로도 막연한 앱 아이디어를 위험 검토가 포함된 개발 명세와 QA 기준까지 연결할 수 있습니다.