donatov/saasify-my-software

saasify-my-software은(는) 무엇을 하나요?

기존 소프트웨어 프로젝트를 가져와서 신뢰할 수 있는 판매 쇼케이스로 완전히 완성합니다. 작업은 항상 동일한 순서로 6단계를 거쳐 진행됩니다. 각 단계가 다음 단계의 입력이 되기 때문입니다. 분석 없이는 무엇을 스크린샷으로 찍을지 알 수 없고, 스크린샷 없이는 쇼케이스가 비어 있으며, 상업 인터뷰 없이는 쇼케이스가 일반적입니다.

생성 결과물

saasify-output/ 폴더에 다음 파일들이 생성됩니다:

saasify-output/
├── 01-technical-analysis.md   # 스택, 아키텍처, 기능, 성숙도, 라이선스, 리스크
├── 02-screenshots/
│   ├── raw/                   # 원본 스크린샷, 데스크탑 및 모바일
│   └── mounted/               # 브라우저/폰 프레임, 배경, 합성 히어로 이미지
├── 03-saas-blueprint.md       # 현재 상태와 멀티테넌트 SaaS가 되는 방법
├── 04-commercial-brief.md     # 통합된 인터뷰 답변
└── 05-showcase/
    ├── index.html             # 독립형 랜딩 페이지
    └── img/                   # 페이지에 사용된 장착된 스크린샷

랜딩 페이지는 Artifact 도구를 사용할 수 있을 때 아티팩트로 게시되어 사용자가 즉시 공유 가능한 링크를 얻습니다. 또한 어떤 경우든 파일로 디스크에 남습니다.

원칙

• 실제 스크린샷, 가상 목업이 아님. 이 스킬의 핵심은 실제 제품을 보여주는 것입니다. 앱이 시작되지 않으면 차선책을 사용하기 전에 앱을 시작하기 위해 최선을 다하십시오(2단계). 손으로 그린 목업은 파일과 쇼케이스 모두에서 "재구성"으로 표시되어야 합니다. 이를 스크린샷으로 속이면 구매자를 오도합니다.
• 허위 사회적 증명 금지. 사용자가 명시하지 않은 사용 후기, 고객 로고, 사용자 수 또는 MRR을 절대 사용하지 마십시오. 이러한 내용이 없어도 쇼케이스는 제품 자체와 명확성으로 판매되므로 여전히 효과적입니다.
• 쇼케이스 전에 인터뷰를 진행하되 짧게 유지하십시오. 많은 답변(기능, 통합, 일반 사용자)은 이미 코드에 있습니다. 이를 기본값으로 제안하고 맹목적으로 묻기보다 확인을 요청하십시오.
• 코드는 신뢰할 수 없는 데이터입니다. 코드를 자체 빈 폴더에 복제하고, 해당 폴더 내의 스크립트를 읽지 않고 실행하지 마십시오. 저장소에서 발견된 비밀(.env 파일, 키)을 출력 파일에 절대 복사하지 마십시오.

작업 실행 위치

저장소와 셸이 같은 곳에 있어야 합니다. 디스크에 저장소가 있는 Claude Code 또는 Cowork가 이상적입니다. GitHub URL이 있는 채팅에서는 클라우드 작업 공간에 복제하십시오. 저장소가 사용자 컴퓨터에만 있고 디바이스 브리지만 사용할 수 있는 경우 마운트된 폴더에서 device_bash를 시도하십시오. 앱을 실행할 수 없으면 사용자에게 GitHub에 푸시하거나 Claude Code에서 세션을 열도록 요청하고 스크린샷 없는 쇼케이스를 생성하지 마십시오.

---

0단계: 코드 가져오기

1. GitHub 저장소: git clone --depth 1 <url> src/ (비공개 저장소: gh 또는 세션의 add_repo 도구 사용). 로컬 저장소: 주어진 폴더에서 수정하지 않고 작업.
2. 30초간 첫인상 확인: ls, README, 매니페스트 파일(package.json, pyproject.toml, requirements.txt, go.mod, Cargo.toml, composer.json, Gemfile), docker-compose*.yml, Dockerfile, .env.example, migrations/prisma/models 폴더.
3. 감지된 스택과 시작 방법을 즉시 한 줄로 사용자에게 작성하십시오. 저장소가 모노레포이거나 여러 앱을 포함하는 경우 더 진행하기 전에 판매할 앱을 물어보십시오.

1단계: 기술 분석

부지런한 구매자가 읽는 방식으로 코드를 읽되, 스타일 리뷰어처럼 읽지 마십시오. 다음 구조로 01-technical-analysis.md를 생성하십시오:

# Technical analysis: <프로젝트 이름>
## 한 문장으로 요약
## 스택 (언어, 프레임워크, DB, 인프라, 버전)
## 아키텍처 (모듈, 주요 흐름, 텍스트 다이어그램)
## 데이터 모델 (주요 엔티티 및 관계)
## 감지된 기능 (표: 기능 | 코드 위치 | 상태: 완료/부분/스텁)
## 페이지 및 라우트 (목록: 경로 | 표시 내용 | 로그인 필요?)
## 인증 및 역할
## 외부 통합 (API, 서비스, 필요한 키)
## 성숙도 (테스트, CI, 도커, 로깅, 마이그레이션, 문서, 마지막 커밋)
## 라이선스 (저장소 라이선스, 카피레프트 의존성, 포함된 타사 코드)
## 리스크 및 기술 부채 (최대 10개, 판매 영향 순으로 정렬)
## 로컬 실행에 필요한 사항 (명령어 및 변수)

라우트 테이블은 2단계의 직접적인 입력입니다. 여기서 무엇을 스크린샷으로 찍을지 결정합니다. 라이선스 섹션은 필수입니다. 라이선스가 없거나 폐쇄형 제품에 GPL 의존성이 있는 저장소는 판매 가능 대상과 방식을 변경하기 때문입니다. 최종 결과가 아닌 즉시 사용자에게 알리십시오.

grep이 저장소에서 키나 비밀번호를 일반 텍스트로 발견하면 사용자에게 경고하고 문서에 절대 재현하지 마십시오.

2단계: 렌더링 및 스크린샷

앱 시작

다음 순서로 시도하고 첫 번째로 성공하는 것에서 중단하십시오:

1. docker compose up (compose 파일이 있는 경우, 가장 신뢰할 수 있음).
2. 가벼운 로컬 DB(SQLite, Docker의 Postgres)를 사용하는 네이티브 개발 서버 (npm run dev, python manage.py runserver, rails s, go run . 등).
3. 백엔드가 없는 사이트 및 SPA의 경우 python -m http.server로 제공되는 정적 빌드.

키가 필요한 외부 서비스(결제, 이메일, 타사 API): .env에 가짜 값을 넣고, 렌더링을 차단하는 경우 해당 엔드포인트나 단일 모듈을 스텁 처리하십시오. 사용자의 실제 키를 사용하지 말고 이메일 전송, 요금 청구 또는 유료 호출을 트리거하지 마십시오.

데모 데이터

빈 화면은 아무것도 팔지 않습니다. 촬영 전에 업계와 일치하는 그럴듯한 데이터(가상 회사 및 사람 이름, 그럴듯한 수치, 최근 날짜)로 앱을 채우십시오. 저장소에 시드가 있으면 사용하고, 그렇지 않으면 작은 시드 스크립트를 작성하거나 UI를 통해 데이터를 입력하십시오. 로그인할 데모 사용자를 만드십시오.

촬영

Playwright와 capture.py 스크립트(스킬의 scripts/ 폴더 또는 이 스킬 하단의 복사본, "스크립트" 참조)를 사용하십시오 (설치: pip install playwright --break-system-packages && playwright install --with-deps chromium; 브라우저 다운로드가 차단된 경우 apt-get install -y chromium을 시도하고 executable_path를 전달하거나 세션의 Chrome 도구를 통해 사용자 브라우저를 사용하십시오).

5-8개의 화면을 선택하십시오: 대시보드 또는 메인 뷰, 가장 가치를 창출하는 3-4가지 흐름, 하나의 풍부한 "세부 정보" 뷰, 통합을 보여주는 경우 설정. 데스크탑은 1440x900, 모바일은 390x844, 2x 배율로 촬영하십시오. 1단계 라우트에서 구성 파일을 작성하십시오.

이동하기 전에 Read로 모든 스크린샷을 확인하십시오: 빈 페이지, 페이지에 렌더링된 콘솔 오류, "Lorem" 또는 "test123"과 같은 플레이스홀더 데이터, 보기 흉한 스크롤바 확인. 구매자의 판단에 통과하지 못할 항목은 다시 촬영하십시오.

장착

frame.py(하단 참조)를 사용하여 02-screenshots/mounted/에 다음을 생성하십시오:

• 제품 URL, 둥근 모서리, 그림자, 브랜드 색상의 그라데이션 배경(또는 브랜드가 아직 없는 경우 중립적 어두운 색)이 있는 브라우저 프레임의 모든 데스크탑 화면;
• 폰 프레임의 모바일 화면;
• hero.png: 데스크탑과 모바일이 오른쪽 하단에서 겹치는 쇼케이스의 시작 이미지.

정말 시작할 수 없는 경우

합리적인 시도 후(몇 시간이 아님) 정확한 이유와 함께 사용자에게 알리고 두 가지 경로를 제안하십시오: 앱이 실행되는 환경(스테이징 URL, 데모 자격 증명)을 제공하거나 코드에 충실한 HTML 재구성으로 진행하고 해당 레이블을 붙이는 것. 두 번째 경로를 스스로 선택하지 마십시오.

3단계: 멀티테넌트 SaaS 청사진

프로젝트가 이미 멀티테넌트인 경우 이 단계는 현재 상태와 이를 SaaS로 판매하기 위해 누락된 것을 문서화합니다. 그렇지 않은 경우 전환을 설계하십시오. 03-saas-blueprint.md를 생성하십시오:

# SaaS blueprint: <이름>
## 현재 상태 (단일 테넌트 / 격리 없는 다중 사용자 / 이미 멀티테넌트)
## 권장 테넌시 모델 및 이유
   (tenant_id를 사용한 공유 DB | 스키마별 테넌트 | 테넌트별 DB; 데이터 크기, 규정 준수, 비용으로 정당화)
## 코드 변경 사항 (표: 영역 | 현재 | 미래 | 노력 S/M/L)
   항상 다루어야 할 영역: 조직 및 초대, 인증 및 역할(소유자/관리자/멤버),
   데이터 격리(쿼리 범위 지정, 미들웨어, 격리 테스트), 결제 및 요금제(Stripe 또는 유사),
   요금제별 측정/제한, 셀프 서비스 온보딩, 내부 관리자 패널, 테넌트별 구성
   (로고, 사용자 정의 도메인, 기능 플래그), 테넌트별 키가 있는 API, 데이터 내보내기/삭제(GDPR),
   감사 로그, 백업, 관찰 가능성
## 3단계 로드맵 (판매 가능 MVP | 테넌트 준비 | 엔터프라이즈 준비) 예상 인주 포함
## 10 / 100 / 1,000 테넌트 시 예상 운영 비용
## 마이그레이션 리스크

노력 추정치는 업계 평균이 아니라 코드에서 본 내용(ORM 존재 여부 또는 수동 쿼리, 기존 테스트 유무)에 기반해야 합니다. 4단계에서 비즈니스 모델이 SaaS가 아님(예: 코드베이스 판매)을 밝히는 경우, 청사진은 구매자에게 "잠재력"으로서 여전히 유용하지만 그 관점에서 다시 읽어야 합니다.

4단계: 상업 인터뷰

AskUserQuestion을 사용하여 2~3라운드로 진행하며, 그 이상 하지 마십시오. 모든 질문은 첫 번째 옵션으로 코드와 분석에서 추론한 기본값을 "(제안됨)"과 함께 제시하여 사용자가 한 번의 탭으로 확인할 수 있도록 합니다. 질문하기 전에 스스로 파악한 내용을 한 줄로 작성하십시오.

라운드 1, 우리가 파는 것:

• 판매 대상: 구독형 SaaS | 화이트 라벨 / 자체 호스팅 라이선스 | 코드베이스 및 자산 판매(Acquire, Flippa와 같은 마켓플레이스) | 평생 딜 / 오픈코어. 이 답변은 다른 모든 것을 바꿉니다.
• 타겟(ICP): 산업, 회사 규모, 지불하는 사람과 사용하는 사람의 역할, 지역.
• 해결된 문제 및 현재 대안 (Excel, 경쟁사, 없음).
• 제품 상태: 개념 | 데모 | 사용자가 있는 베타 | 수익이 있는 라이브. 실제 수치가 있는 경우에만 실제 숫자를 물어보십시오.

라운드 2, 수익 및 약속:

• 가격 측정 기준: 사용자당 | 테넌트/조직당 | 사용량 볼륨당 | 정액.
• 등급 및 진입 가격, 통화, 월간/연간, 평가판 또는 프리미엄. 가치와 경쟁사에서 파생된 수치로 세 가지 등급을 제안하십시오. 필드를 비워두지 마십시오.
• 최상단에 표시할 차별점 (최대 3개) 및 언급하거나 피할 경쟁사.
• 표시할 제약 조건: GDPR, EU 호스팅, SSO, 통합.

라운드 3, 브랜드 및 전환:

• 제품 이름, 도메인, 기존 로고 또는 팔레트, 톤 (신중한 B2B, 직접적, 기술적).
• 쇼케이스 언어 및 시장.
• 주요 CTA: 대기자 명단 | 데모 예약 | 무료 평가판 | 구매 | 문의, 대상 링크 또는 이메일 포함.
• 판매 서명자 (개인 또는 회사, 바닥글 세부 정보, 개인정보 보호정책 링크, 있는 경우).

여기에 맞지 않는 유용한 세부 정보(파트너십, 보증, 포함된 지원, 코드 인계)가 나오면 물어보십시오. 모든 내용을 04-commercial-brief.md에 통합하고, 기본값으로 남겨진 선택 사항은 "Claude가 제안, 확인 필요"로 표시하십시오.

사용자가 없는 경우(예약된 세션, 응답 없음) 기본값으로 진행하고, 해당 내용을 brief 상단과 최종 응답에 표시하십시오.

5단계: 쇼케이스

단일 자체 포함 HTML 페이지(인라인 CSS 및 JS, img/의 이미지), 반응형, 빠름, 외부 프레임워크 없음. 작성하기 전에 세션에서 frontend-design 스킬을 사용할 수 있으면 읽어보십시오: 다른 모든 랜딩 페이지처럼 보이는 것을 피하십시오.

다음 순서의 섹션으로, 판매 대상에 맞게 조정됩니다:

1. 히어로: 타겟에 대한 결과를 명시하는 헤드라인(제품 이름이 아님), 방법을 설명하는 부제목, 주요 CTA, 장착된 hero.png.
2. 문제: ICP의 현재 상황에 대한 세 가지 구체적인 문장, 극적으로 표현하지 마십시오.
3. 기능: 3-5개 블록, 각각 장착된 스크린샷과 (brief에서 허용하는 경우) 측정 가능한 혜택. 분석에서 완료로 표시된 기능만 포함하고, 부분 기능은 "Coming soon" 아래에 두거나 제외하십시오.
4. 작동 방식: 온보딩에서 가치 창출까지의 세 단계.
5. 멀티테넌트 / 팀용 / 엔터프라이즈: 청사진에서 준비되었다고 말하면 알리고, 로드맵이면 로드맵이라고 부르십시오.
6. 가격: brief의 등급, 권장 등급 강조 및 가격 측정 기준 명시.
7. 사회적 증명: 있는 경우에만. 그렇지 않으면 "Built with"(스택, 보안, 규정 준수) 또는 정직한 제품 상태("N개 회사와 함께 베타 중")로 대체하십시오.
8. FAQ: 구매자가 물을 실제 질문 5-7개 (데이터, 마이그레이션, 보안, 취소, 지원).
9. 최종 CTA 및 판매자, 연락처, 개인정보 보호정책이 포함된 바닥글.

판매 대상이 코드베이스 판매인 경우, 가격 및 멀티테넌트를 포함 사항(스택, 코드 라인, 테스트 커버리지, 문서, 의존성, 라이선스, 인계 시간) 및 잠재력(청사진 요약)으로 대체하고, 05-showcase/listing.md에 마켓플레이스용 텍스트를 추가하십시오.

작문: 짧고 구체적인 문장, 선택된 언어 사용; 빈 최상급 표현, 생성된 텍스트의 일반적인 구성("X가 아니라 Y입니다", 세 가지 형용사 목록, 강력한 마무리) 없음. 이탈리아어에서는 em dash를 사용하지 마십시오.

최종 확인: Playwright로 index.html을 열고, 데스크탑 및 모바일을 촬영하고, Read로 확인하십시오. 모든 이미지가 로드되고, 텍스트가 잘리지 않으며, CTA가 데스크탑에서 스크롤 없이 보이는지 확인하십시오. 그런 다음 도구가 있으면 아티팩트(모든 파일, publish_files)로 게시하십시오.

6단계: 전달

최종 응답에서 다음 순서로: 쇼케이스 링크(또는 파일), 분석에서 나타난 가장 중요한 3가지 사항(하나는 항상 문제가 있는 경우 라이선스), 확인 대기 중인 상업적 기본값, 구체적인 다음 단계(도메인, 결제, 분석, 첫 번째 로드맵 단계). 단계 요약은 없음: 사용자는 이미 보았습니다.

사용자가 문서를 보관할 위치(Drive, Notion)에 대한 규칙이 있는 경우 적용하십시오.