Use when users need help with Plugin Forge commands, want to discover available routes, or report documentation gaps. Triggers on "forge help", "how do I forge", "what forge commands", "kc-plugin-forge-help", "help with plugin forge", "what can forge do", "plugin forge help".
Use before making a public plugin feature PR ready or before a release-please publication to grep for known leak patterns in the plugin's public reference files. Triggered by "/kc-plugin-forge sanitize-check ", "sanitize-check", "check leaks before publish", "prepublish scan". Read-only safety net — NOT a replacement…
Use when creating a new Claude Code plugin, auditing an existing plugin for quality, improving plugin skills with TDD, or verifying plugin agent configurations.
Use when maintaining a kc-claude-plugins feature or release pull request, waiting for its GitHub checks, or synchronizing a released plugin into local Claude Code and Codex installs.
Use when verifying that a fix actually reaches the bug's break-point in the real runtime path — not just at unit-test level. Primary trigger is bugfix / cross-stack PR review (invoked by kc-pr-review). Also invoke standalone when pressure-testing a fix claim, pre-merge verification of cross-layer wiring, or debugging…
Use when a feature is complete with PR and demo artifacts (e2e walkthroughs, Loom, screenshots), and user wants to announce on Slack. Triggers on "announce", "post to product", "draft product message", "公告", or after PR + demo completion.
Use when user says 'create pr', 'open pr', '建立 PR', '開 PR', '發 PR', '送審', or when implementation is complete and changes need a pull request on GitHub.
Use when a feature branch has messy interleaved commits that need reorganization into logical groups before PR review. Triggers include "squash commits", "clean up history", "reorganize commits", "reorder commits", "too many commits". Not for simple squash-all — use git merge --squash instead.