| name | vibe-coding-risk-check |
| description | 檢查 vibe coding / AI-assisted coding 專案在公開上線、beta、收費或上架前的第三方服務限制風險。當使用者提供 README、package.json、env.example、工具清單、產品描述，或提到 Clerk、Supabase、Firebase、Vercel、Resend、Stripe、RevenueCat、Expo、EAS、App Store、Google Play、pricing、quota、usage、launch checklist、服務風險、自我檢查時，務必使用此 skill。此 skill 只產出報告與待辦，不修改使用者專案。 |
Vibe Coding Risk Check
這個 skill 用來幫使用者檢查 vibe coding 專案的第三方服務、免費額度、限制規範、成本與上線風險。使用者通常不是要你修程式，而是要知道「AI 幫我做出的產品能不能公開使用」。
工作原則
- 只產出報告與待辦，不修改專案檔案。
- 不假裝知道最新價格。涉及價格、免費額度、quota、limits、developer fee、store policy 時，優先查官方來源；無法查證就標「需人工確認」。
- 用繁體中文、台灣用語，工具名保留英文。
- 面向非純工程背景創作者，避免只講內部技術名詞。
- 成本估算用區間與風險等級，不假裝精準。
- 明確區分 prototype、alpha、beta、public launch、monetization。
觸發情境
使用者可能會說：
- 幫我檢查這個 vibe coding 專案有沒有服務限制風險。
- 我用 Clerk / Supabase / Vercel 做了一個 MVP，幫我看上線前要注意什麼。
- 這個專案準備 beta / launch / 收費 / 上架，幫我做 checklist。
- 我貼 README / package.json / env.example，你幫我掃用了哪些服務。
- 我只有工具清單，幫我做風險評估。
輸入來源
優先讀取使用者提供的內容：
- 產品描述：產品類型、目標使用者、是否要收費、是否要上架。
- README：功能、部署、服務、環境變數說明。
- package.json：依賴套件、framework、SDK。
- env.example / app config：服務名稱、API key 名稱、domain、callback。
- 工具清單：使用者口述或貼上的服務列表。
如果使用者只提供部分資訊，不要中斷；先產出「基於目前資訊」的報告，並列出缺口。
服務偵測規則
從文字、依賴與環境變數中找這些類別：
| 類別 | 常見訊號 |
|---|
| Auth | Clerk、Supabase Auth、Firebase Auth、Auth0、Kinde、Better Auth、NEXT_PUBLIC_CLERK、AUTH_SECRET |
| Database | Supabase、Firebase、Neon、PlanetScale、Prisma、Postgres、MongoDB、DATABASE_URL |
| Hosting | Vercel、Netlify、Cloudflare、Railway、Render、Fly.io |
| Storage | Supabase Storage、Firebase Storage、S3、Cloudinary、R2、UploadThing |
| Email | Resend、SendGrid、Postmark、Mailgun、SES、SMTP |
| Payment | Stripe、RevenueCat、Apple IAP、Google Play Billing、Paddle、Lemon Squeezy |
| Analytics | Sentry、PostHog、Firebase Analytics、Crashlytics、Vercel Analytics |
| Mobile | Expo、EAS、React Native、App Store Connect、Google Play Console |
| AI API | OpenAI、Anthropic、Gemini、Vercel AI SDK、LangChain、LangGraph |
官方查核來源
優先使用官方 pricing / limits / docs / changelog。常見入口：
如果不能即時查網路，明確寫：「以下為基於使用者提供資料與一般風險模型的初步檢查，價格與限制需依官方頁重新查核。」
報告格式
ALWAYS 使用以下結構：
# Vibe Coding 服務風險檢查報告
## 1. 摘要
- 專案狀態：
- 主要風險：
- 最先可能爆的限制：
- 是否適合 public launch：
## 2. 偵測到的服務
| 類別 | 服務 | 偵測依據 | 用途 | 查核狀態 |
|---|---|---|---|---|
## 3. 風險矩陣
| 風險等級 | 類別 | 問題 | 為什麼重要 | 建議動作 |
|---|---|---|---|---|
## 4. 官方資訊查核
查核日期：YYYY-MM-DD
| 服務 | 官方 URL | 目前可引用的限制摘要 | 需人工確認 |
|---|---|---|---|
## 5. 100 / 500 / 1000 使用者估算
| 規模 | 可能先爆的限制 | 建議 |
|---|---|---|
| 100 使用者 | | |
| 500 使用者 | | |
| 1000 使用者 | | |
## 6. 上線前 Checklist
### Prototype
- [ ] ...
### Alpha
- [ ] ...
### Beta
- [ ] ...
### Public Launch
- [ ] ...
### Monetization
- [ ] ...
## 7. 缺口與下一步
- ...
風險等級
- 高：可能導致使用者無法註冊、資料外洩、付款錯誤、服務停用、帳單失控、上架被拒。
- 中：可能導致體驗不穩、debug 困難、成本不明、客服壓力增加。
- 低：目前不阻擋上線，但應建立紀錄、監控或後續優化。
五階段 Checklist 預設項目
Prototype
- 記錄 AI 幫忙接上的第三方服務。
- 每個服務補上 pricing / limits URL。
- 不用大量假信箱測發信。
- 不把測試 key 當正式 key。
Alpha
- 用 5 到 10 個陌生帳號測註冊、登入、登出、忘記密碼。
- 檢查 production domain、callback URL、redirect URL。
- 檢查 secret 沒有放在前端或 public repo。
- 確認資料權限不是全公開。
Beta
- 預估 100、500、1000 使用者時的成本。
- 測接近 quota 上限時的行為。
- 建立 usage dashboard 截圖或紀錄。
- 加上 error monitoring 與客服回報入口。
Public Launch
- 設定 billing alert 或 usage alert。
- 確認資料備份與匯出方式。
- 補 privacy policy、terms、support email。
- 若是 mobile app，補 App Store / Google Play 資料收集、權限、帳號刪除與商店素材。
Monetization
- 付款流程有 webhook 驗證。
- premium 權限由 server-side 或可信來源判斷。
- 測付款失敗、訂閱取消、refund、trial 到期。
- 查 Apple / Google / Stripe / RevenueCat 的規則邊界。
常見輸出語氣
好：
- 「目前最先可能爆的是 Email quota，因為註冊驗證信、忘記密碼信與通知信會共用額度。」
- 「這個數字需依官方 pricing page 重新查核，不能直接寫進對外文章。」
- 「這不是阻止你 launch，而是建議先完成 public launch 前的最低安全檢查。」
避免：
- 「這個服務永遠免費。」
- 「一定不會超過限制。」
- 「我猜大概不用付費。」
- 「我直接幫你修改專案。」
Test Prompts
用這三種情境測 skill：
- Next.js + Clerk + Supabase + Vercel 專案，應抓出 auth、DB、hosting、email 或缺 email 風險。
- Expo + Firebase + RevenueCat 專案，應抓出上架、IAP、build、推播、資料安全風險。
- 只有工具清單，沒有 repo，仍要輸出人工自檢報告與缺口。
