Code review

Skill s-hiraoku/synapse-a2a/plugins/synapse-a2a/skills/code-review

Perform structured code reviews focusing on correctness, readability, security, and maintainability. Use this skill when reviewing pull requests, evaluating code changes, or establishing review standards for a team.From its SKILL.md

Install

npx -y skills add s-hiraoku/synapse-a2a --skill code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
10 stars10 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.8 KB, 602 tokens by cl100k_base, as published. Nobody here has run it

Code Review

Perform structured, actionable code reviews.

When to Use

Reviewing a pull request or set of changes
Evaluating code quality before merging
Auditing a module for technical debt
Establishing review standards or checklists

Review Dimensions

Review code across these dimensions, in priority order:

1. Correctness

Does the code do what it claims?
Are edge cases handled? (null, empty, overflow, concurrency)
Are error paths tested?
Do tests cover the changed behavior?

2. Security

Input validation at system boundaries
No secrets in code (API keys, passwords, tokens)
SQL/command injection prevention
Proper authentication and authorization checks
See security-audit skill for deeper analysis

3. Readability

Clear naming (variables, functions, classes)
Functions do one thing
No deep nesting (max 3 levels)
Comments explain "why", not "what"
Consistent style with the surrounding codebase

4. Maintainability

No unnecessary abstractions
DRY without over-abstraction (rule of three)
Dependencies are justified
Breaking changes are flagged

5. Performance

Only flag when there is a real concern (hot path, large data, N+1 queries)
Do not micro-optimize unless the context demands it

Review Output Format

Structure feedback as:

## Review: <PR title or file>

### Must Fix
- [ ] **file.py:42** — [Correctness] Description of the issue and suggested fix

### Should Fix
- [ ] **file.py:78** — [Readability] Description and suggestion

### Consider
- [ ] **file.py:100** — [Performance] Optional improvement

### Positive
- file.py:15 — Good use of context manager for resource cleanup

Severity levels:

Level	Meaning	Merge?
Must Fix	Bug, security issue, or broken contract	Block
Should Fix	Significant readability/maintainability concern	Request changes
Consider	Optional improvement, style preference	Approve with comment
Positive	Good patterns worth highlighting	-

Guidelines

Be specific - Point to exact lines, suggest concrete alternatives
Explain why - "This could cause X because Y", not just "change this"
Separate style from substance - Automate style (linters); review logic manually
Limit scope - Review what changed, not the entire file (unless asked)
Acknowledge good work - Include at least one positive observation
Propose, don't impose - "Consider using X" not "You must use X" (unless it's a Must Fix)

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most code review skills give in 602 tokens

Counted across 668 of the 814 authors here whose files we hold, read 2026-09-06

Provide technical reasoning when pushing backin 84 of 668, across 70 files
Fix critical issues immediatelyin 77 of 668, across 60 files
Dispatch a code reviewer subagentin 76 of 668, across 59 files
Fix important issues before proceedingin 73 of 668, across 56 files
Ask for clarification on unclear itemsin 68 of 668, across 56 files
Verify feedback against codebase before implementationin 66 of 668, across 55 files
Implement fixes one at a timein 64 of 668, across 53 files
Test each fix individuallyin 62 of 668, across 51 files
Restate technical requirements in own wordsin 57 of 668, across 46 files
Reply to inline comments in the specific threadin 51 of 668, across 40 files
Note minor issues for laterin 49 of 668, across 34 files
Group findings by severityin 48 of 668, across 47 files

Said here and by no other author read

Ensure code readability and naming
Assess maintainability and abstractions
Flag performance issues on hot paths
Explain the reasoning for feedback
Separate style from substance
Limit review scope to changes

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.