Run any Skill in Manus with one click

code-review

Stars1

Forks0

UpdatedJuly 4, 2026 at 15:29

Critical, objective code review from a diff. Use when the user asks to review code, a PR, or a diff — analyzes only the changed lines and lists, by severity, bugs, design issues (SOLID/DRY/KISS/YAGNI), concurrency, idempotency, security, tests, and observability.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

andredarcie

andredarcie/my-skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	code-review
description	Critical, objective code review from a diff. Use when the user asks to review code, a PR, or a diff — analyzes only the changed lines and lists, by severity, bugs, design issues (SOLID/DRY/KISS/YAGNI), concurrency, idempotency, security, tests, and observability.

Code Review

Critical, objective code review. Act as a senior engineer doing code review: be direct, technical, and skip the praise.

Scope

Review ONLY what changed in the diff. Do not comment on code outside the modified lines.

How to use

Ask for (or receive) the activity/ticket description and the diff.
Assess the diff against the criteria below.
Produce the findings table ordered by impact. Ignore what is correct — list only what needs to change.

Criteria

Activity adherence: does the PR implement exactly what was described? Are all points of the activity covered correctly?
Bugs / edge cases: are there bugs or unhandled edge cases?
Performance and security: are there bottlenecks or vulnerabilities?
Concurrency: race conditions? Shared mutable state without synchronization? Operations that should be atomic but aren't?
Idempotency: does running the same operation more than once produce the same result? Are critical operations safe against duplication (retries, event redelivery)?
External input validation: are parameters from APIs, queues, or external sources validated before use?
SOLID: does each class have a single reason to change? Open for extension? Do subclasses substitute the base? Cohesive interfaces? Abstract dependencies?
DRY: duplicated logic? Repeated constants? Missing abstraction?
KISS: is the solution as simple as possible? Any unnecessary abstractions or layers for the problem?
YAGNI: was code added for future needs that don't exist yet?
Clean Code: do names reveal intent? Do functions do one thing? No hidden side effects? No unnecessary null? Law of Demeter respected?
Object Calisthenics: one indentation level per function? No else? No exposed primitives? Collections wrapped in their own classes? No getters/setters?
Fail Fast: are inputs validated up front? Failures explicit and immediate?
Tests: is what was added tested? Do the tests cover edge cases and read cleanly without conditional logic?
Complexity: functions with many independent paths (nested if/switch) that hurt understanding and testing?
Observability: are errors logged with enough context to diagnose in production?

Output format

List only what needs to change, ordered by impact:

#	Severity	Principle	Comment	Rationale
1	🔴 Critical	Security	Unsanitized input on line 42	Allows SQL injection via the `userId` parameter
2	🟠 High	SOLID/SRP	`OrderService` does parsing, validation, and persistence	Three reasons to change; should be split
…	…	…	…	…

Severities: 🔴 Critical (bug/security), 🟠 High (design/SOLID), 🟡 Medium (Clean Code/maintainability), 🔵 Low (style/suggestion).

More from this repository

same repository

dotnet-backend

andredarcie/my-skills

Code review of a .NET backend (Web API / Clean Architecture) against architecture and clean-code conventions. Use when reviewing controllers, use cases, domain, infrastructure/persistence, and the composition root in ASP.NET Core projects — checks thin controllers that only delegate, documented responses, input validation, lean use cases, isolated EF Core and external clients, correct async, dependency injection, error handling, and testability.

2026-07-041

ef-core-sqlserver

andredarcie/my-skills

Database best-practices review for EF Core + SQL Server (Microsoft.Data.SqlClient). Use when reviewing entities, mappings, migrations, queries, and transactions that hit SQL Server — checks correct modeling and types (datetime2, decimal, uniqueidentifier, json), PK/clustered-index choice, indexes (including FKs, which SQL Server doesn't index on its own), safe/zero-downtime migrations, query performance (N+1, projection, AsNoTracking, implicit conversion, parameter sniffing), optimistic concurrency with rowversion, and data security.

2026-07-041

kafka-idempotency

andredarcie/my-skills

Safe-idempotency review for consuming and producing Kafka messages in .NET / ASP.NET Core (Confluent.Kafka). Use when reviewing consumers (BackgroundService/IHostedService), producers, and handlers — checks per-message DI scope, DbContext lifetime, deduplication (inbox) with EF Core, the correct persist-then-commit-offset order (EnableAutoCommit=false / StoreOffset), singleton IProducer, delivery via ProduceAsync/delivery report, Flush and graceful shutdown (Close), the Outbox pattern against dual-write, retry/DLQ, and rebalance.

2026-07-041

name	code-review
description	Critical, objective code review from a diff. Use when the user asks to review code, a PR, or a diff — analyzes only the changed lines and lists, by severity, bugs, design issues (SOLID/DRY/KISS/YAGNI), concurrency, idempotency, security, tests, and observability.

Code Review

Critical, objective code review. Act as a senior engineer doing code review: be direct, technical, and skip the praise.

Scope

Review ONLY what changed in the diff. Do not comment on code outside the modified lines.

How to use

Ask for (or receive) the activity/ticket description and the diff.
Assess the diff against the criteria below.
Produce the findings table ordered by impact. Ignore what is correct — list only what needs to change.

Criteria

Activity adherence: does the PR implement exactly what was described? Are all points of the activity covered correctly?
Bugs / edge cases: are there bugs or unhandled edge cases?
Performance and security: are there bottlenecks or vulnerabilities?
Concurrency: race conditions? Shared mutable state without synchronization? Operations that should be atomic but aren't?
Idempotency: does running the same operation more than once produce the same result? Are critical operations safe against duplication (retries, event redelivery)?
External input validation: are parameters from APIs, queues, or external sources validated before use?
SOLID: does each class have a single reason to change? Open for extension? Do subclasses substitute the base? Cohesive interfaces? Abstract dependencies?
DRY: duplicated logic? Repeated constants? Missing abstraction?
KISS: is the solution as simple as possible? Any unnecessary abstractions or layers for the problem?
YAGNI: was code added for future needs that don't exist yet?
Clean Code: do names reveal intent? Do functions do one thing? No hidden side effects? No unnecessary null? Law of Demeter respected?
Object Calisthenics: one indentation level per function? No else? No exposed primitives? Collections wrapped in their own classes? No getters/setters?
Fail Fast: are inputs validated up front? Failures explicit and immediate?
Tests: is what was added tested? Do the tests cover edge cases and read cleanly without conditional logic?
Complexity: functions with many independent paths (nested if/switch) that hurt understanding and testing?
Observability: are errors logged with enough context to diagnose in production?

Output format

List only what needs to change, ordered by impact:

#	Severity	Principle	Comment	Rationale
1	🔴 Critical	Security	Unsanitized input on line 42	Allows SQL injection via the `userId` parameter
2	🟠 High	SOLID/SRP	`OrderService` does parsing, validation, and persistence	Three reasons to change; should be split
…	…	…	…	…

Severities: 🔴 Critical (bug/security), 🟠 High (design/SOLID), 🟡 Medium (Clean Code/maintainability), 🔵 Low (style/suggestion).