App Scorecard
如果 SKILL.md 旁有 LOCAL.md 檔案，請先閱讀它，它包含了此工作區的特定資訊（路徑、工具、範例），並會覆蓋下列通用預設值。
一套評分標準，每個應用程式，每次使用。重點在於可比較性：相同的維度、相同的 0–5 量表、相同的門檻，這樣三月份評分的應用程式在六月份再次評分時，其差異才有意義，兩個應用程式之間也可以進行比較，而無需重新爭論評分標準。
此技能源自「什麼讓應用程式卓越」研究報告（references/framework-source.md），並輔以針對性研究填補其缺口（references/research-notes.md）。完整 23 維度執行範例（已匿名化）：assets/example-audit.html。
原則（請先閱讀，它們主導一切）
- 門檻先於分數。 安全、隱私、法律、無障礙，以及對於任何斷言事實的應用程式的內容正確性，都是非補償性的。設計得 5 分無法彌補隱私得 0 分。請先列出未通過的門檻；切勿使用平均數。
- 證據勝過意見。 每個分數都附有證據等級（E0 斷言 → E4 穩固），每個發現都標記為 已觀察 / 推斷 / 假設 / 未知。
- 絕不從程式碼推斷行為。 除非有遙測數據、同類群組數據或問卷調查，否則留存率、互動度、市場契合度、滿意度、營收都是 未知。程式碼和螢幕截圖無法證明它們。請說「未知」，而不是「可能」。
- 階段決定評分標準。 產品-市場契合前期的應用程式是依據他們是否正在學習來評判，而非他們是否有服務水準目標。請參閱
references/stages.md。 - 節奏勝於基準。 沒有通用的 D7 留存率標準。一個每週使用的任務在「兩週內使用幾次」就是健康的。請先確定其自然使用節奏。
- 每個弱維度都有一個最小修復建議。 沒有修復建議的評分卡只是一份投訴。一行文字，可逆轉，以小時或天為單位衡量。
工作流程
0 · 框架（5 分鐘，不可跳過）
用一行文字分別定義：目標用戶 · 主要任務 · 自然使用節奏 · 首次價值事件 · 商業模式 · 主要替代方案（包括「什麼都不做」）。如果儲存庫中有 AGENTS.md / README.md，請從中獲取這些資訊並引用。如果缺失，則推斷，陳述假設，然後繼續。
然後選擇階段（references/stages.md）：
| 階段 | 訊號 | 評分標準 |
|---|---|---|
| 產品-市場契合前期 | < 約 100 個活躍用戶，無同類群組數據，或 Sean Ellis「非常失望」< 40% | 9 個維度 + 門檻 |
| 成長期 | 存在同類群組，> 100 個活躍用戶，或有付費客戶 | 完整 23 個維度 + 門檻 |
| 概念 / 規格 | 尚無程式碼 | 僅假設品質評分標準（stages.md §3） |
1 · 收集證據（可能時並行進行）
總是（程式碼 + 部署）：
- 路由 / 畫面、API 表面、身份驗證 + 授權執行（伺服器端？）
- 測試：執行它們。Lint：執行它。CI：讀取工作流程。部署：讀取腳本。
- 遙測：實際發送了什麼？（一個針對應用程式未託管平台的分析導入，等於什麼都沒有。）
- 儲存 / 資料庫：每個用戶寫入了什麼，是否有刪除功能，是否有備份。
- 隱私政策 / 服務條款 / 刪除路徑。付費 API 的速率限制和配額。
- 無障礙搜尋：
aria-,alt=,focus-visible,prefers-reduced-motion, 標籤。 - 國際化涵蓋範圍：字串外部化 vs 硬編碼，語言環境，複數 / 日期規則。
- 錯誤 / 空白 / 載入 / 離線狀態；路由層級的
error.tsx/not-found.tsx。 - 效能：伺服器端或客戶端的繁重數據處理、快取、記錄的 p95 百分位數（如有記錄）。
- 對於 AI / 參考應用程式：歸因 + 引用邏輯、基礎事實防護、幻覺控制、語料庫來源。
當可用時（行為）： beta 測試表單、分析數據、同類群組表、支援工單、Sean Ellis 問卷結果、觀察到的使用者會話。這些能將維度從「未知」提升到實際分數。沒有它們，請保持未知。
為了廣度，可派出最多 3 個唯讀的 Explore 子代理程式（最大 3 個並發）；自己則讀取入口點、導航、核心流程、身份驗證和儲存層。
2 · 檢查門檻
來自 references/rubric.md §Gates。每個門檻狀態為 未通過 / 已通過 / 不適用，並附上觀察到的證據。未通過的門檻會出現在每次輸出的頂部。常見範例：收集個人識別資訊時沒有隱私政策或刪除路徑；有付款功能卻沒有服務條款；缺少伺服器端身份驗證；針對年長觀眾的動畫效果沒有 prefers-reduced-motion；參考應用程式中歸屬不當或未引用的內容。
3 · 評分每個維度
針對所選評分標準中的每個維度（references/rubric.md）：
- 使用評分標準中的量表（非感覺）評分 0–5。
- 證據等級 E0–E4 並標記為 已觀察 / 推斷 / 未知。
- 勾選維度的核對清單項目：存在 / 部分 / 缺失 / 無法得知。
- 一行發現，基於一個
file:line、一個路由、一個設定或一個引用。 - 如果分數 ≤ 3，則提供一行的最小修復建議。
對於 UI / UX 設計，使用 rubric.md §UX Design 中的視覺設計子評分標準（字體排版、層級結構、色彩、間距、一致性、文案）。如果用戶需要此處的深度，請在評分卡之後調用 ui-usability-audit 技能，並參考其字母等級評分。
4 · 判斷
- 未通過的門檻（再次優先列出）。
- 贏的 3 大理由 · 輸的 3 大理由 · 3 大未知因素。
- 單一最高槓桿的下一步實驗或修復。
- 裁決：Go（可行） / Conditional Go（有條件可行） / Iterate（迭代） / No-Go（不可行），並附上信心水準。 經驗法則：任何未通過的門檻 ⇒ 最多 Iterate；所有門檻已通過 + 價值事件已埋點 ⇒ Conditional Go；在自然使用節奏下累積了四週的留存數據 ⇒ Go 才有可能。
5 · 交付 — 視覺化評分卡是主要交付物
交談訊息是摘要。發佈的 HTML 評分卡成品是輸出。 絕不能在不產生成品的情況下完成一次評分；如果 Artifact 工具不可用（Codex、子代理程式），則將 HTML 寫入應用程式儲存庫中的 docs/scorecards/<日期>-scorecard.html，然後改為發送 / 開啟該檔案。
- 建構成品，從
assets/scorecard-template.html開始。首先載入artifact-design技能，然後嚴格按照以下順序保持範本的結構，使每個應用程式的評分卡閱讀方式相同：- 標頭 —
<應用程式名稱> Scorecard，階段 + 證據來源 + 日期標題列，一句話論點，裁決標籤（go/ 預設琥珀色 /nogo類別），信心水準，以及框架陳述（用戶 · 任務 · 節奏 · 價值事件 · 替代方案）。 - 一覽網格 — 每個維度一個方塊，分數範圍著色（青綠色 ≥ 3，琥珀色 2，紅色 ≤ 1，灰色未知），任何帶有未通過門檻的維度顯示
gate外框，如果存在之前的執行結果則顯示 ▲/▼ 差異。 - 門檻 — 每個門檻一張卡片：未通過（紅色）或已通過（綠色），附上觀察到的證據以及
code格式的檔案/路由名稱。 - 各維度卡片，分組（策略與經濟 · 體驗與信任 · 工程與規模，或 Tier A 清單）：分數、證據徽章、2–4 句發現、帶有存在/部分/缺失/無法得知標記的核對清單，以及任何 ≤ 3 維度的最小修復建議。
- 最終判斷 — 三欄（贏的理由 · 輸的理由 · 關鍵未知因素）以及深色「最高槓桿下一步」面板。
- 方法備註 — 讀取了什麼、執行了什麼、拒絕了什麼；連結到前次執行結果。 設計規則：僅包含真實內容，無假文；所有顏色來自代幣集以支援深色模式；無表情符號、無裝飾性圖表；數位使用等寬字型。檢視渲染後的頁面一次，修正顯示的任何問題，然後發佈。
- 標頭 —
- 發佈，使用
Artifact。首次發佈時標題為<應用程式名稱> Scorecard，圖示 🔬。在重新執行時，請傳遞先前成品的url，這樣歷史記錄會維持在同一個連結（請在docs/SCORECARD.md中找到它）。 - 交談：先給出連結，然後是框架區塊、未通過的門檻、一個簡潔的表格（維度 · 分數 · 證據 · 發現）、裁決。簡潔扼要。不要重複成品的詳細內容。
- 持久化：在應用程式儲存庫的
docs/SCORECARD.md中新增一行記錄（如果檔案不存在則建立）：日期 · 階段 · 未通過的門檻 · 各維度分數 · 裁決 · 成品 URL。僅在使用者要求時才提交。
規則
- 完全閱讀，然後評分。 評分標準可以縮短判斷時間，但絕不能縮短閱讀時間。
- 當測試人員或檔案說明了某事，直接引用，不要改寫。
- 拒絕評分無法得知的項目。「未知」是一個有效且誠實的答案。
- 不要發明基準。 你唯一可以引用的數值閾值是
references/research-notes.md中定義的（SUS 68/80, Ellis 40%, CWV 2.5 s / 200 ms / 0.1, Nielsen severity 0–4, WCAG 2.2 AA, ASVS L1）。其他任何比較都只能與應用程式自身的先前執行結果進行。 - 跨應用程式使用相同的評分標準。 不要根據不同的應用程式添加或刪除維度。當某個維度確實不適用時（例如，內部工具的 Monetization 維度），將其標記為 n-a（不適用）—— n-a 會被記錄，而不是跳過。
- 僅使用開發/測試環境來操作真實應用程式。切勿使用正式環境。
- 唯讀。 評分卡提供建議；它不會編輯應用程式。
- 無成品，等於無評分。 僅存在於交談記錄中的評分卡在下個季度無法進行比較。務必發佈（或寫入 HTML 檔案）。
可組合的技能
ui-usability-audit— 深入 UX 設計維度，提供視覺上的前後對比。qa-sweep— 功能性的 PASS/FAIL 測試，為 Reliability 和 Core UX 維度提供輸入。dev-to-prod-promotion-review— 評分卡的裁決是發佈門檻的輸入之一。panel-brainstorm— 當「最小修復建議」需要產生替代方案時使用。