菜单
Verification gate before claiming work is complete, fixed, or passing. Evidence before claims — run lint + test + build before any completion statement. Auto-loaded by /write, /fix, /refactor at completion step.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Static risk review of a GitHub Pull Request — correctness, breaking changes, security, secret leaks, test/error-handling/type/comment risks. This skill should be used when the user asks to "review this PR", "review a pull request", "audit a PR", gives a PR URL or owner/repo#number, or wants a pre-merge risk check. Does NOT run tests/build/lint or modify files. For local uncommitted diff review use /review instead.
Security-vet a third-party GitHub repository BEFORE using, cloning into a project, or installing it. Clones to an isolated directory (never executes repo code) and statically scans for credential theft, hidden outbound connections, install-time attacks (malicious postinstall / setup.py), obfuscated payloads, supply-chain risks, leaked secrets, and dangerous CI workflows. Outputs a verdict report (BLOCK / CAUTION / PASS). Use this skill whenever the user asks "is this repo safe", "scan this repo", "can I trust this project", "會不會偷 key", "這個 repo 安全嗎", "掃描這個 repo", "幫我檢查這個專案可不可以用", or pastes a GitHub URL of an unfamiliar project they intend to install or run. Not for reviewing the user's own code (use /review) and not for auditing changes on the current branch (use /security-review).
Sync the Notion PAI second-brain (Projects, To-Do, Inbox, Knowledge Base) with the local gbrain knowledge graph. `pull` mirrors Notion into gbrain (down); `push` sends local gbrain edits up to Notion (up-only — a page changed on the Notion side is left for the next pull, never clobbered). Includes interactive first-time init. Use when the user says /notion-sync, init notion sync, sync notion, pull notion, push notion, refresh brain, notion sync status, notion sync conflicts, notion sync doctor, 初始化 notion, 同步 notion, 拉取 notion, 推回 notion, 雙向同步, brain 沒更新, 檢查 notion 同步, notion 衝突. Sub-commands: init, pull, push, conflicts, schedule, status, doctor. Do NOT use for: ad-hoc Notion page edits (use Notion MCP tools like notion-update-page), general gbrain queries (use mcp__gbrain__* directly), or installing gbrain itself (use gbrain CLI per RUNBOOK.md Step 1).
Enforce project-specific coding constraints that Claude does not apply by default: function length limits (50 TS / 60 Python), dependency injection over concretions, and structured data class selection. Auto-loaded by /write, /fix, /review, /refactor when designing interfaces or checking architecture. Do NOT use for refactoring (use /refactor) or bug fixes (use /fix).
Review local code changes for style, test quality, and architecture. This skill should be used when the user asks to "review code", "review my changes", "check code quality", "review the diff", or wants a pre-commit code review. Not for GitHub PR review — use /pr-review instead.
AI-era technology decision framework for tech selection, architecture choices, and build-vs-buy analysis. This skill should be used when comparing frameworks, services, tools, or libraries, evaluating architecture approaches (monorepo vs multi-repo, SSR vs SSG), deciding build vs buy, or assessing whether to upgrade or stay. Trigger phrases: "which should I use", "A vs B", "should I switch to", "build or buy", "upgrade or stay", "compare X and Y", "what is the best option for". Do NOT use for pure implementation tasks where the technology choice is already made.
基于 SOC 职业分类
| name | done |
| description | Verification gate before claiming work is complete, fixed, or passing. Evidence before claims — run lint + test + build before any completion statement. Auto-loaded by /write, /fix, /refactor at completion step. |
| user-invocable | false |
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
If you have not run the verification command in this message, you cannot claim it passes.
Find verification commands in: package.json scripts, Makefile, pyproject.toml, CI config, or README.
Run the full chain (lint + test + build), not just one step.