Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

idea2planning

Estrelas22

Forks8

Atualizado24 de maio de 2026 às 01:10

Use when converting a rough idea, new feature request, or improvement into structured product documents. Triggers when user runs /idea2planning or wants to generate a 1-pager, PRD, or ASCII wireframe from an idea.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

pentaxzs

pentaxzs/skill-idea2planning

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Especialistas em gestão de projetosNegócios e Operações Financeiras·SOC 13-1082

SKILL.md

readonly

Execute qualquer Skill com um clique

name	idea2planning
description	Use when converting a rough idea, new feature request, or improvement into structured product documents. Triggers when user runs /idea2planning or wants to generate a 1-pager, PRD, or ASCII wireframe from an idea.

idea2planning

Overview

아이디어를 입력받아 1-pager, PRD, ASCII 와이어프레임을 단계적으로 생성하는 스킬. 대상: PM, PD 주니어~시니어 / 막연한 아이디어로도 시작 가능.

시작: Entry Menu

스킬 시작 시 반드시 아래 메뉴를 먼저 제시한다. 다른 행동을 먼저 하지 말 것:

무엇을 만들어볼까요?

1) 1-pager     — "이 제품이 왜 필요한가"를 한 장으로 정리한 요약 문서
                 (문제 · 솔루션 · 타겟 유저 · 기대 효과)

2) PRD         — "무엇을 어떻게 만들어야 하는가"를 정리한 요구사항 문서
                 (기능 정의 · 유저 시나리오 · 제약 조건)

3) 와이어프레임 — 텍스트로 그리는 화면 구조 스케치
                 (레이아웃 · 주요 UI 요소 배치)

4) 처음부터 차근차근 (1→2→3 순서로)

5) 잘 모르겠어요, 아이디어부터 설명할게요

언어 처리

사용자 입력 언어를 감지하여 동일 언어로 문서 생성.

한국어 입력 → 한국어 문서
English input → English document

옵션 5: 아이디어 먼저

사용자 아이디어를 자유롭게 입력받는다
아이디어 내용을 분석한다
최적 시작 단계를 추천하고 이유를 설명한다:
- 막연한 아이디어만 있음 → 1번(1-pager)부터 추천
- 이미 1-pager/요약 문서가 있음 → 2번(PRD)부터 추천
- PRD 수준 스펙이 이미 있음 → 3번(와이어프레임)부터 추천
추천 단계로 바로 진행한다

문서 저장

각 산출물 완성 후, 다음 단계 진행 여부를 묻기 전에 반드시 저장 여부를 먼저 확인한다.

저장 플로우

완성 직후 저장 여부 질문:

"파일로 저장할까요? (md / pdf / 건너뛰기)"
md 선택 시:
- Write 도구로 직접 저장
- 저장 경로: ~/Documents/idea2planning/outputs/ (기본값)
- 파일명: 1pager_[제목요약]_[YYMMDD].md 형식
pdf 선택 시:
- pandoc 설치 여부 확인: pandoc --version
- 설치되어 있으면: pandoc [input.md] -o [output.pdf] 실행
- 설치 안 되어 있으면: md로 저장 후 안내
  
  "pandoc이 설치되어 있지 않아 md 파일로 저장했어요. PDF로 변환하려면 터미널에서 brew install pandoc 후 재시도해주세요."
건너뛰기 선택 시: 저장 없이 다음 단계로 진행

파일명 규칙

산출물	파일명 예시
1-pager	`1pager_홈배너개선_260517.md`
PRD	`prd_홈배너개선_260517.md`
와이어프레임	`wireframe_홈배너개선_260517.md`

단계 전환

각 산출물 완성 후 저장 여부 확인 → 다음 단계 진행 여부를 묻는다:

1-pager 완성 → 저장 확인 → "PRD 작성으로 넘어갈까요?"
PRD 완성 → 저장 확인 → "ASCII 와이어프레임으로 넘어갈까요?"
와이어프레임 완성 → 저장 확인 → 종료
Yes → 다음 단계 진행 / No → 종료

Stage 1: 1-pager 생성

참조 파일 읽기 (작성 전 필수)

references/ 폴더에서 아래 파일들을 읽어 스타일·어조·섹션 깊이·품질 기준을 파악한다:

1pager_understanding.md — 작성 원칙 및 개념
1pager_template.md — 구조 기준
1pager_example*.md — 존재하는 모든 예시 파일 (현재 개수에 관계없이 전부 읽을 것)

정보 수집

아이디어/문제가 충분히 파악되지 않은 경우 한 번에 하나씩 질문:

어떤 문제를 해결하려 하나요?
주요 타겟 사용자는 누구인가요?
관련 데이터나 현황 수치가 있나요? (없으면 정성 근거로 대체 가능)

문서 구조

아래 순서로 각 섹션에 실제 내용을 채워 작성한다:

# [YY.MM.DD] 제목 (팀/조직명)

## 1. 프로젝트 한 줄 요약
## 2. 대상
   | 대상 | 상황/특징 |
## 3. 문제 정의
   ### 고객 문제         — 불릿 리스트
   ### 비즈니스 문제      — 불릿 리스트
   ### 데이터 기반 현황   — 항목·수치·인사이트 테이블
   ### Root Cause      — Case 1, 2, 3...
## 4. 목표
   | 항목 | 목표 수치 |
## 5. 현황 및 분석      — VOC 인용, 인터뷰, 시장 동향
## 6. 해결방안          — Phase 1, Phase 2... 단위
## 7. 리스크
   | 영향도 | 리스크 | 대응 방안 |
## 8. 중요도 및 긴급도  — 상/중/하 + 이유

작성 원칙

Why 중심 (당위성·근거 중심, 스펙 상세화 X)
숫자로 설명 (정량 우선, 없으면 정성 근거)
고객 문제 / 비즈니스 문제 반드시 분리
해결방안은 Phase 단위
리스크 반드시 포함

Stage 2: PRD 생성

참조 파일 읽기 (작성 전 필수)

references/ 폴더에서 아래 파일들을 읽어 스타일·어조·섹션 깊이·품질 기준을 파악한다:

prd_understanding.md — 작성 원칙 및 개념
prd_template.md — 구조 기준
prd_example*.md — 존재하는 모든 예시 파일 (현재 개수에 관계없이 전부 읽을 것)

정보 수집

PRD 작성 전 아래 항목을 한 번에 하나씩 반드시 확인한다:

대상 사용자 세그먼트와 제외 대상은?
핵심 기능 우선순위는?
제외 범위(Out of Scope)는?
오픈 목표 일정이나 단계적 출시 계획이 있나요?
관련된 유관부서나 이해관계자가 있나요? (마케팅, 법무, 운영 등)
예외 처리가 필요한 특수 상황이 있나요? (예: API 실패, 데이터 부족, 특정 사용자 제외 등)

문서 구조

# [YY.MM.DD] 프로젝트명 (팀/조직명)
> 작성일 / 작성자 / 상태: Draft / 버전: v0.1

## 0. 문서 개요
   ### 0-1. 프로젝트 요약
   ### 0-2. 배경
      - 현재 상황
      - 문제 정의 + 데이터 현황 테이블
      - 사용자 Voice (인터뷰/VOC 인용)

## 1. 목표 (Goal)
   ### 1-1. 프로젝트 목표 (사용자 / 비즈니스 / 운영)
   ### 1-2. 성공 기준
      | 지표 | 현재 | 목표 |
      정성 목표

## 2. KPI 및 측정지표
   ### 2-1. 핵심 KPI
      | KPI명 | 정의 | 계산식 | 목표 | 측정 주기 | 측정 도구 |
   ### 2-2. 보조 지표
   ### 2-3. 모니터링 지표 (유입·탐색·퍼널·리텐션)

## 3. 사용자 및 이해관계자
   ### 3-1. 대상 사용자 + 제외 대상
   ### 3-2. 이해관계자
      | 조직 | 역할 |

## 4. 정책 정의
   ### 4-1. 기본 정책 (가입 조건·지역·이용 제한)
   ### 4-2. 상태값 정의
      | 상태 | 설명 |
   ### 4-3. 예외 정책
      | 상황 | 처리 |

## 5. 서비스 구조
   ### 5-1. 서비스 흐름 (텍스트 다이어그램)
   ### 5-2. 유저 플로우 (단계별 행동)
   ### 5-3. 주요 화면
      | 화면 | 목적 |

## 6. 상세 요구사항
   ### 6-1. 기능 요구사항
      | ID | 기능 | 설명 | 우선순위 |
   ### 6-2. 운영 요구사항
   ### 6-3. 데이터 요구사항
      | 항목 | 설명 |

## 7. UX/UI 고려사항 (UX 원칙 + 로딩/실패/빈 상태 처리)
## 8. 기술 고려사항 (구조·인증·캐시·성능 목표)
## 9. 실험 및 검증 (AB Test 계획 + 검증 방법)
## 10. 리스크 및 대응
    | 리스크 | 대응 |
## 11. 일정 및 운영계획
    | 단계 | 기간 |
## Appendix (용어 정의·변경 이력)

작성 원칙

애매한 표현 금지 → 구체적 조건·수치로
예외상황 정의 필수 (결제 실패·중복 요청·API timeout 등)
KPI와 기능 연결 (이 기능이 어떤 지표를 개선하는지 명시)
상태값(State) 명확히 정의
개발자가 API/DB 설계 시작 가능한 수준까지 구체적으로

Stage 3: ASCII 와이어프레임 생성

참조 파일 읽기 (작성 전 필수)

references/ 폴더에서 아래 파일들을 읽어 스타일·구조·품질 기준을 파악한다:

wireframe_understanding.md — 작성 원칙 및 개념
wireframe_template.md — 구조 기준 및 Type A/B/C 형식
wireframe_example*.md — 존재하는 모든 예시 파일 (없으면 생략)

핵심 원칙

정답 1개가 아닌 **최소 3가지 방향(Type A/B/C)**을 동시에 제안한다. 각 안의 정보 구조·CTA 방식·인터랙션 방향이 명확히 달라야 한다.

정보 수집

필요 시 한 번에 하나씩 질문:

어떤 화면(들)을 그릴까요?
핵심 CTA는 무엇인가요?
모바일/웹 중 어느 플랫폼 기준인가요? (기본값: 모바일)

출력 형식

각 화면에 대해 아래 구조로 작성:

# 화면명

## 화면 목적     — 단일 핵심 목적 (탐색·구매·가입·리텐션 등)
## 공통 요구사항 — 반드시 포함할 기능·정책·운영 요소

## Type A — 현실적인 안
컨셉: 현재 구조 기반, 빠른 적용, 운영 안정성 높음
핵심 UX 방향: 익숙한 패턴 / CTA 명확화 / 탐색 효율 강화

Wireframe:
┌─────────────────────┐
│ ...실제 내용...      │
└─────────────────────┘

특징 / 장점 / 단점

## Type B — 디자인 강조안
컨셉: 브랜드 몰입감·비주얼 중심
핵심 UX 방향: 대형 비주얼 / 스크롤 몰입 / 감성 중심

Wireframe: ...

특징 / 장점 / 단점

## Type C — 실험적/미래형 안
컨셉: AI·자동화·실시간 개인화 중심
핵심 UX 방향: AI 인터랙션 / 동적 UI / 상황 기반 변화

Wireframe: ...

특징 / 장점 / 단점

추가 권장 항목 (필요 시):

상태 정의: Default / Loading / Empty / Error / Disabled
인터랙션 설명: 등장 애니메이션·스크롤 변화·Sticky 동작

작성 원칙

디자인보다 구조에 집중 (레이아웃·정보 우선순위·CTA 위치)
실제 서비스처럼 (실제 카드 개수·콘텐츠 길이·에러 상황 고려)
한 화면에 핵심 목적 하나
3가지 안의 차이 명확히 (정보 구조·CTA 방식·인터랙션 방향)
모바일 기준 우선 작성

name	idea2planning
description	Use when converting a rough idea, new feature request, or improvement into structured product documents. Triggers when user runs /idea2planning or wants to generate a 1-pager, PRD, or ASCII wireframe from an idea.

idea2planning

Overview

아이디어를 입력받아 1-pager, PRD, ASCII 와이어프레임을 단계적으로 생성하는 스킬. 대상: PM, PD 주니어~시니어 / 막연한 아이디어로도 시작 가능.

시작: Entry Menu

스킬 시작 시 반드시 아래 메뉴를 먼저 제시한다. 다른 행동을 먼저 하지 말 것:

무엇을 만들어볼까요?

1) 1-pager     — "이 제품이 왜 필요한가"를 한 장으로 정리한 요약 문서
                 (문제 · 솔루션 · 타겟 유저 · 기대 효과)

2) PRD         — "무엇을 어떻게 만들어야 하는가"를 정리한 요구사항 문서
                 (기능 정의 · 유저 시나리오 · 제약 조건)

3) 와이어프레임 — 텍스트로 그리는 화면 구조 스케치
                 (레이아웃 · 주요 UI 요소 배치)

4) 처음부터 차근차근 (1→2→3 순서로)

5) 잘 모르겠어요, 아이디어부터 설명할게요

언어 처리

사용자 입력 언어를 감지하여 동일 언어로 문서 생성.

한국어 입력 → 한국어 문서
English input → English document

옵션 5: 아이디어 먼저

사용자 아이디어를 자유롭게 입력받는다
아이디어 내용을 분석한다
최적 시작 단계를 추천하고 이유를 설명한다:
- 막연한 아이디어만 있음 → 1번(1-pager)부터 추천
- 이미 1-pager/요약 문서가 있음 → 2번(PRD)부터 추천
- PRD 수준 스펙이 이미 있음 → 3번(와이어프레임)부터 추천
추천 단계로 바로 진행한다

문서 저장

각 산출물 완성 후, 다음 단계 진행 여부를 묻기 전에 반드시 저장 여부를 먼저 확인한다.

저장 플로우

완성 직후 저장 여부 질문:

"파일로 저장할까요? (md / pdf / 건너뛰기)"
md 선택 시:
- Write 도구로 직접 저장
- 저장 경로: ~/Documents/idea2planning/outputs/ (기본값)
- 파일명: 1pager_[제목요약]_[YYMMDD].md 형식
pdf 선택 시:
- pandoc 설치 여부 확인: pandoc --version
- 설치되어 있으면: pandoc [input.md] -o [output.pdf] 실행
- 설치 안 되어 있으면: md로 저장 후 안내
  
  "pandoc이 설치되어 있지 않아 md 파일로 저장했어요. PDF로 변환하려면 터미널에서 brew install pandoc 후 재시도해주세요."
건너뛰기 선택 시: 저장 없이 다음 단계로 진행

파일명 규칙

산출물	파일명 예시
1-pager	`1pager_홈배너개선_260517.md`
PRD	`prd_홈배너개선_260517.md`
와이어프레임	`wireframe_홈배너개선_260517.md`

단계 전환

각 산출물 완성 후 저장 여부 확인 → 다음 단계 진행 여부를 묻는다:

1-pager 완성 → 저장 확인 → "PRD 작성으로 넘어갈까요?"
PRD 완성 → 저장 확인 → "ASCII 와이어프레임으로 넘어갈까요?"
와이어프레임 완성 → 저장 확인 → 종료
Yes → 다음 단계 진행 / No → 종료

Stage 1: 1-pager 생성

참조 파일 읽기 (작성 전 필수)

references/ 폴더에서 아래 파일들을 읽어 스타일·어조·섹션 깊이·품질 기준을 파악한다:

1pager_understanding.md — 작성 원칙 및 개념
1pager_template.md — 구조 기준
1pager_example*.md — 존재하는 모든 예시 파일 (현재 개수에 관계없이 전부 읽을 것)

정보 수집

아이디어/문제가 충분히 파악되지 않은 경우 한 번에 하나씩 질문:

어떤 문제를 해결하려 하나요?
주요 타겟 사용자는 누구인가요?
관련 데이터나 현황 수치가 있나요? (없으면 정성 근거로 대체 가능)

문서 구조

아래 순서로 각 섹션에 실제 내용을 채워 작성한다:

# [YY.MM.DD] 제목 (팀/조직명)

## 1. 프로젝트 한 줄 요약
## 2. 대상
   | 대상 | 상황/특징 |
## 3. 문제 정의
   ### 고객 문제         — 불릿 리스트
   ### 비즈니스 문제      — 불릿 리스트
   ### 데이터 기반 현황   — 항목·수치·인사이트 테이블
   ### Root Cause      — Case 1, 2, 3...
## 4. 목표
   | 항목 | 목표 수치 |
## 5. 현황 및 분석      — VOC 인용, 인터뷰, 시장 동향
## 6. 해결방안          — Phase 1, Phase 2... 단위
## 7. 리스크
   | 영향도 | 리스크 | 대응 방안 |
## 8. 중요도 및 긴급도  — 상/중/하 + 이유

작성 원칙

Why 중심 (당위성·근거 중심, 스펙 상세화 X)
숫자로 설명 (정량 우선, 없으면 정성 근거)
고객 문제 / 비즈니스 문제 반드시 분리
해결방안은 Phase 단위
리스크 반드시 포함

Stage 2: PRD 생성

참조 파일 읽기 (작성 전 필수)

references/ 폴더에서 아래 파일들을 읽어 스타일·어조·섹션 깊이·품질 기준을 파악한다:

prd_understanding.md — 작성 원칙 및 개념
prd_template.md — 구조 기준
prd_example*.md — 존재하는 모든 예시 파일 (현재 개수에 관계없이 전부 읽을 것)

정보 수집

PRD 작성 전 아래 항목을 한 번에 하나씩 반드시 확인한다:

대상 사용자 세그먼트와 제외 대상은?
핵심 기능 우선순위는?
제외 범위(Out of Scope)는?
오픈 목표 일정이나 단계적 출시 계획이 있나요?
관련된 유관부서나 이해관계자가 있나요? (마케팅, 법무, 운영 등)
예외 처리가 필요한 특수 상황이 있나요? (예: API 실패, 데이터 부족, 특정 사용자 제외 등)

문서 구조

# [YY.MM.DD] 프로젝트명 (팀/조직명)
> 작성일 / 작성자 / 상태: Draft / 버전: v0.1

## 0. 문서 개요
   ### 0-1. 프로젝트 요약
   ### 0-2. 배경
      - 현재 상황
      - 문제 정의 + 데이터 현황 테이블
      - 사용자 Voice (인터뷰/VOC 인용)

## 1. 목표 (Goal)
   ### 1-1. 프로젝트 목표 (사용자 / 비즈니스 / 운영)
   ### 1-2. 성공 기준
      | 지표 | 현재 | 목표 |
      정성 목표

## 2. KPI 및 측정지표
   ### 2-1. 핵심 KPI
      | KPI명 | 정의 | 계산식 | 목표 | 측정 주기 | 측정 도구 |
   ### 2-2. 보조 지표
   ### 2-3. 모니터링 지표 (유입·탐색·퍼널·리텐션)

## 3. 사용자 및 이해관계자
   ### 3-1. 대상 사용자 + 제외 대상
   ### 3-2. 이해관계자
      | 조직 | 역할 |

## 4. 정책 정의
   ### 4-1. 기본 정책 (가입 조건·지역·이용 제한)
   ### 4-2. 상태값 정의
      | 상태 | 설명 |
   ### 4-3. 예외 정책
      | 상황 | 처리 |

## 5. 서비스 구조
   ### 5-1. 서비스 흐름 (텍스트 다이어그램)
   ### 5-2. 유저 플로우 (단계별 행동)
   ### 5-3. 주요 화면
      | 화면 | 목적 |

## 6. 상세 요구사항
   ### 6-1. 기능 요구사항
      | ID | 기능 | 설명 | 우선순위 |
   ### 6-2. 운영 요구사항
   ### 6-3. 데이터 요구사항
      | 항목 | 설명 |

## 7. UX/UI 고려사항 (UX 원칙 + 로딩/실패/빈 상태 처리)
## 8. 기술 고려사항 (구조·인증·캐시·성능 목표)
## 9. 실험 및 검증 (AB Test 계획 + 검증 방법)
## 10. 리스크 및 대응
    | 리스크 | 대응 |
## 11. 일정 및 운영계획
    | 단계 | 기간 |
## Appendix (용어 정의·변경 이력)

작성 원칙

애매한 표현 금지 → 구체적 조건·수치로
예외상황 정의 필수 (결제 실패·중복 요청·API timeout 등)
KPI와 기능 연결 (이 기능이 어떤 지표를 개선하는지 명시)
상태값(State) 명확히 정의
개발자가 API/DB 설계 시작 가능한 수준까지 구체적으로

Stage 3: ASCII 와이어프레임 생성

참조 파일 읽기 (작성 전 필수)

references/ 폴더에서 아래 파일들을 읽어 스타일·구조·품질 기준을 파악한다:

wireframe_understanding.md — 작성 원칙 및 개념
wireframe_template.md — 구조 기준 및 Type A/B/C 형식
wireframe_example*.md — 존재하는 모든 예시 파일 (없으면 생략)

핵심 원칙

정답 1개가 아닌 **최소 3가지 방향(Type A/B/C)**을 동시에 제안한다. 각 안의 정보 구조·CTA 방식·인터랙션 방향이 명확히 달라야 한다.

정보 수집

필요 시 한 번에 하나씩 질문:

어떤 화면(들)을 그릴까요?
핵심 CTA는 무엇인가요?
모바일/웹 중 어느 플랫폼 기준인가요? (기본값: 모바일)

출력 형식

각 화면에 대해 아래 구조로 작성:

# 화면명

## 화면 목적     — 단일 핵심 목적 (탐색·구매·가입·리텐션 등)
## 공통 요구사항 — 반드시 포함할 기능·정책·운영 요소

## Type A — 현실적인 안
컨셉: 현재 구조 기반, 빠른 적용, 운영 안정성 높음
핵심 UX 방향: 익숙한 패턴 / CTA 명확화 / 탐색 효율 강화

Wireframe:
┌─────────────────────┐
│ ...실제 내용...      │
└─────────────────────┘

특징 / 장점 / 단점

## Type B — 디자인 강조안
컨셉: 브랜드 몰입감·비주얼 중심
핵심 UX 방향: 대형 비주얼 / 스크롤 몰입 / 감성 중심

Wireframe: ...

특징 / 장점 / 단점

## Type C — 실험적/미래형 안
컨셉: AI·자동화·실시간 개인화 중심
핵심 UX 방향: AI 인터랙션 / 동적 UI / 상황 기반 변화

Wireframe: ...

특징 / 장점 / 단점

추가 권장 항목 (필요 시):

상태 정의: Default / Loading / Empty / Error / Disabled
인터랙션 설명: 등장 애니메이션·스크롤 변화·Sticky 동작

작성 원칙

디자인보다 구조에 집중 (레이아웃·정보 우선순위·CTA 위치)
실제 서비스처럼 (실제 카드 개수·콘텐츠 길이·에러 상황 고려)
한 화면에 핵심 목적 하나
3가지 안의 차이 명확히 (정보 구조·CTA 방식·인터랙션 방향)
모바일 기준 우선 작성