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行でユーザーにすぐに伝えます。リポジトリがモノレポまたは複数のアプリを含む場合は、先に進む前にどれを販売するか尋ねます。

フェーズ1: 技術分析

熱心な購入者のようにコードを読みます（スタイルレビュアーとしては読みません）。以下の構造で 01-technical-analysis.md を生成します:

# 技術分析: <プロジェクト名>
## 一言で
## スタック（言語、フレームワーク、DB、インフラ、バージョン）
## アーキテクチャ（モジュール、主要フロー、テキスト図）
## データモデル（主要エンティティと関連性）
## 検出された機能（表: 機能 | コード上の位置 | ステータス: 完了/部分的/スタブ）
## ページとルート（リスト: パス | 表示内容 | ログイン必要?）
## 認証とロール
## 外部統合（API、サービス、必要なキー）
## 成熟度（テスト、CI、docker、ログ、マイグレーション、ドキュメント、最終コミット）
## ライセンス（リポジトリライセンス、コピーレフト依存関係、埋め込みサードパーティコード）
## リスクと技術的負債（最大10、販売への影響度順）
## ローカル実行に必要なもの（コマンドと変数）

ルートテーブルはフェーズ2への直接のインプットです。そこで何を撮影するか決定します。ライセンスセクションは必須です。ライセンスがないリポジトリや、クローズド製品にGPL依存関係がある場合は、何をどのように販売できるかが変わります。ユーザーにすぐに伝え、後回しにしないでください。

grep でリポジトリ内に平文のキーやパスワードが見つかった場合は、ユーザーに警告し、ドキュメントにそれらを決して転記しないでください。

フェーズ2: レンダリングとスクリーンショット

アプリの起動

以下の順序で試し、最初に成功した方法で停止します:

1. docker compose up（composeファイルが存在する場合、最も確実）。
2. ネイティブ開発サーバー（npm run dev、python manage.py runserver、rails s、go run . など）、軽量なローカルDB（SQLite、Docker内のPostgres）を使用。
3. python -m http.server で提供される静的ビルド（バックエンドのないサイトやSPA向け）。

外部サービス（支払い、メール、サードパーティ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のフロー、リッチな「詳細」ビュー1つ、統合を示す設定。デスクトップは1440x900、モバイルは390x844、2倍スケールで撮影します。フェーズ1のルートから設定ファイルを記述します。

すべてのスクリーンショットをReadで確認してから次に進みます。空白ページ、ページにレンダリングされたコンソールエラー、「Lorem」や「test123」のようなプレースホルダーデータ、見苦しいスクロールバーがないか確認します。購入者の判断に耐えないものは撮り直します。

マウンティング

frame.py（下部参照）を使用して、02-screenshots/mounted/ に以下を生成します:

• すべてのデスクトップ画面をブラウザフレーム内に（製品URL、角丸、シャドウ、ブランドカラー（またはブランドがまだ存在しない場合はニュートラルなダーク）のグラデーション背景）
• モバイル画面を電話フレーム内に
• hero.png: デスクトップの右下にモバイルが重なった、ショーケースのオープニング画像

本当に起動しない場合

合理的な試行（数時間ではない）の後、正確な理由をユーザーに伝え、2つの選択肢を提示します: アプリが実行できる環境（ステージングURL、デモ認証情報）を提供してもらうか、コードに忠実で「再構成」とラベル付けされたHTML再構成で進めるか。自分で2番目の選択肢を選ばないでください。

フェーズ3: マルチテナントSaaS設計書

プロジェクトがすでにマルチテナントである場合、このフェーズではその方法と、SaaSとして販売するために不足しているものを文書化します。そうでない場合は、変換を設計します。03-saas-blueprint.md を生成します:

# SaaS設計書: <名前>
## 現在の状態（シングルテナント / 分離のないマルチユーザー / すでにマルチテナント）
## 推奨テナントモデルとその理由
   （共有DB with tenant_id | スキーマ per tenant | DB per tenant; データサイズ、コンプライアンス、コストで正当化）
## コードの変更点（表: 領域 | 現在 | 将来 | 工数 S/M/L）
   常にカバーする領域: 組織と招待、認証とロール（owner/admin/member）、
   データ分離（クエリスコーピング、ミドルウェア、分離テスト）、課金とプラン（Stripeなど）、
   プランごとのメータリング/制限、セルフサービスオンボーディング、内部管理パネル、テナントごとの設定
   （ロゴ、カスタムドメイン、機能フラグ）、テナントごとのキーを持つAPI、データエクスポート/削除（GDPR）、
   監査ログ、バックアップ、オブザーバビリティ
## ロードマップ（3段階: 販売可能なMVP | テナント対応 | エンタープライズ対応）と想定工数（人週）
## 10/100/1000テナント時の推定ランニングコスト
## 移行リスク

工数見積もりは、業界平均ではなく、コードで確認した内容（ORMの有無、手書きクエリ、既存テストの有無）に基づく必要があります。フェーズ4でビジネスモデルがSaaSでないことが判明した場合（例: コードベースの販売）、設計書は依然として「可能性」として購入者に示すのに有用ですが、その観点で読み直さなければなりません。

フェーズ4: 商用インタビュー

AskUserQuestionを使用して、2〜3ラウンドで実行します。それ以上は行いません。各質問は、コードと分析から推測したデフォルトを最初の選択肢として持ち、その横に「(提案)」と表示し、ユーザーが1タップで確認できるようにします。質問する前に、自分で既に把握したことを1行で書きます。

ラウンド1、販売対象:

• 販売対象: サブスクリプションSaaS | ホワイトラベル/セルフホストライセンス | コードベースとアセットの販売（Acquire、Flippaなどのマーケットプレイス） | ライフタイムディール / オープンコア。この回答が他のすべてを変えます。
• ターゲット（ICP）: 業界、企業規模、支払う人と使う人の役割、地域。
• 解決する問題と現在の代替手段（Excel、競合、なし）。
• 製品ステータス: コンセプト | デモ | ユーザーがいるベータ | 収益があるライブ。実際の数字を持っていると言った場合のみ尋ねます。

ラウンド2、価格と約束:

• 価格設定指標: ユーザーあたり | テナント/組織あたり | 使用量あたり | 定額。
• ティアとエントリー価格、通貨、月額/年額、トライアルまたはフリーミアム。価値と競合他社から導き出した3つのティアを数字で提案します。フィールドを空のままにしないでください。
• 差別化要因（最大3つ）と、言及するか避けるべき競合他社。
• 表示すべき制約: GDPR、EUホスティング、SSO、統合。

ラウンド3、ブランドとコンバージョン:

• 製品名、ドメイン、既存のロゴやパレット、トーン（堅実なB2B、直接的、技術的）。
• ショーケースの言語と市場。
• プライマリCTA: ウェイティングリスト | デモを予約 | 無料トライアル | 購入 | お問い合わせ、リンク先またはメールアドレスを添えて。
• 販売契約者（個人または会社、フッター詳細、プライバシーポリシーリンク（存在する場合））。

ここに当てはまらない有用な詳細（パートナーシップ、保証、含まれるサポート、コード引き継ぎ）が出てきた場合は、それについて尋ねます。すべてを 04-commercial-brief.md に統合します。デフォルトのままにした選択も含め、「Claudeが提案、確認待ち」とマークします。

ユーザーが不在の場合（スケジュールされたセッション、応答なし）は、デフォルトで進め、ブリーフの上部と最終的な返信でその旨をフラグします。

フェーズ5: ショーケース

単一の自己完結型HTMLページ（インラインCSSとJS、img/ 内の画像）、レスポンシブ、高速、外部フレームワークなし。作成する前に、セッションで利用可能な frontend-design スキルを読んでください。他のすべてのランディングページと同じように見えるページを避けてください。

セクション（この順序、販売対象に合わせて調整）:

1. ヒーロー: ターゲットにとっての成果を述べる見出し（製品名ではない）、方法を説明するサブタイトル、プライマリCTA、マウントされた hero.png。
2. 問題: ICPの現在の状況について、ドラマチックにせず3つの具体的な文。
3. 機能: 3〜5ブロック。それぞれにマウントされたスクリーンショットと、ブリーフが許せば測定可能なベネフィット。分析で「完了」とマークされた機能のみ。部分的なものは「近日公開」または除外。
4. 仕組み: オンボーディングから価値創出までの3ステップ。
5. マルチテナント / チーム向け / エンタープライズ: 設計書が準備完了と示す場合はそれを伝え、ロードマップの場合はロードマップと呼びます。
6. 価格設定: ブリーフのティア、推奨ティアを強調し、価格設定指標を明示。
7. ソーシャルプルーフ: 存在する場合のみ。存在しない場合は、「Built with」（スタック、セキュリティ、コンプライアンス）または正直な製品ステータス（「N社とベータ中」）に置き換えます。
8. FAQ: 購入者が尋ねるであろう5〜7の実際の質問（データ、移行、セキュリティ、キャンセル、サポート）。
9. 最終CTA とフッター（販売者、連絡先、プライバシー）。

販売対象がコードベースの場合は、価格設定とマルチテナントを 含まれるもの（スタック、コード行数、テストカバレッジ、ドキュメント、依存関係、ライセンス、引き継ぎ時間）と 可能性（設計書の要約）に置き換え、05-showcase/listing.md にマーケットプレイス向けのテキストを追加します。

文体: 短く、具体的な文章、選択された言語で。空の最上級表現、「XではなくY」、3つの形容詞のリスト、パンチラインクローザーなど、生成テキストに典型的な構造は使用しません。イタリア語ではemダッシュを使用しないでください。

最終チェック: Playwrightで index.html を開き、デスクトップとモバイルを撮影し、Readで確認します。すべての画像が読み込まれ、テキストが途切れておらず、CTAがデスクトップでスクロールせずに表示できることを確認します。その後、アーティファクトとして公開します（すべてのファイル、publish_files）。ツールが存在する場合。

フェーズ6: 納品

最終的な返信では、以下の順序で行います: ショーケースへのリンク（またはファイル）、分析から明らかになった最も重要な3つのこと（ライセンスに問題がある場合は常にその1つ）、確認待ちの商用デフォルト、具体的な次のステップ（ドメイン、支払い、分析、最初のロードマップ段階）。フェーズの要約は行いません。ユーザーはそれらを見ています。

ユーザーがドキュメントをアーカイブする場所（Drive、Notion）に関するルールを持っている場合は、それを適用します。