メニュー
Use this skill after completing multiple, complex software development tasks before informing the user that work is complete.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/sammcj/agentic-coding --skill code-reviewコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Summarises the delta between a tool's latest release and the last summary the user saw. Use when the user asks about what's new, the latest release, release notes, or the changelog of one of the supported tools: Claude Code, OpenCode, llama-swap, or llama.cpp.
You **MUST** load this skill before the skill-creator skill AND before making ANY change to, or conducting a review of ANY Agent Skill. Triggers include creating, editing, reviewing, or contributing to any part of an Agent Skill (description, frontmatter, body, references, scripts, trigger evals, conflicts, etc).
Use when creating, editing or debugging Ghostty terminal configuration - config.ghostty files, config option names and their valid values, keybinds and key sequences, themes, fonts, shell integration, or `ghostty +` CLI actions. Covers macOS and Linux/GTK differences.
SOC 職業分類に基づく
SKILL.md を表示中
| name | code-review |
| description | Use this skill after completing multiple, complex software development tasks before informing the user that work is complete. |
Run a structured review over the changes in scope. Two modes:
Fix mode only. If you were asked only to review, stop at step 3 and report your findings.
If a finding is especially complex or keeps recurring, use the systematic-debugging skill to get to the root cause.
Direct sub-agents to evaluate the changes across these dimensions. The questions below are illustrative, not a fixed checklist. Apply the ones that fit and raise the concerns that actually matter for this codebase's language, domain, and conventions:
Create checklists or TODOs for yourself (or the sub-agents) to ensure your coverage is thorough.
On top of whatever the repo documents, the Readability and Architecture axes always carry this fixed set of Fowler code smells (Refactoring, ch.3). It applies even when a repo documents no standards of its own. Two rules bind it:
Pass this list to the sub-agents verbatim - they have no other access to it. Each smell reads what it is → how to fix; match it against the diff and name the smell in the finding.
switch/if-cascade on the same type recurs across the change. → replace with polymorphism, or one map both sites share.a.b().c().d() navigation the caller shouldn't depend on. → hide the walk behind one method on the first object.Refactors leave orphans. After changing code, list anything now unused (replaced functions, components, constants) and ask before removing it, rather than deleting silently or leaving it to rot.
Where appropriate use sub-agents to parallelise your work and reduce context bloat in the main conversation.
The fixes, or the findings are the deliverable, so open with the (concise) outcome, not preamble or a description of your process.
file:line, the problem, and a concrete fix. If nothing substantive turned up, say so in a line.State real issues plainly and drop the hedging ("might want to consider", "could potentially"); tag anything optional as low and move on. Batch style nitpicks into a single note rather than scattering them. Don't close with a summary that restates the list. A short report flagging the few things that count beats a long one padded with the obvious.