job-stories

job-stories 스킬 개요

job-stories 스킬은 거친 제품 아이디어를 JTBD 스타일의 job story로 정리하는 데 도움을 줍니다. 형식은 “When [상황], I want to [동기], so I can [결과]”입니다. 백로그 항목을 더 명확하게 만들거나, 요구사항 기획을 더 탄탄하게 하거나, 솔루션 설계 전에 사용자 맥락을 공통 언어로 정리해야 할 때 특히 유용합니다.

이 스킬이 가장 잘 맞는 경우

이미 기능 영역은 알고 있지만 그 안에 숨어 있는 사용자 문제를 더 선명하게 만들고 싶을 때 job-stories 스킬을 쓰면 좋습니다. 제품 매니저, 디자이너, 분석가, 그리고 디자인 링크나 기능 프롬프트, 이해관계자 메모를 바탕으로 요구사항을 초안화하는 AI 에이전트에 잘 맞습니다.

일반적인 프롬프트와 다른 점

핵심 가치는 구조입니다. 이 스킬은 모델이 먼저 상황과 동기에서 출발한 뒤, 관찰 가능한 결과와 연결된 수용 기준을 붙이도록 유도합니다. 그래서 팀이 맥락, 의도, 테스트 가능한 결과를 중요하게 본다면, 느슨하게 “user stories를 써 달라”는 프롬프트보다 job-stories가 훨씬 유용합니다.

어떤 경우에 특히 적합한가

이 스킬은 job-stories for Requirements Planning, 초기 발굴 전 백로그 정리, 기능 개념을 사용자 중심 스토리로 바꾸는 작업에 잘 맞습니다. 반대로 수용 기준 없이 짧은 문장 아이디어 목록만 빠르게 필요하거나, 팀이 전혀 다른 요구사항 형식을 쓰는 경우에는 효용이 떨어집니다.

job-stories 스킬 사용 방법

올바르게 설치하고 실행하기

job-stories install 용도라면, 디렉터리의 일반적인 스킬 로더를 사용하세요: npx skills add phuryn/pm-skills --skill job-stories. 그런 다음 모델이 사용자 상황, 제품 영역, 원하는 결과를 추론할 수 있을 만큼 충분한 입력과 함께 스킬을 호출합니다. 기능 이름만 던지는 방식으로는 보통 정보가 너무 부족합니다.

적절한 입력 형태로 전달하기

이 스킬은 프롬프트에 제품, 기능, 사용자 맥락, 그리고 디자인 참고 자료가 함께 들어갈 때 가장 잘 작동합니다. 좋은 시작 프롬프트 예시는 다음과 같습니다: “Create job stories for [product] feature [feature] using these user situations: [context]. Use the design link [design] and focus on outcomes, not roles.” “checkout에 대한 job stories를 써 줘”보다 훨씬 낫습니다.

먼저 읽어야 할 파일

먼저 SKILL.md를 여세요. 워크플로, 스토리 템플릿, 필수 인자가 들어 있습니다. 로컬 복사본에 인접 문서가 있다면 그다음에는 README.md, AGENTS.md, metadata.json을 읽고, 필요에 따라 rules/, resources/, references/, scripts/ 폴더도 확인하세요. 이 저장소에서는 SKILL.md가 주된 기준 문서이므로, 추가로 훑어볼 표면적은 많지 않습니다.

출력 품질을 높이는 워크플로 팁

이 스킬은 두 번에 나눠 쓰는 편이 좋습니다. 먼저 raw job stories를 받고, 그다음 실제 제약 조건에 맞춰 다듬으세요. 첫 결과가 모호하다면 구체적인 상황, 의사결정 지점, 디자인 링크를 더 넣으세요. 스토리가 역할 중심으로 흐른다면, 페르소나보다 트리거와 원하는 진전에 초점을 맞춰 다시 써 달라고 요청하세요.

job-stories 스킬 FAQ

job-stories는 Requirements Planning에 좋은가요?

네. job-stories는 기능 우선 티켓보다 사용자 중심 백로그 항목이 필요한 requirements planning에 맞게 설계되었습니다. 범위를 상황, 동기, 결과로 바꿔 주기 때문에 디자인과 엔지니어링과 논의할 때 더 다루기 쉽습니다.

제대로 쓰려면 디자인 파일이 꼭 필요한가요?

아니요. 하지만 job-stories 스킬은 디자인 파일이 있을 때 더 강합니다. Figma나 Miro 링크가 있으면 모델이 수용 기준을 보이는 동작에 묶을 수 있어서, 근거 없는 가정을 덜 하게 됩니다.

일반적인 user stories와 무엇이 다른가요?

일반적인 프롬프트는 역할 기반 템플릿이나 얕은 수용 기준으로 끝나는 경우가 많습니다. job-stories 스킬은 시스템이 무엇을 해야 하는지보다, 사용자가 왜 행동하는지와 어떤 결과가 필요한지가 핵심일 때 더 좋습니다.

초보자도 쓰기 쉬운가요?

네, 기능을 평이한 언어로 설명할 수 있다면 충분합니다. 다만 입력 품질이 가장 큰 변수입니다. 초보자는 넓은 기능 주제보다 실제 사용자 상황 1~2개를 주었을 때 훨씬 좋은 결과를 얻습니다.

job-stories 스킬 개선 방법

기능 이름보다 더 풍부한 상황을 넣기

품질을 가장 크게 끌어올리는 요소는 구체적인 맥락입니다. “notifications”라고만 쓰지 말고, “When a user misses a payment reminder while traveling”처럼 상황을 주세요. 그래야 job-stories 스킬이 의미 있는 상황-동기-결과 흐름을 만들 수 있습니다.

제약 조건과 성공 신호를 추가하기

접근성, 타이밍, 기기 제한, 승인 흐름이 중요하다면 처음부터 함께 적으세요. 성공이 어떤 모습인지, 무엇이 관찰 가능해야 하는지, 무엇이 나오면 스토리가 실패인지가 설명될수록 수용 기준이 더 탄탄해집니다.

실패 양상 기준으로 수정 요청하기

첫 초안이 너무 일반적이면 역할 언급을 줄이고 상황 묘사를 더 늘리라고 하세요. 너무 솔루션 중심이면 구현 용어를 피한 job stories로 다시 써 달라고 하세요. 너무 넓으면 기능을 한 번에 하나의 사용자 목표로 좁히세요.

첫 결과를 기획 초안으로 활용하기

첫 번째 결과는 최종 요구사항이 아니라 탐색 도구로 보세요. job-stories를 가장 잘 활용하는 방법은 스토리가 로드맵, 디자인, 엔지니어링 제약과 맞아떨어질 때까지 반복한 뒤, Requirements Planning이나 전달에 도움이 되지 않는 요소를 덜어내는 것입니다.