一键在 Manus 中运行任何 Skill

code-review

星标1

分支0

更新时间2026年7月4日 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.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

andredarcie

andredarcie/my-skills

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

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).

同仓库更多 Skills

同仓库

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).