Menu
Vibe-SDLC Phase 1：定義規格文件與計畫，協助撰寫與審查 PRD、SRD、SDD、API Spec、Dev Plan。 使用時機：專案啟動需要建立規格文件與計畫，或需要審查既有規格的完整性與一致性。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Vibe-SDLC Agent 狀態查詢與彙整。讀取各 Agent 狀態檔，彙整為全局 STATUS.md，提供即時專案現況。 使用時機：想掌握各 Agent 工作狀態、專案全局現況、或需要彙整 STATUS.md 時。
Vibe-SDLC 流程總覽與導航。顯示完整 SDLC 流程、角色定義，並引導使用者進入對應的 Phase skill。 使用時機：專案啟動、查看目前進度、不確定該用哪個 Phase skill 時。
Vibe-SDLC Phase 3：開發循環 (Execution Loop)。領取 Issue 進行開發、測試、Vibe Check，通過後自動建立 PR。 使用時機：日常開發，需要從看板領取 Issue 並實作功能。
Vibe-SDLC Phase 4：CI 監控、失敗修正與合併後作業。處理 CI 結果、修正失敗、Merge 後更新 Dev Plan。 使用時機：PR 已建立（由 Phase 3 自動建立），需要監控 CI、處理失敗、或執行合併後作業。
Vibe-SDLC Phase 5：回饋收集、Release 發佈與迭代規劃。 使用時機：里程碑收尾完成（由 Phase 4 觸發），需要收集回饋、發佈 Release、啟動下一輪迭代。
Vibe-SDLC Phase 2：任務掛載 (Planning → Issues)。審核 Dev Plan 完整性，並自動建立 GitHub Issues。 使用時機：規格文件已定稿，需要將開發計畫轉換為 GitHub Issues 與看板任務。
| name | vibe-sdlc-spec |
| description | Vibe-SDLC Phase 1：定義規格文件與計畫，協助撰寫與審查 PRD、SRD、SDD、API Spec、Dev Plan。 使用時機：專案啟動需要建立規格文件與計畫，或需要審查既有規格的完整性與一致性。 |
| user_invocable | true |
建立專案的完整真相來源（Single Source of Truth）。此階段應充分與開發者討論，生成高品質規格文件與計畫，所有後續工作皆以此為依據。
你是 AI 助手（執行者）。在此階段你的職責是：
你不應該：在需求定義階段自行決定商業需求或技術選型，這些應該在需求完成後與開發者討論後進行決策。
CLAUDE.md、/docs 目錄皆不存在，skill 會自動進入「空專案初始化」流程）| 文件 | 檔名 | 存放路徑 | 類型 | 說明 |
|---|---|---|---|---|
| 文件入口與導航 | 00-Docs_Index.md | /docs/00-Docs_Index.md | 必要 | 規格文件導航索引，列出所有文件清單、建立/更新時機、依賴關係 |
| 產品需求文件 (PRD) | 01-1-PRD.md | /docs/01-1-PRD.md | 必要 | 偏重產品面或客戶的需求及要求，可能衍生 UI/UX 需求 |
| 系統需求文件 (SRD) | 01-2-SRD.md | /docs/01-2-SRD.md | 必要 | 非功能性需求（NFR）、部署要求、約束與安全合規 |
| 系統設計文件 (SDD) | 01-3-SDD.md | /docs/01-3-SDD.md | 必要 | 系統架構、元件設計、數據模型、技術決策記錄（ADR） |
| 遊戲設計文件 (GDD) | 01-4-GDD.md | /docs/01-4-GDD.md | 領域選用 | 遊戲專案專用：核心機制、數值設計、關卡設計。僅遊戲類專案需要 |
| API 介面規格 | 01-5-API_Spec.md | /docs/01-5-API_Spec.md | 必要 | API 規格說明 |
| API 介面合約 | API_Spec.yaml | /docs/API_Spec.yaml | 必要 | OpenAPI 規格 |
| UI/UX 設計文件 | 01-6-UI_UX_Design.md | /docs/01-6-UI_UX_Design.md | 選用 | UI/UX 設計規格（視覺風格、互動流程、Design Tokens），若 PRD 衍生 UI/UX 需求時建立。撰寫前 必須 先讀 references/UI_UX_Writing_Guidelines.md |
| UI Wireframe | ui/{page}.html | /docs/ui/*.html | 選用 | 每個頁面一檔的 HTML + Tailwind CDN 視覺參考，由 01-6-UI_UX_Design.md 以 link 引用（規則詳見 UI_UX_Writing_Guidelines.md §9） |
| 開發執行計畫 | 02-Dev_Plan.md | /docs/02-Dev_Plan.md | 必要 | 里程碑、任務拆解、依賴關係 |
| 規格審查報告 | 03-Docs_Review_Report.md | /docs/03-Docs_Review_Report.md | 必要 | 交叉比對結果、不一致與遺漏項目 |
| CI/CD 規格文件 | 04-CI_CD_Spec.md | /docs/04-CI_CD_Spec.md | 選用 | CI Workflow 定義、品質閘門、Docker 部署配置（複雜專案建議獨立，Dev Plan 以連結引用） |
重要：
若需建立 01-6-UI_UX_Design.md，AI 助手必須先讀取 references/UI_UX_Writing_Guidelines.md 並遵循該指引的 9 條準則撰寫。指引重點：
/docs/ui/，由 markdown 規格書以 relative link 引用（準則 9）UI/UX 產出物結構：
/docs/01-6-UI_UX_Design.md — 規格權威（markdown，AI 實作時以此為準）/docs/ui/{page}.html — 視覺參考（每個 §3.x 頁面對應一檔，低保真 wireframe 使用灰階 palette）核心原則：markdown 規格書是實作權威，HTML wireframe 是視覺輔助。兩者衝突時以 markdown 為準。
所有 /docs 規格文件皆須包含版本管理資訊，格式如下：
> **版本**：v{major}.{minor}
> **最後更新**：{YYYY-MM-DD}
---
## 版本修訂說明
| 版本 | 日期 | 修訂內容 |
|------|------|---------|
| v1.0 | 2026-03-16 | 初版定稿 |
| v1.1 | 2026-03-21 | {修訂摘要，列出新增/修改的章節與內容} |
| 變更類型 | 版本遞進 | 範例 |
|---|---|---|
| 新增功能需求（如新增 PRD-F-XXX） | minor +1 | v1.0 → v1.1 |
| 修正錯誤、補充遺漏、格式調整 | minor +1 | v1.1 → v1.2 |
| 重大架構變更、破壞性修改 | major +1 | v1.2 → v2.0 |
每次修改 /docs 下的規格文件時，必須同步更新以下三處：
注意：OpenAPI YAML 檔（如
API_Spec.yaml）的版本號寫在info.version欄位，修訂說明寫在info.description欄位中。
請參考 examples/docs/ 目錄下的文件。
| 步驟 | 執行者 | 操作 | 產出 |
|---|---|---|---|
| 0 | 開發者 | 建立文件入口：初始化 Docs Index，登錄預計建立的文件清單 | 00-Docs_Index.md |
| 1 | 開發者 | 撰寫 PRD：定義功能清單、使用者故事、資料欄位，並與開發者討論並優化 PRD | 01-1-PRD.md |
| 2 | 開發者 | 撰寫 SRD：當 PRD 定義完成後，定義非功能性需求（NFR）、部署要求、約束與安全合規 | 01-2-SRD.md |
| 3 | 開發者 | 撰寫 SDD：當 SRD 定義完成後，定義系統架構、技術棧選型、數據模型、設計決策記錄（ADR） | 01-3-SDD.md |
| 4 | 開發者 | 定義 API Spec：以 OpenAPI 格式定義所有端點、請求/回應結構 | 01-5-API_Spec.md, API_Spec.yaml |
| 5 | 開發者 | 撰寫 Dev Plan：當 PRD、SRD、SDD、API Spec 定義完成後，拆解里程碑、任務清單、任務間依賴關係 | 02-Dev_Plan.md |
| 6 | 開發者 | 確認以上文件均已提交至 /docs 目錄並推送至倉庫 | Git commit & push to Github (or Gitlab) |
| 7 | AI 助手 | 交叉比對 /docs 下規格文件，產出完整性審查報告 | 審查報告 |
| 8 | 開發者 | 審閱報告，修正規格缺漏後重新提交 | 最終版規格 |
SRD 與 SDD 的分工：SRD 定義「系統應該達到的需求與約束」（如性能目標、安全要求），SDD 負責描述「如何設計系統來滿足這些需求」（如架構選型、元件設計）。
領域專用文件：遊戲類專案應在步驟 1 之後額外建立
01-4-GDD.md（遊戲設計文件），定義核心機制、數值設計與關卡設計。其他領域專用文件（如資料設計文件）可視需求於適當步驟加入。
可依需求規格相關文件(包含PRD、SRD、API Spec、...等)生成 Dev Plan(開發計畫)，然後與開發者討論並優化。
範例文件：02-Dev_Plan.md
API_Spec.yaml 解耦，Sub Agents 可高度並行開發。必須在文件最開頭以表格定義所有角色，包含：角色代號、角色名稱、類別 (🧑 人類 / 🤖 AI)、GitHub 帳號、Git Author、說明。後續全文引用角色時必須使用此處定義的代號，禁止前後不一致。
建議角色配置：
| 類別 | 建議角色 | GitHub 帳號 | 說明 |
|---|---|---|---|
| 🧑 人類 | H-Director (導演) | @owner | 最高決策、規格審查、Milestone 驗收、PR 合併 |
| 🧑 人類 | H-Reviewer (審查員) | (同 Director 或獨立帳號) | 特定領域審查（安全/合規性），可由 Director 兼任 |
| 🧑 人類 | H-UxReviewer (UX 審查員) | (同 Director 或獨立帳號) | UX 相關審查，可由 Director 兼任或由 AI Agent 代理 |
| 🤖 AI | A-Main (主代理) | (同 Director 或獨立帳號) | 統籌拆解 Issue、協調 Sub Agents、整合驗證 |
| 🤖 AI | A-Backend (後端子代理) | @ext-dev 或 @owner | 專注後端 API、DB、ORM |
| 🤖 AI | A-Frontend (前端子代理) | @ext-dev 或 @owner | 專注 UI 組件、頁面、狀態管理 |
| 🤖 AI | A-QA (測試子代理) | (同 Director 或獨立帳號) | E2E 測試、覆蓋率 |
| 🤖 AI | A-DevOps (部署子代理) | (同 Director 或獨立帳號) | CI/CD、Docker、監控 |
多帳號協作：多個角色可共用同一 GitHub 帳號（單人專案），也可每個角色使用獨立帳號（多人或外部成員協作）。角色表中需填寫
GitHub 帳號與Git Author，並在 §1.5 中配置認證方式與 Repo 權限。詳細配置步驟請參考 帳號配置指南。
| ID | 任務名稱 | 優先級 | 負責角色 | 前置任務 | PR 策略 | 預估耗時 |
|----|---------|-------|---------|---------|--------|----------|
| T-101 | [任務名稱] | P0 | A-Backend | — | 與 T-102 合併 | ~N AI Sessions |
| T-102 | [任務名稱] | P0 | A-Backend | — | 與 T-101 合併 | ~N AI Sessions |
| T-103 | [任務名稱] | P0 | A-Frontend | — | 獨立 PR | ~N AI Sessions |
| T-104 | [任務名稱] | P0 | A-DevOps | T-102, T-103 | 獨立 PR | ~N AI Sessions |
| ⛳ M1 | M1 驗收門 | P0 | H-Director | T-103, T-104 | — | ~N HRH |
—。—。AI Sessions (一次完整 Agent 對話執行)；人類角色用 HRH (Human Review Hours)。P0 為關鍵路徑必須完成、P1 為重要但非阻塞、P2可選任務但建議完成(時間允許時應該完成此任務)、P3可選任務(可做可不做，但若完成對專案可能有加分效果)。每個任務以下列結構描述：
**T-{ID}：{任務名稱}**
- **任務描述**：概述該任務的目標
- **主要步驟**：
1. 步驟一：具體操作描述
2. 步驟二：具體操作描述
3. ...
- **前置任務**：前置任務 ID，若無填 `（無）`
- **輸入**：依賴或參考的文件，若無填 `（無）`
- **產出**：此任務的輸出/產出文件或源碼，若無填 `（無）`
- **驗證**：
- ✅ 自動：可在 CI 中自動執行的驗證（單元測試、lint、type check、build）
- 👁️ 手動：需人工操作的驗證（視覺效果、裝置測試、外部 API 整合）
- **優先級**：任務的優先等級
主要步驟：以 numbered list 條列該任務的具體執行步驟，便於 Sub Agent 逐步對照執行。步驟應具體到可操作的程度（如「安裝依賴 X」、「實作 Y 端點」），而非抽象描述。
驗證分類：每個驗證條件必須標記為
✅ 自動或👁️ 手動，明確區分 CI 可執行與需人工操作的項目。
flowchart 的 fork/join 語法視覺化並行關係subgraph 標示同 Agent 的依序執行關係，與跨 Agent 並行區分。package.json 和 npm scripts），但所有功能開發任務必須依賴 CI 就緒，確保功能 PR 提交時已有自動品質閘門。骨架任務 → CI 任務 → 功能開發任務。04-CI_CD_Spec.md，Dev Plan 以連結引用，避免 Dev Plan 過於冗長。✅ 自動（CI 可執行）與 👁️ 手動（需人工操作），不可混為一談。subgraph 標示 Agent 內部的依序關係。👁️ 手動 項目時，每個手動驗證項應建立獨立的 Issue，指派給對應的人類審查角色。指派原則：
| 驗證類型 | 指派角色 | 範例 |
|---|---|---|
| 視覺效果、互動體驗、UI 佈局、動畫、裝置相容性 | H-UxReviewer | 預算血條顏色漸變、PWA 安裝體驗、語音按鈕手動測試 |
| 安全性、合規性、API 整合、資料正確性 | H-Reviewer | LLM 引擎整合測試（需真實 API Key）、權限驗證 |
| 端到端業務流程、功能驗收 | H-Director | 完整記帳流程操作驗證 |
命名規範：手動驗證 Issue 標題格式為 [驗證] T-{ID} {驗證項目簡述}，例如：
[驗證] T-201 Gemini/OpenAI 引擎整合測試[驗證] T-203 語音辨識瀏覽器相容性測試[驗證] T-302 預算血條視覺效果驗收文件中所有流程圖、時間表、依賴關係圖，一律使用 Mermaid 語法，禁止使用 ASCII Art。建議圖表：
ganttflowchart LRflowchart TB (fork/join 模式)當多個 Sub Agents 並行開發時，Dev Plan 應包含以下 Git 協作規範：
checkout 切換衝突。git worktree add ../worktree-<agent> <branch>⛔ 嚴格禁止直接 push 至 main，所有變更一律透過分支 + PR 流程。main 為唯讀基準分支，dev/main-agent 為 A-Main 的快照分支（不承接任何工作 commit）。
| 條件 | 分支命名 | 生命週期 | 說明 |
|---|---|---|---|
| 有 Issue | feat/<agent>/issue-N-簡述 | 短期 | 所有 Issue-based 開發，PR 合併後刪除 |
| 無 Issue（小修） | chore/main-agent/<YYYYMMDD>-<簡述> | 短期 | typo、文案、聯調連續小修；從 origin/main 建出，PR 合併後刪除 |
| A-Main 快照 | dev/main-agent | 永久（允許 force-update） | 由 /vibe-sdlc-status 管理，僅承載 STATUS / dashboard 快照 commit。嚴禁承接工作 commit 或從其分出新分支 |
Per-issue 分支範例：
feat/backend/issue-12-auth-apifeat/frontend/issue-15-login-uifeat/devops/issue-20-docker-setupChore 分支範例：
chore/main-agent/20260410-typo-readmechore/main-agent/20260410-integration-fixesdev/main-agent 快照分支生命週期：
git checkout -b dev/main-agent origin/main && git push -u origin dev/main-agent/vibe-sdlc-status 在彙整 STATUS 時 git reset --hard origin/main + 重新 commit + git push --force-with-lease/vibe-sdlc-status 的「A-Main 快照分支」章節與 /vibe-sdlc-dev 的「分支策略」M1 中，CI Pipeline 本身就是開發任務之一（如 T-104），在 CI 就緒前提交的初始化 PR 無法經過 CI 閘門檢查：
gh pr create --reviewer <H-Director-username>| 場景 | 通知方式 |
|---|---|
| Bootstrap 階段 | gh pr create --reviewer <H-Director-username>，GitHub 自動發送 Review Request 通知 |
| 標準流程 | A-Main 初審通過後執行 gh pr edit --add-reviewer <H-Director-username>，GitHub 自動通知 |
| Milestone 驗收 | A-Main 在 GitHub Issue 中 @H-Director 並附上驗收檢查清單 |
flowchart LR
SUB["Sub Agent<br/>gh pr create"] --> CI["GitHub Actions<br/>CI 檢查"]
CI -->|通過| MAIN["A-Main 初審"]
CI -->|失敗| SUB
MAIN -->|通過| REQ["A-Main 執行<br/>gh pr edit<br/>--add-reviewer H-Director"]
REQ --> DIR["H-Director<br/>收到 GitHub 通知<br/>終審 & Merge"]
MAIN -->|駁回| SUB
main（或指定的整合分支）。gh pr edit --add-reviewer <H-Director-username> 通知 H-Director。| Sub Agent 角色 | 允許修改的路徑 |
|---|---|
| A-Backend | /backend/** |
| A-Frontend | /frontend/** |
| A-QA | /tests/** |
| A-DevOps | .github/**, docker/**, Dockerfile, docker-compose.yml |
| A-Main | 全專案 (整合與修復用) |
當執行步驟「交叉比對規格文件」時，按以下格式產出報告至 /docs/03-Docs_Review_Report.md：
# 規格完整性審查報告
## 審查範圍
- 比對文件：00-Docs_Index.md, 01-1-PRD.md, 01-2-SRD.md, 01-3-SDD.md, 01-5-API_Spec.md, 02-Dev_Plan.md, ...
## 不一致項目
| 編號 | 文件 | 不一致描述 | 建議修正 |
|------|------|------------|----------|
> 註： 「文件」可以列出多個文件，若包含多個文件之間存在不一致，請將所有不一致項目列於此表格中。
## 遺漏項目
| 編號 | 文件 | 遺漏描述 | 應補充至 |
|------|------|----------|----------|
## 結論
- 不一致項目：N 項
- 遺漏項目：N 項
- 建議：[通過 / 需修正後重新審查]
/docs/00-Docs_Index.md 已建立，且所有文件皆已登錄/docs當使用者呼叫此 skill 時，必須先偵測專案是否為空，依下列層次判定並引導：
| 層次 | 偵測指令 | 缺什麼 |
|---|---|---|
| L1 | test -d .git | 本地 git 倉庫 |
| L2 | git remote -v 輸出為空 | GitHub / GitLab 遠端 |
| L3 | test -f README.md && test -f .gitignore | 專案基礎檔 |
| L3.5 | test -f CLAUDE.md（且檔案非空） | Claude Code 專案指引 |
| L4 | test -d docs | /docs 目錄 |
| L5 | test -f docs/00-Docs_Index.md | Docs Index 與規格文件 |
僅在 L4 與 L5 皆缺失（即 /docs 目錄不存在或完全沒有規格文件）時觸發初始化面板。若使用者已有 /docs 內容，直接進入「行為指引」既有流程，不打擾。
偵測到空專案時，輸出下列面板並等待使用者選擇，禁止自動執行：
🌱 偵測到這是新專案，Vibe-SDLC 可協助初始化以下項目：
──────────────────────────────────────────────────
{✅/❌} L1 git init（本地倉庫）
{✅/❌} L2 GitHub remote 設定
{✅/❌} L3 .gitignore / README.md
{✅/❌} L3.5 CLAUDE.md（專案指引）
{✅/❌} L4 /docs 目錄
{✅/❌} L5 /docs/00-Docs_Index.md 骨架
{✅/❌} A-Main 快照分支 dev/main-agent
請選擇：
1️⃣ 全部執行（推薦，新專案一鍵 bootstrap）
2️⃣ 只建立 /docs 骨架 + Docs Index（已有 git 時）
3️⃣ 我想逐項確認
4️⃣ 跳過初始化，直接進入規格撰寫流程
請選擇（1/2/3/4）：
{✅/❌} 依實際偵測結果填入（已存在為 ✅，缺失為 ❌）。
選項 1 — 全部執行：依下列順序執行，每一步執行前以一句話備註用途，執行失敗則停下報告：
.git/ 不存在，執行 git init 並建立初始 commit 佔位（空 commit 或含 README）.gitignore 或 README.md，建立最小骨架：
.gitignore：至少包含 .env, .env.*, node_modules/, dist/, build/, *.log, .DS_Store, docs/status/（若採用 STATUS 模式 B/C）README.md：含專案名稱 + 一句話描述 + Vibe-SDLC 連結/docs/ 目錄，並從 examples/docs/00-Docs_Index.md 複製一份作為 /docs/00-Docs_Index.md，將「專案名稱」與文件清單改為占位符待使用者填寫git checkout -b dev/main-agent（A-Main 快照分支，從 main 分出；若尚無 commit，先完成 step 1 的初始 commit）。建立後不立即在其上做任何 commit；後續由 /vibe-sdlc-status 管理完成後輸出下一步建議：「初始化完成，接下來會協助你撰寫 PRD，請先告訴我專案要解決什麼問題。」
選項 2 — 只建 docs 骨架：只執行上方步驟 3、4（CLAUDE.md + docs 骨架），跳過 git 與基礎檔相關動作。適合已有 git repo 但剛從別的 SDLC 切換過來的專案。
選項 3 — 逐項確認：依序對每個 ❌ 項目詢問「是否執行？(y/N)」，使用者答 y 才執行該項。
選項 4 — 跳過：不做任何初始化動作，直接進入既有的「行為指引」流程（由使用者自行決定從哪份規格開始）。
本 skill 提供骨架模板：templates/CLAUDE.md.template（含 {PROJECT_NAME}、{PROJECT_DESCRIPTION}、{BACKEND_STACK} 等占位符）。
情境 A：CLAUDE.md 不存在
{PROJECT_NAME}{PROJECT_DESCRIPTION}templates/CLAUDE.md.template 讀取內容，置換占位符<project_root>/CLAUDE.md情境 B：CLAUDE.md 已存在但缺少 Vibe-SDLC 區塊
偵測方式：grep CLAUDE.md 是否包含 /vibe-sdlc 字串。若不包含：
templates/CLAUDE.md.template 擷取「## Vibe-SDLC 流程」整段（包含核心原則），以 append 方式寫入既有 CLAUDE.md 末尾情境 C：CLAUDE.md 已存在且已含 Vibe-SDLC 區塊
跳過，不動它。
前置檢查：先執行 git remote -v，若已有 origin 指向有效遠端（非占位），則直接跳過整段流程。
若本地 git 有 commit 但無 remote，輸出下列選擇面板並等待使用者選擇：
🔗 GitHub Remote 尚未設定
──────────────────────────
選擇建立方式：
A 由 AI 代為建立（執行 gh repo create，需要 gh 已登入）
B 我要自己手動建立
C 先跳過，稍後再設定
請選擇（A/B/C）：
選項 A — AI 代為建立：
gh auth status 若失敗，提示使用者先執行 gh auth login，然後改選 B 或 Cbasename $(pwd)，可覆寫）gh api user --jq .login 取得的當前使用者，可覆寫）private / public / internal（預設 private）即將執行：
gh repo create <owner>/<name> --private --source=. --remote=origin --push
git push -u origin dev/main-agent
執行？(y/N)：
選項 B — 使用者手動建立：
輸出完整指令清單供使用者複製：
請依序執行以下指令（可依需求調整參數）：
# 1. 建立 GitHub repo（擇一）
# 方式 A：使用 gh CLI
gh repo create <name> --private --source=. --remote=origin --push
# 方式 B：在 GitHub 網頁建立空 repo 後手動加 remote
git remote add origin git@github.com:<owner>/<name>.git
git branch -M main
git push -u origin main
# 2. 將常駐分支推上遠端
git push -u origin dev/main-agent
設定完成後告訴我一聲，我會繼續後續流程。
輸出後暫停流程等待使用者回報，不進入後續 PRD 撰寫。
選項 C — 先跳過：
記錄「稍後再設定 remote」，繼續後續流程（進入 PRD 撰寫）。提醒使用者：「Phase 2 建立 Issues 時必須要有 remote，請在那之前完成 remote 設定。」
初始化完成後（或偵測到非空專案時），依下列流程協助使用者：
/docs 目錄是否存在，以及已有哪些規格文件/docs/00-Docs_Index.md 不存在：建議先建立文件入口，作為後續文件的導航索引references/UI_UX_Writing_Guidelines.md 的 9 條準則（逐條列出符合/違反，違反項必須寫入審查報告）：
/docs/ui/*.html wireframe 且 markdown 已 link 引用ui/{page}.html#{anchor} link；HTML 對應 <section> 有 id 屬性/docs/ui/*.html wireframe 是否包含 <meta name="fidelity"> 與 <meta name="spec-ref"> 標籤01-4-GDD.md）/vibe-sdlc-issues）