一键在 Manus 中运行任何 Skill

verification

星标40

分支4

更新时间2026年7月3日 13:23

交付前驗證紀律：依變更類型選擇最小充分驗證組合（unit / 目標 E2E / happy-path CI / make build）、Makefile 打包檢查、i18n 連動、GEMINI.md key_files 同步、誠實回報。當使用者提到「驗證、收尾、完成了嗎、可以交付嗎、送 PR 前、檢查一下」或任何實作即將收尾時觸發。

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

Tai-ch0802

Tai-ch0802/arc-like-chrome-extension

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Verification Skill — 完成的定義

「寫完 code」不等於「完成」。本 skill 定義宣稱完成前必須通過的驗證，以及對應變更類型的最小充分火力表——不多跑浪費時間，不少跑帶病交付。

核心原則

驗證強度對應變更風險，不是一律全跑（npm run test:full 全套很貴），也不是一律不跑。
宣稱什麼，就要驗過什麼。說「修好了」之前要親眼看到修好的證據；說「不影響其他功能」之前要跑過對應測試。
誠實回報：測試失敗就回報失敗與輸出，跳過的步驟就明說跳過。絕不把「應該會過」寫成「已通過」。

驗證火力表（依變更類型取聯集）

變更類型	必跑	說明
純文件（docs/、*.md、spec）	無自動化	人工檢查連結與檔案引用是否存在
`modules/utils/`、純函式、`modules/sync/syncLogic`	`npm run test:unit`	單元測試最快，先跑
UI / renderer / 互動邏輯	相關單一 E2E 檔 → `npm run test:ci`	先跑最相關的一檔（快），過了再跑 happy-path 全套
`manifest.json` / `Makefile` / 新增檔案	`make` + `make release`，並檢查 zip 內容	漏打包是本專案歷史事故，見下方檢查法
`background.js` / service worker 邏輯	相關 E2E + 手動情境思考「SW 終止後還對嗎」	in-memory 狀態存活性
測試本身的修改	該測試檔連跑 3 次	排除 flaky 假陽性

# 常用指令
npm run test:unit                                          # 單元測試（秒級）
npx jest usecase_tests/puppeteer_tests/<related>.test.js   # 目標 E2E
npm run test:ci                                            # happy-path 全套（CI 等價）
make && make release                                       # 兩種 build 都要能過

連動檢查清單（改 code 之外的義務）

Makefile：新增/改名的檔案是否已在 DEV_SRC_FILES？prod 需要的話是否在 PROD_STATIC_FILES 或 esbuild 指令中？驗證法：unzip -l arc-sidebar-v*-dev.zip | grep <新檔名>。
i18n：新增使用者可見文案 → _locales/（14 語）要補 key；README / store description 層級的文案 → 觸發 update-multilingual-docs skill。
GEMINI.md key_files：新增模組或改變既有模組職責時同步更新描述（專案歷史約定）。
spec 對照（T1/T2 案件）：逐條核對 SPEC.md 驗收條件 / PRD Acceptance Criteria，在 PR description 回報結果。
暫時性產物清除：debug 用 console.log、截圖檔、暫存 md 檔都已移除。

回報格式（PR description 或對話收尾）

驗證結果：
- npm run test:unit：✅ 42 passed
- npx jest .../happy_path_search.test.js：✅ 4 passed
- make && make release：✅ 產物包含新檔案 modules/foo.js
- 未跑：npm run test:full（變更不涉及其他動線；CI 會跑）

有失敗就照實列出失敗輸出與你的判斷（是本次變更造成、還是既有 flaky——flaky 判斷依據見 debugging skill）。

同仓库更多 Skills

同仓库

pull-request

Tai-ch0802/arc-like-chrome-extension

建立本專案的 Pull Request：雙語描述 (zh-TW/en)、gh CLI、.agent/skills/pull-request/scripts/check-pr.sh 預驗證、references/pr_template.md 與 checklist.md。當使用者提到「開 PR、建 PR、create PR、pull request、提交變更、發 PR、新建 PR」時觸發。

2026-07-0340

debugging

Tai-ch0802/arc-like-chrome-extension

本專案 (MV3 Chrome extension) 的除錯紀律與 playbook：先重現再修、證據優先於模式匹配、單變因修改、跨 context 時序問題、service worker 終止、storage 問題、flaky E2E 分流。當使用者提到「除錯、debug、壞掉、不會動、修不好、查原因、root cause、flaky、時好時壞」時觸發。

2026-07-0340

harness-maintenance

Tai-ch0802/arc-like-chrome-extension

維護本專案 AI agent harness（AGENTS.md / CLAUDE.md / GEMINI.md / .agent/{rules,skills,workflows} / docs/wiki）的 SOP：單一事實來源對照表、drift 稽核步驟、新增/刪除 skill 的判準、wiki 同步機制。當使用者提到「更新 harness、同步 AGENTS、文件過時、drift、稽核設定檔、整理 skills、維護 wiki」時觸發。

2026-07-0340

cleanup-merged-branches

Tai-ch0802/arc-like-chrome-extension

清理已合併進 main 的本地與遠端 git 分支。本專案採 squash merge，PR 合併後特性分支可直接刪除。當使用者提到「清理分支、cleanup branches、刪除舊分支、清掉已合併分支、整理 branch」時觸發。

2026-06-1040

commit-message-helper

Tai-ch0802/arc-like-chrome-extension

本專案 (Manifest V3 Chrome extension) 的 commit 規範與範例：subject 使用英文 Conventional Commits、body 使用繁中說明背景與原因。當使用者提到「commit、提交訊息、commit message、寫 commit、commit 規範」時觸發。

2026-06-1040

prd

Tai-ch0802/arc-like-chrome-extension

撰寫本專案的 PRD (產品需求文件)，位置為 /docs/specs/{type}/{ID-PREFIX}_{desc}/PRD_spec.md。當使用者提到「PRD、產品需求、需求文件、寫規格、新功能規劃、acceptance criteria」時觸發。分級 SDD 之 T2（完整流程）的 Phase 1，產出物提供給 sa skill 銜接；T1 輕量案件不需獨立 PRD。

2026-06-1040

name	verification
description	交付前驗證紀律：依變更類型選擇最小充分驗證組合（unit / 目標 E2E / happy-path CI / make build）、Makefile 打包檢查、i18n 連動、GEMINI.md key_files 同步、誠實回報。當使用者提到「驗證、收尾、完成了嗎、可以交付嗎、送 PR 前、檢查一下」或任何實作即將收尾時觸發。

Verification Skill — 完成的定義

核心原則

驗證強度對應變更風險，不是一律全跑（npm run test:full 全套很貴），也不是一律不跑。
宣稱什麼，就要驗過什麼。說「修好了」之前要親眼看到修好的證據；說「不影響其他功能」之前要跑過對應測試。
誠實回報：測試失敗就回報失敗與輸出，跳過的步驟就明說跳過。絕不把「應該會過」寫成「已通過」。

驗證火力表（依變更類型取聯集）

變更類型	必跑	說明
純文件（docs/、*.md、spec）	無自動化	人工檢查連結與檔案引用是否存在
`modules/utils/`、純函式、`modules/sync/syncLogic`	`npm run test:unit`	單元測試最快，先跑
UI / renderer / 互動邏輯	相關單一 E2E 檔 → `npm run test:ci`	先跑最相關的一檔（快），過了再跑 happy-path 全套
`manifest.json` / `Makefile` / 新增檔案	`make` + `make release`，並檢查 zip 內容	漏打包是本專案歷史事故，見下方檢查法
`background.js` / service worker 邏輯	相關 E2E + 手動情境思考「SW 終止後還對嗎」	in-memory 狀態存活性
測試本身的修改	該測試檔連跑 3 次	排除 flaky 假陽性

# 常用指令
npm run test:unit                                          # 單元測試（秒級）
npx jest usecase_tests/puppeteer_tests/<related>.test.js   # 目標 E2E
npm run test:ci                                            # happy-path 全套（CI 等價）
make && make release                                       # 兩種 build 都要能過

連動檢查清單（改 code 之外的義務）

Makefile：新增/改名的檔案是否已在 DEV_SRC_FILES？prod 需要的話是否在 PROD_STATIC_FILES 或 esbuild 指令中？驗證法：unzip -l arc-sidebar-v*-dev.zip | grep <新檔名>。
i18n：新增使用者可見文案 → _locales/（14 語）要補 key；README / store description 層級的文案 → 觸發 update-multilingual-docs skill。
GEMINI.md key_files：新增模組或改變既有模組職責時同步更新描述（專案歷史約定）。
spec 對照（T1/T2 案件）：逐條核對 SPEC.md 驗收條件 / PRD Acceptance Criteria，在 PR description 回報結果。
暫時性產物清除：debug 用 console.log、截圖檔、暫存 md 檔都已移除。

回報格式（PR description 或對話收尾）

驗證結果：
- npm run test:unit：✅ 42 passed
- npx jest .../happy_path_search.test.js：✅ 4 passed
- make && make release：✅ 產物包含新檔案 modules/foo.js
- 未跑：npm run test:full（變更不涉及其他動線；CI 會跑）

有失敗就照實列出失敗輸出與你的判斷（是本次變更造成、還是既有 flaky——flaky 判斷依據見 debugging skill）。