ワンクリックでManusで任意のスキルを実行

始める

code-review

スター1

フォーク0

更新日2026年3月22日 21:10

On-demand code review for directories, git diffs, staged changes, or files. Manual invocation, structured feedback.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

snqb

snqb/my-skills

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Code Review Skill

Default Behavior

Review the last thing done in this conversation.

No args needed. Just say "review" or "review this".

If the context contains:

Code just written/edited → review that
Files just read → review those
Diffs shown → review the diff
Nothing obvious → ask what to review

Explicit Targets (optional)

"review staged changes"              → git diff --cached
"review diff main..HEAD"             → git diff main...HEAD
"review src/auth/"                   → read & review dir
"review last 3 commits"              → git diff HEAD~3..HEAD

Pyramid (Bottom = Most Important)

         ╱╲
        ╱  ╲   Style ← automate (ruff/eslint)
       ╱────╲
      ╱      ╲  Tests
     ╱────────╲
    ╱          ╲ Docs
   ╱────────────╲
  ╱              ╲ Implementation
 ╱────────────────╲
╱   API Design     ╲ ← FOCUS HERE
────────────────────

Source: morling.dev/blog/the-code-review-pyramid

Google Standard

Approve if it improves overall code health, even if not perfect.

No "perfect" code, only better code
Don't block on nitpicks
Balance progress vs. quality
Prefix optional feedback with Nit:

Source: google.github.io/eng-practices

What to Look For (Google)

Area	Check
Design	Does it belong here? Right abstraction?
Functionality	Works correctly? Edge cases? Concurrency?
Complexity	Can be understood quickly? Over-engineered?
Tests	Correct, sensible, useful?
Naming	Clear intent without being verbose?
Comments	Explain why, not what?
Style	Consistent? (delegate to linter)

Conventional Comments

Format: label: subject

Label	Meaning
`praise:`	Highlight good stuff
`nitpick:`	Minor, non-blocking
`suggestion:`	Propose improvement
`issue:`	Problem that must be addressed
`question:`	Need clarification
`thought:`	Idea for consideration
`chore:`	Cleanup/maintenance task

Decorations: (blocking), (non-blocking), (security), (performance)

suggestion (security): This SQL uses string concat.
Use parameterized queries to prevent injection.

Source: conventionalcomments.org

Red Flags

Security

SQL string concat → injection
eval()/exec() → RCE
Hardcoded secrets
Missing auth checks
pickle.load() untrusted data

Correctness

Uncaught exceptions in I/O
Race conditions
Resource leaks (files, connections)
Null/empty not handled
Off-by-one

Design

God object (10+ methods)
Boolean params (unclear at call site)
Deep nesting (3+ levels)
Copy-paste duplication

Output Format

## Review: <context>

### Summary
<1-2 sentences>

### Issues
**file:line** - `issue:`/`suggestion:`/`nitpick:`
<description>

### Good
<acknowledge quality>

### Questions
<clarifications needed>

Tone

From Google eng-practices:

❌ "Why did you do this?" ✅ "This approach adds complexity without benefit because..."

Comment on code, not developer
Explain why
Offer alternatives
Acknowledge good work

Automate First

Run before reviewing:

ruff check .                         # Python
eslint .                             # JS/TS
go vet ./... && staticcheck ./...    # Go
cargo clippy                         # Rust

Don't waste review time on what tools catch.

References

このリポジトリの他の Skills

同じリポジトリ

behavioral-testing

snqb/my-skills

Behavioral testing methodology — test what users experience, not how code is structured. Use when writing tests, reviewing test quality, planning test strategy for new features, or when existing tests are brittle/verbose/coupled to implementation details. Triggers: writing tests, TDD, test review, "tests keep breaking", "too many mocks", "tests are verbose", test coverage planning, behavior-driven development.

2026-04-071

bishkek-report

snqb/my-skills

Summon 8–12 fictional but statistically plausible people from Kyrgyzstan to judge your web app. They take screenshots, click around, get confused, get delighted, and write honest reviews in Russian. Output: a single .md report with embedded screenshots. Use when you need brutal UX feedback from people who ride marshrutkas.

2026-04-071

artemy

snqb/my-skills

Artemy Lebedev-style бизнес-линч design review. Opens the site in a real browser, screenshots everything, then tears it apart (or praises it) in his signature voice — brutal, specific, visual. Use when you want a no-bullshit design review, 'линч', 'lebedev review', 'artemy review', or 'roast my site'.

2026-04-021

autoresearch

snqb/my-skills

Autonomous experiment loop — modify code, measure, keep/discard, repeat forever. Based on Karpathy's autoresearch pattern. Use when there's working code + a measurable metric to optimize. Agent works while you sleep.

2026-04-021

deep-research

snqb/my-skills

Iterative deep research agent — recursive breadth×depth tree search that accumulates learnings, generates follow-ups, and produces cited reports. Uses exa + serper + subagents. Use when user says 'deep research', 'investigate', 'deep dive', 'thorough analysis', or needs multi-source synthesis with depth.

2026-04-021

design-audit

snqb/my-skills

Detect and fix design system leaks — default shadcn/bootstrap/MUI styling breaking through your brand. Use when: UI feels 'template-y', 'looks like shadcn', 'too generic', buttons are inconsistent colors, cards look default, or after shipping many features fast. Also: 'audit my design', 'check consistency', 'brand leak', 'fix the defaults'.

2026-04-021

name	code-review
description	On-demand code review for directories, git diffs, staged changes, or files. Manual invocation, structured feedback.

Code Review Skill

Default Behavior

Review the last thing done in this conversation.

No args needed. Just say "review" or "review this".

If the context contains:

Code just written/edited → review that
Files just read → review those
Diffs shown → review the diff
Nothing obvious → ask what to review

Explicit Targets (optional)

"review staged changes"              → git diff --cached
"review diff main..HEAD"             → git diff main...HEAD
"review src/auth/"                   → read & review dir
"review last 3 commits"              → git diff HEAD~3..HEAD

Pyramid (Bottom = Most Important)

         ╱╲
        ╱  ╲   Style ← automate (ruff/eslint)
       ╱────╲
      ╱      ╲  Tests
     ╱────────╲
    ╱          ╲ Docs
   ╱────────────╲
  ╱              ╲ Implementation
 ╱────────────────╲
╱   API Design     ╲ ← FOCUS HERE
────────────────────

Source: morling.dev/blog/the-code-review-pyramid

Google Standard

Approve if it improves overall code health, even if not perfect.

No "perfect" code, only better code
Don't block on nitpicks
Balance progress vs. quality
Prefix optional feedback with Nit:

Source: google.github.io/eng-practices

What to Look For (Google)

Area	Check
Design	Does it belong here? Right abstraction?
Functionality	Works correctly? Edge cases? Concurrency?
Complexity	Can be understood quickly? Over-engineered?
Tests	Correct, sensible, useful?
Naming	Clear intent without being verbose?
Comments	Explain why, not what?
Style	Consistent? (delegate to linter)

Conventional Comments

Format: label: subject

Label	Meaning
`praise:`	Highlight good stuff
`nitpick:`	Minor, non-blocking
`suggestion:`	Propose improvement
`issue:`	Problem that must be addressed
`question:`	Need clarification
`thought:`	Idea for consideration
`chore:`	Cleanup/maintenance task

Decorations: (blocking), (non-blocking), (security), (performance)

suggestion (security): This SQL uses string concat.
Use parameterized queries to prevent injection.

Source: conventionalcomments.org

Red Flags

Security

SQL string concat → injection
eval()/exec() → RCE
Hardcoded secrets
Missing auth checks
pickle.load() untrusted data

Correctness

Uncaught exceptions in I/O
Race conditions
Resource leaks (files, connections)
Null/empty not handled
Off-by-one

Design

God object (10+ methods)
Boolean params (unclear at call site)
Deep nesting (3+ levels)
Copy-paste duplication

Output Format

## Review: <context>

### Summary
<1-2 sentences>

### Issues
**file:line** - `issue:`/`suggestion:`/`nitpick:`
<description>

### Good
<acknowledge quality>

### Questions
<clarifications needed>

Tone

From Google eng-practices:

❌ "Why did you do this?" ✅ "This approach adds complexity without benefit because..."

Comment on code, not developer
Explain why
Offer alternatives
Acknowledge good work

Automate First

Run before reviewing:

ruff check .                         # Python
eslint .                             # JS/TS
go vet ./... && staticcheck ./...    # Go
cargo clippy                         # Rust

Don't waste review time on what tools catch.