菜单
規劃或實作任何 product 功能前，先用程式碼驗證 docs/product 的狀態標示是否為真。docs/product 的 PRD/FRD 狀態普遍落後於程式碼——直接照文件規劃會重做一個早就上線的功能。Use before planning a feature, estimating scope, writing an OpenSpec change, or answering "這功能做了沒". Triggered by keywords: PRD, FRD, 規劃, 這功能, 還沒做, 規劃中, roadmap, scope, plan feature.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
PR merge 後的收尾流程：歸檔 openspec change、更新 docs/product 功能狀態、校準地圖文件。Use when a PR is merged, the user says 合併了/merged/上線了, or after confirming a PR's merge status.
PRD 快速生成、需求補洞、優化顧問三合一工具。從需求產出完整 PRD，多角色檢視缺漏，再優化成工程師友善文件。Use when writing a new PRD, reviewing an existing PRD for gaps, or optimizing PRD readability. Triggered by keywords: PRD, 需求文件, 產品規格, 規格書, user story, acceptance criteria, 驗收條件.
依島島 GTM 策略產出 TA 導向的行銷內容——部落格文章、社群貼文（Threads/IG/FB）、回覆別人的文案。Use when user says "寫一篇文章"、"寫貼文"、"幫我回覆這篇"、"招生文"、"揪團文"、"寫 threads"、"content"、"文案"。自動套用語氣鐵律、TA 痛點語言與模板 CTA。
Use when asked to summarize or analyze monthly user activity and interaction data. Queries DB for MAU, DAU trends, check-in counts, reactions, comments, follows, retention rate, and top users/practices. Generates narrative insights via daodao-ai-backend LLM and outputs a markdown report or writes to Notion.
Use when sending personalized congratulation emails to users who completed a practice. Queries the DB for completed practices, generates personalized email content via daodao-ai-backend LLM, previews samples for confirmation, then sends via email API. Always runs in dry-run mode first.
在 daodao 任務 Notion DB 建立新卡片。Use when user says "開 Notion 卡"、"建 notion 單"、"新增任務"、"create notion card"、"開一張卡"、"記到 notion"。從對話或報告自動推斷欄位，互動確認後建立。
| name | product-status-check |
| description | 規劃或實作任何 product 功能前，先用程式碼驗證 docs/product 的狀態標示是否為真。docs/product 的 PRD/FRD 狀態普遍落後於程式碼——直接照文件規劃會重做一個早就上線的功能。Use before planning a feature, estimating scope, writing an OpenSpec change, or answering "這功能做了沒". Triggered by keywords: PRD, FRD, 規劃, 這功能, 還沒做, 規劃中, roadmap, scope, plan feature. |
docs/product/** 底下的 PRD/FRD 是在規劃當下寫的，功能上線後沒有人回頭改它的狀態。
所以文件寫「規劃中 / 待實作 / Phase 1」時，程式碼裡那個功能可能早就上線了。
如果你照文件當地圖去規劃或報 scope，你會做出兩種錯誤之一：
2026-07-06 的實地盤點：至少六個功能「文件說規劃中、程式碼已上線」——快速回應（6 種 reaction）、兩層留言含 @mention、關注／連結、複製實踐、靈感牆 feed、許願池＋公開 Roadmap。這不是特例，是系統性現象。
docs/product的狀態標示一律當成「未知」，不是「未完成」。動工前必須用程式碼查一次。 文件與程式碼衝突時，以程式碼為準——這也是各 repo CLAUDE.md 的既有工作守則。
一個功能只要「後端路由 ＋ API service ＋ 前端頁面」三者都在，就是已上線，無論 PRD 怎麼寫。逐 repo 查：
| 要查什麼 | 去哪查 | 指令 |
|---|---|---|
| server 端點 | daodao-server/src/routes/<domain>.routes.ts | grep -n "router\." src/routes/<domain>.routes.ts |
| ai-backend 端點 | daodao-ai-backend/src/routers/*.py | grep -rn "@router" src/routers/ |
| worker 端點 | daodao-worker/src/ | 看 zod-openapi 路由定義 |
| f2e API 層 | daodao-f2e/packages/api/src/services/ | ls 找 <domain>.ts + <domain>-hooks.ts |
| f2e 頁面 | daodao-f2e/apps/product/src/app/[locale]/ | find ... -type d，找對應路由 |
| DB 資料表 | daodao-storage/schema/ 與 migrate/sql/ | 表存在 ≠ 功能上線；表在但 API 空＝只做了一半 |
判讀：
docs/product 完全沒有對應資料夾 → 孤兒功能，沒人在產品面維護（如 mentor.routes.ts）。動它之前先問使用者定位。docs/product/prd/learning-ecosystem.md（八層生態＋通電度，校準日 2026-07-06）。超過數週的任何快照都要重跑上面的驗證法，不要照抄。.claude/skills/system-map（各子 repo 內）。這份「每次動工前手動查」的 skill 是止血；根治的機制已建好：
scripts/product_status_manifest.yml——功能 → 宣稱狀態 → 程式碼 signal 的對照清單，也是目前最可靠的狀態索引。要快速知道某功能真實狀態，先查這裡。scripts/check_product_status.py——比對 manifest 與各 repo 程式碼，漂移就報（--ci 有漂移時 exit 1）。本地跑：python3 scripts/check_product_status.py --verbose --projects-dir <各 repo 的上層目錄>。.github/workflows/product-status-drift.yml——每週一自動跑，漂移發 Discord。你動 product 功能時的義務：新功能就往 manifest 補一筆（declared 照 PRD 當下狀態填、signal 填真實存在的路徑）。這樣 CI 才能在它上線後自動抓到 declared 過期，而不是等下一個 AI 再踩一次。
codebase-map、system-map）有明確維護規範且較新，不在本 skill 的懷疑範圍；本 skill 專指 daodao/docs/product/** 的產品狀態標示。