
Read, write, and sync project memory stored as Markdown under `~/.agents/memories/{project-name}/`. Use when starting work and needing project context, when the user asks to read or update memory, or when ending a session and preserving stable learnings. Triggers: "read memory", "load memory", "write memory", "save memory", "update memory", "sync memory", "refresh memory", "读取记忆", "加载记忆", "写入记忆", "保存记忆", "更新记忆", "同步记忆".
Review a GitHub Pull Request as a responsible project owner using the `gh` CLI. Use when the user provides a PR URL (e.g. https://github.com/ORG/REPO/pull/N) or a PR number for the current git repo (prefer upstream, else origin) and wants an owner-grade review document `review-N.md` written in Chinese with copy-pastable GitHub comments in English. Scope the review to lines changed by the PR (do not nitpick unrelated pre-existing code), but apply best practices and flag any clear bugs, security issues, or CI failures caused by the change.
Export current session state as a structured HANDOFF.md for another LLM to continue work. Captures: current goal, files changed, what was tried, what worked, dead ends, and next steps. Use when: user says "handoff", "export state", "save progress", "session export", "pass to another LLM", "clone yourself", "create handoff", "wrap up", "done for now", "bye", or at session end when ongoing work needs continuity. Output is a self-contained prompt that another LLM can use to resume work exactly where this session left off.
Ship staged changes through a narrow release flow: auto-clean staged files, block unexpected non-i18n CJK additions, create or keep a branch, commit staged work, push, and open a pull request — all without confirmation. Use mainly when the user explicitly invokes `/ship` or says "ship it", "push and PR", or "commit and PR". Do not use for commit-only, push-only, PR-only, or existing-PR editing requests. All generated git and GitHub text must be in English.
Cross-tool vibe coding profiler. Scans AI coding tool data on the machine (Claude Code sessions, OpenCode DB, Codex sessions), combined with git history and project memory, to build a true user portrait, discover workflow automation opportunities, and update the target tool's instruction file (CLAUDE.md or AGENTS.md) accordingly. Use when: "calibrate", "vibe-calibrate", "分析我的习惯", "profile me", "update my CLAUDE.md based on my history", "我的效率怎么提升", "analyze my patterns", "优化我的配置", or at the start of a long-term engagement with a new user.
Generate a concise Chinese evaluation prompt for DevOps CLI / command-line tool projects based on clig.onev.dev guidelines, with weights, thresholds, and hard gates. Use when a user asks to create or store a reusable CLI review prompt, a scoring rubric, an evaluation checklist, or wants to evaluate a command-line interface, terminal tool, or CLI best practices against design guidelines.
Generate a deep, code-first project wiki and VitePress documentation site (DeepWiki-style) for a repository. Use when asked to create a complete wiki/manual for a new codebase, build a code-first documentation site, or generate a `codewiki/` folder with structured Markdown, diagrams, and navigation based on the source code (not existing docs).
Use the `gmc` CLI for explicit gmc requests: generate commit messages, create or remove worktrees, prune merged worktrees, discover or sync shared resources, or run other `gmc wt` subcommands. Triggers mainly when the user invokes `/gmc` or mentions `gmc wt add`, `gmc wt prune`, `gmc wt share`, `gmc wt sync`, `gmc tag`, or asks to use gmc for commit or worktree automation. Do not use for generic git or generic worktree requests unless the user specifically wants `gmc`.
Multi-model code review for pull requests and git diffs. Use when asked to "review my code", "review this PR", "review my changes", "find reviewers", or "run a code review". Suggests appropriate reviewers based on which files changed, runs iterative review rounds across multiple AI models, and tracks findings across sessions.
Generate repo-local coding and review skills from a repository's git history and GitHub PR review activity. Use when asked to create, refresh, or update repository-specific coding/review skills, learn from PRs, analyze commit history, extract coding patterns, or generate coding guidelines for the current repo or a specific module.
Dispatch a bug or task report into conflict-aware PR-sized worktrees with `gmc wt add` and write LLM-ready `todo.md` files in each worktree. Use when the user explicitly asks to dispatch bugs from a report, split a bug or task report into PRs, create worktrees from a report, or hand off fixes into separate worktrees. Typical input is the output of `critical-bug-finder` or any structured bug report with identifiable files, problems, and fix goals. Do not use for generic bug finding, generic issue triage, or normal project planning without a report file.
Find critical implementation bugs that can crash production, corrupt data, bypass security, deadlock, race, or break core logic. Use for explicit fatal bug hunts such as "find critical bugs", "audit for fatal bugs", "security vulnerability audit", "race condition audit", "find crash or data loss bugs", or reliability incident reviews. Do not use for general code review, refactoring, style feedback, or routine performance analysis.
GitHub issue management toolkit for project maintainers and contributors. Four modes: (1) scan — find contributable issues ranked P0-P5, (2) reply — draft and post concise maintainer responses to specific issues, (3) triage — classify issues and assign/remove labels, (4) analyze — deep root-cause or feature-design analysis saved to markdown. Use when: managing GitHub issues, finding contribution opportunities, replying to issues, triaging issues, labeling issues, analyzing bugs, designing features from issues, "what can I work on", "reply to this issue", "triage issues", "analyze this bug", "label these issues", "find easy issues", "show me contributable issues", issue cleanup, issue management, project maintenance, open source contribution discovery. Do not use for: PR review, code review, issue creation from scratch, or general GitHub operations unrelated to issue management.
Ruthless code simplifier: flatten abstractions, inline wrappers, remove unnecessary layers, delete dead code — without changing behavior. Use when: user says "simplify", "simplify this", "flatten", "inline", "too complex", "over-engineered", "remove abstraction", "unwrap", "reduce complexity", "make it simpler", "this is too complicated", or points at code that has unnecessary indirection. Does NOT change behavior, break public APIs, or remove meaningful error handling.
撰写微信公众号技术文章的结构化工作流。使用场景:用户要写一篇公众号文章、需要创建文章目录、组织素材、迭代草稿。强制遵循 blogs/wechat/README.md 的命名规范和目录结构。