claude-plugins

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.

Systematic diagnosis workflow — find root cause before proposing any fix. This skill should be used when encountering bugs, crashes, errors, test failures, unexpected behavior, build failures, stack traces, or performance problems. Do NOT skip to fixes before completing Phase 1.

Fix a bug using TDD. Diagnose root cause, write a failing test, then fix. This skill should be used when the user asks to "fix a bug", "debug and fix", "find and fix", or encounters a failing test, crash, or regression that needs a code fix. For diagnosis only without fixing, use /diagnose instead.

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.

Enforce TDD discipline with Shadow Run validation and AI-specific guardrails. Auto-loaded when writing tests, implementing features, or fixing bugs. Ensures tests are written before implementation, fail before passing (Shadow Run), and are never deleted or weakened by AI. Skip for pure refactoring with existing test coverage.

Clean up existing code by identifying smells and applying safe refactoring. Behavior must not change. This skill should be used when the user asks to "refactor", "clean up code", "simplify", "extract function", "reduce complexity", or mentions code smells, tech debt, or structural improvements. For bug fixes use /fix. For new features use /write.

Define the interface contract before writing any implementation code. This skill should be used when the TypeScript interface or function signature does not yet exist, the public API or return type is changing, or you cannot immediately name 3+ boundary cases without stopping to think. Output: behaviour description (Given/When/Then), TypeScript interface, invariants list. Do NOT use for internal refactoring or bug fixes where the public interface is unchanged.

Implement a small to medium feature with TDD approach. This skill should be used when the user asks to "write a feature", "implement", "add functionality", "build", or describes a new feature to create. For large features requiring architecture exploration, consider a feature-dev plugin.