菜单
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when starting feature work that needs isolation from current workspace, before executing implementation plans, or when reviewing an existing branch (e.g. a PR) without switching away from the current branch. It creates isolated git worktrees under `.worktrees/`.
Use this skill when working on terminal UI rendering, interactive CLI prompts, ANSI color output, terminal screenshots, Bubble Tea/Lip Gloss/Huh/Glamour, curses-style apps, or CLI tests that depend on TTY behavior.
Use this skill when you're working with golang code.
Use whenever asked to create GitHub Pull Request.
Use when writing, rewriting, or updating a pull request description. Use this skill's explicit PR template unless the user provides a different template for the current task, keep the result concise and human-readable, explain why the change exists, and ask the user for motivation before updating the PR when the user has not explicitly provided it.
Use this skill whenever writing, editing, reviewing, or deciding whether to add code comments, docstrings, inline comments, or internal function documentation in any programming language. Use it even when the task only mentions "comments", "docs in code", "docstrings", "document this function", or "explain this helper".
| name | requesting-code-review |
| description | Use when completing tasks, implementing major features, or before merging to verify work meets requirements |
Dispatch the code-reviewer agent to catch issues before they cascade.
The reviewer gets precisely crafted context for evaluation — never your session's history.
This keeps the reviewer focused on the work product, not your thought process,
and preserves your own context for continued work.
Core principle: Review early, review often.
Scope guard:
code-reviewer agent, perform the review directly.Mandatory:
Optional but valuable:
1. Determine scope:
By default the reviewer inspects unstaged changes (git diff).
For committed work specify the files or commit range explicitly.
2. Dispatch code-reviewer agent:
Use the Agent tool with subagent_type: "code-reviewer" and a prompt that includes:
3. Act on feedback:
[Just completed Task 2: Add verification function]
You: Let me request code review before proceeding.
[Dispatch code-reviewer agent]
Prompt:
Review the unstaged changes in git diff.
I just added verifyIndex() and repairIndex() functions to handle
4 types of index corruption. Focus on correctness and error handling.
[Agent returns]:
Issues:
Important [85]: Missing progress indicators for long-running repair
Critical [92]: repairIndex() swallows errors from writeFile()
Assessment: Fix before proceeding
You: [Fix the issues]
[Continue to Task 3]
Subagent-Driven Development:
Executing Plans:
Ad-Hoc Development:
Never:
If reviewer wrong: