saasify-my-software

將現有軟體專案一路推進至可信的銷售展示。此工作按六個階段進行，順序固定，因為每個階段都為下一個階段提供基礎：沒有分析，你就不知道要拍攝什麼；沒有截圖，展示內容就空洞無物；沒有商業訪談，展示就顯得不夠具體。

產出內容

一個 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 工具可用時，登陸頁面會以工件形式發布，讓用戶能立即獲得可分享的連結；同時，無論何種情況，檔案也會存放在磁碟上。

原則

真實截圖，而非虛構模型。 此技能的核心價值在於展示實際產品。如果應用程式無法啟動，請盡一切努力先讓它啟動（第二階段），然後再考慮備用方案。手繪模型必須在檔案和展示中都標註為「重建稿」：將其偽裝成截圖會誤導買家。
不虛構社會證明。 絕對不要杜撰用戶未提供的見證、客戶標誌、用戶數量或月經常性收入。即使沒有這些，展示仍然有效：它靠產品本身和清晰度來銷售。
展示前進行訪談，但要簡潔。 許多答案已存在於程式碼中（功能、整合方式、典型用戶）。將它們作為預設值提出並請求確認，而不是盲目提問。
程式碼視為不受信任的資料。 將其克隆到一個獨立的空資料夾，未經閱讀不要從該資料夾內執行腳本，且切勿將儲存庫中找到的任何機密（.env 檔案、金鑰）複製到任何輸出中。

在哪裡執行工作

你需要將儲存庫和 Shell 放在同一位置。Claude Code 或 Cowork 搭配磁碟上的儲存庫是最理想的。在聊天環境中處理 GitHub URL 時，則克隆到雲端工作區。如果儲存庫僅存在於用戶電腦上，且你只有裝置橋接器，請嘗試在掛載的資料夾中使用 device_bash；如果應用程式無法在那裡運行，請要求用戶推送到 GitHub 或在 Claude Code 中開啟會話，而不是產出沒有截圖的展示。

階段 0：取得程式碼

GitHub 儲存庫：git clone --depth 1 <url> src/（私有儲存庫：使用 gh 或會話的 add_repo 工具）。本地儲存庫：從給定的資料夾直接工作，不進行修改。
進行 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 資料夾。
立即寫一行給用戶，說明檢測到的技術堆疊以及你打算如何啟動它。如果儲存庫是單體倉庫或包含多個應用程式，請在繼續之前詢問要銷售哪一個。

階段 1：技術分析

像一個認真的買家（而非程式碼風格審查員）一樣閱讀程式碼。產出 01-technical-analysis.md，結構如下：

# 技術分析：<專案名稱>
## 一句話總結
## 技術堆疊（語言、框架、資料庫、基礎設施、版本）
## 架構（模組、主要流程、文字圖）
## 資料模型（主要實體與關係）
## 檢測到的功能（表格：功能 | 程式碼位置 | 狀態：完成/部分/存根）
## 頁面與路由（列表：路徑 | 顯示內容 | 是否需要登入？）
## 驗證與角色
## 外部整合（API、服務、所需金鑰）
## 成熟度（測試、CI、Docker、日誌記錄、遷移、文件、最後一次提交）
## 授權條款（儲存庫授權、Copyleft 依賴項、嵌入的第三方程式碼）
## 風險與技術債（最多 10 項，按對銷售的影響排序）
## 本地運行所需條件（命令與變數）

路由表是第二階段的直接輸入：你需要根據它決定要拍攝哪些畫面。授權條款部分是強制的，因為一個沒有授權的儲存庫，或是在封閉產品中含有 GPL 依賴項的儲存庫，會改變可以銷售的內容和方式：立即告知用戶，而不是等到最後。

如果 grep 在儲存庫中發現明文金鑰或密碼，請警告用戶，並且絕對不要將它們複製到文件中。

階段 2：渲染與截圖

啟動應用程式

按以下順序嘗試，並在第一個成功的方法處停止：

如果存在 Compose 檔案，則使用 docker compose up（最忠實的方式）。
使用輕量級本地資料庫（SQLite、Docker 中的 Postgres）的原生開發伺服器（npm run dev、python manage.py runserver、rails s、go run . 等）。
對於沒有後端的靜態網站和 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、2 倍縮放拍攝行動版。根據階段 1 的路由表編寫設定檔。

在繼續之前，使用 Read 工具查看每一張截圖：檢查空白頁面、頁面上呈現的控制台錯誤、像「Lorem」或「test123」這樣的佔位資料、難看的滾動條。重新製作那些無法通過買家判斷標準的截圖。

嵌入展示模型

使用 frame.py（位於末尾）在 02-screenshots/mounted/ 中產出：

每張桌面畫面都放在瀏覽器框架中，包含產品 URL、圓角、陰影、品牌顏色的漸層背景（如果品牌尚未建立，則使用中性深色）；
行動版畫面放在手機框架中；
一張 hero.png：桌面版畫面與行動版畫面在右下角重疊，作為展示的開場圖片。

如果應用程式真的無法啟動

在進行合理嘗試（幾個小時內）之後，用準確的原因告知用戶，並提供兩條路徑：他們提供應用程式可以運行的環境（一個暫存 URL、演示憑證），或者你繼續使用忠於程式碼的 HTML 重建稿，並標註為「重建」。不要自行選擇第二個選項。

階段 3：多租戶 SaaS 藍圖

如果專案已經是多租戶架構，此階段將記錄其現狀以及缺少哪些部分才能將其作為多租戶產品銷售。如果不是，則設計轉換方案。產出 03-saas-blueprint.md：

# SaaS 藍圖：<名稱>
## 目前狀態（單租戶 / 無隔離的多用戶 / 已多租戶）
## 推薦的租戶模型及其原因
   （共享資料庫加 tenant_id | 每個租戶一個 Schema | 每個租戶一個資料庫；根據資料量、合規性和成本進行論證）
## 程式碼中的變化（表格：領域 | 現在 | 未來 | 工作量 S/M/L）
   需始終涵蓋的領域：組織與邀請、驗證與角色（擁有者/管理員/成員）、
   資料隔離（查詢範圍限定、中介軟體、隔離測試）、計費與方案（Stripe 或類似服務）、
   每個方案的計量/限制、自助入職、內部管理面板、每個租戶的設定
   （標誌、自訂網域、功能開關）、附帶每個租戶金鑰的 API、資料匯出/刪除（GDPR）、
   稽核日誌、備份、可觀測性
## 三個階段的路線圖（可銷售的 MVP | 租戶就緒 | 企業就緒），附估算的人-週數
## 10 / 100 / 1,000 個租戶的估計運行成本
## 遷移風險

工作量估算必須基於你在程式碼中觀察到的情況（存在 ORM 還是手寫查詢、是否有既有測試），而不是行業平均值。當階段 4 顯示商業模式不是 SaaS（例如銷售程式碼庫）時，藍圖仍然可以作為「潛在發展方向」向買家展示，但必須以此為背景重新審視。

階段 4：商業訪談

使用 AskUserQuestion 工具執行，分 2 到 3 輪進行，絕不超過；每個問題的第一個選項都包含你從程式碼和分析中推斷出的預設值，並在旁邊標註「（提議）」，以便用戶一鍵確認。在提問之前，先寫一行文字說明你已經自行了解到的內容。

第 1 輪，我們在銷售什麼：

銷售標的物：訂閱制 SaaS | 白標籤/自託管授權 | 程式碼庫與資產銷售（Acquire、Flippa 等市集） | 終身方案 / 開放核心。這個答案會改變所有其他內容。
目標客戶（ICP）：行業、公司規模、付款方與使用者的角色、地理位置。
解決的問題與現有替代方案（Excel、競爭對手、無）。
產品狀態：概念 | 演示 | 有用戶的測試版 | 有收入的上線版。只有在用戶表示有真實數字時才詢問。

第 2 輪，金錢與承諾：

定價指標：每位使用者 | 每個租戶/組織 | 按使用量計費 | 固定費用。
方案層級與入門價格、貨幣、月費/年費、試用期或免費增值模式。提出三個層級並附上具體數字，參考價值與競爭對手；不要留空。
要突出顯示的差異化因素（最多 3 個）以及要提及或避免的競爭對手。
需要顯示的限制：GDPR、歐盟託管、SSO、整合方式。

第 3 輪，品牌與轉換：

產品名稱、網域、現有標誌或色調、語氣（嚴肅 B2B、直接、技術導向）。
展示語言與市場。
主要行動呼籲：候補名單 | 預約演示 | 免費試用 | 購買 | 聯絡方式，附上目標連結或電子郵件。
銷售簽署方（個人或公司、頁尾詳細資訊、隱私權政策連結，如果有的話）。

如果出現與此處不符的有用細節（合作關係、保證、包含的支援、程式碼移交），請詢問。將所有內容整合到 04-commercial-brief.md 中，包括保留預設值的選擇，並標記為「由 Claude 提議，待確認」。

如果用戶不在場（排程會話、無回應），則使用預設值繼續進行，並在摘要的開頭和最終回覆中標記。

階段 5：展示

一個自包含的 HTML 頁面（內嵌 CSS 和 JS，圖片在 img/ 中），響應式、快速、無外部框架。在編寫之前，如果會話中提供了 frontend-design 技能，請閱讀它：避免看起來千篇一律的登陸頁面。

章節按此順序，並根據銷售標的物進行調整：

主圖區：一個標題，說明對目標客戶的成果（而非產品名稱）、副標題說明方法、主要行動呼籲、嵌入的 hero.png。
問題：三個具體句子描述目標客戶目前的情況，不要誇大其詞。
功能：3-5 個區塊，每個區塊包含一張嵌入截圖，如果摘要允許，還包含一個可衡量的效益。僅包含分析標記為「完成」的功能；部分完成的功能放在「即將推出」下方或排除。
運作方式：從入門到實現價值的三個步驟。
多租戶 / 團隊 / 企業：如果藍圖顯示已準備就緒，則說明；如果是路線圖，則稱為路線圖。
定價：來自摘要的方案層級，突出顯示推薦層級並明確標示定價指標。
社會證明：僅當存在時才顯示。否則替換為「技術架構」（技術堆疊、安全性、合規性）或誠實的產品狀態（「處於測試階段，有 N 家公司使用」）。
常見問題：5-7 個買家會問的真實問題（資料、遷移、安全性、取消、支援）。
最終行動呼籲與頁尾，包含銷售方、聯絡方式、隱私權政策。

如果銷售標的物是程式碼庫，請將定價和多租戶替換為包含項目（技術堆疊、程式碼行數、測試覆蓋率、文件、依賴項、授權條款、移交時數）和潛在發展（藍圖摘要），並在 05-showcase/listing.md 中添加準備好發布到市集的文字。

寫作風格：簡短、具體的句子，使用選定的語言；不要有空泛的形容詞、不要有生成文本典型的結構（「它不是 X，它是 Y」、三個形容詞的列表、總結性的結尾語）。在義大利語中，永遠不要使用長破折號。

最終檢查：使用 Playwright 開啟 index.html，拍攝桌面版和行動版的螢幕，使用 Read 工具查看。確認所有圖片都已載入、沒有文字被截斷、並且在桌面版上無需滾動即可看到行動呼籲。然後，如果 Artifact 工具可用的話，將其作為工件發布（所有檔案，publish_files）。

階段 6：交付

在最終回覆中，按以下順序：展示頁面的連結（或檔案）、從分析中得出的 3 個最重要的事項（如果授權條款有問題，其中一個始終是授權問題）、待確認的商業預設值、以及具體的下一步行動（網域、支付、分析工具、第一個路線圖階段）。不要回顧階段：用戶已經看到它們了。

如果用戶有關於文件歸檔位置的規則（Google Drive、Notion），請套用。

軟體變銷售貨架