Use when reviewing code for algorithmic complexity — nested loops, repeated scans, wrong data structure, brute force where a known algorithm (hashing, sorting, binary search, prefix sums, heaps, graph traversal) would change the Big-O. Proposes behavior-preserving rewrites verified against the original. Not for…
Use when designing a new HTTP/REST API or reviewing an API contract (OpenAPI spec, route list, endpoint handlers) — resources and URLs, status codes, error format, pagination, idempotency, concurrency control, auth, rate limiting, versioning and deprecation, and outbound webhooks. Not for overall system or service…
Use when designing a new system or service, choosing between architectural options (monolith vs. service, sync vs. async, which broker/store), reviewing the architecture of a design doc, or planning how a system handles growth, failure, consistency, security and migration. Produces a numbers-driven design: options…
Use when turning commits, merged PRs, or a git range into CHANGELOG.md entries or release notes — classifies changes with Keep a Changelog categories, flags breaking changes and SemVer mismatches, and produces a developer changelog plus user-facing release notes without inventing facts. Not for writing guides…
Use when reviewing code in any language — a snippet, function, file, module, or diff — for bugs, correctness, edge cases, security and performance red flags, maintainability, and tests, including when the user pastes code and asks "any issues?", "is this OK?", "review this code". Single pass: severity-tagged findings…
Use when designing or reviewing a relational database schema — modeling entities, choosing types, keys and constraints, enforcing multi-tenant isolation, deriving indexes from known queries, or defining the target schema of a change. PostgreSQL by default. Not for executing or reviewing a migration rollout (locks…
Use when a failure is already observable or reproducible (failing test, erroring command, triggerable wrong output, flaky failure you can loop) and you need the proven root cause — rank hypotheses, eliminate them with one-variable experiments, fix only what the evidence confirms. Triggers: "debug this", "find the root…
Use when writing or updating technical documentation from code, specs, or notes — README/setup guides, tutorials, how-to guides, runbooks, API references, ADRs, usage instructions — or when syncing existing docs after a code change. Triggers include "write docs", "document this API", "write a README", "write an ADR"…
Use when restructuring, cleaning up, or simplifying existing C#, .NET, or ASP.NET Core code with identical behavior — including after a dotnet-code-review when the user says "apply the fixes". One smell at a time, SAFE/RISKY/DANGEROUS risk, characterization tests first, and .NET traps (LINQ deferred execution, async…
Use when reviewing C#, .NET, or ASP.NET Core code — a class, file, diff, or module — or when the user pastes C# and asks for feedback, issues, or improvements without saying "review". Checks .NET slop (skipped tests, #pragma/NoWarn, ! abuse, swallowed exceptions) and async, DI, EF Core, disposal, ASP.NET Core…
Use when the user reports a bug with little context — the entry point for bug reports such as an error message, a stack trace, "it's not working", "fix this", "why is this failing", "sửa lỗi này", "fix lỗi", "tại sao bị lỗi", "only one user has this", "restart fixed it", "chỉ máy tôi bị". Checks where the cause lives…
Use when writing or modifying code in any language — a silent baseline of senior engineering defaults (errors, bounded queries, idempotency, concurrency, security, testability). When a task-specific skill applies it leads and this only fills gaps: refactor/dotnet-code-refactor, fix-bug/debug, test-writer, ui-design…
Use when planning or reviewing a schema or data migration that runs against a live database — DDL lock impact, locktimeout/statementtimeout, table rewrites, NOT VALID + VALIDATE constraints, concurrent index builds, batched backfills, expand–contract while old and new code run side by side, per-step rollback…
Use when an endpoint, query, job, page, or service is slow and you need the bottleneck found from measurements (percentiles, traces, profiles, EXPLAIN ANALYZE), fixes ranked by gain, cost, and rollout risk, and a re-measurement plan; also to review a load test. Triggers: "why is this slow", "p99", "review hiệu năng"…
Use when deciding if a change set (PR URL, branch vs base, or pasted diff) is ready to merge — "review this PR", "is this ready to merge". Judges the change as a unit: scope, size, hidden changes, blast radius, tests, rollout/rollback, description, plus blocking defects in changed lines; ends in REQUEST CHANGES /…
Use when the user asks to refactor, clean up, simplify, restructure, or untangle existing code, or the code has deep nesting, duplication, god functions, premature abstractions, or scattered logic — and the goal is the same behavior with a clearer structure. Works in any language; modifies code in small verified steps…
Use when reviewing code, a diff, or a service specifically for security weaknesses — injection, authn/authz and object-level access (IDOR), SSRF, CSRF, XSS, deserialization, mass assignment, path traversal, XXE, file upload, open redirect, race conditions and business logic, tenant isolation, prompt injection…
Use when responding to a live production incident or on-call page, defining or reviewing SLIs, SLOs, error budgets and burn-rate alerts, fixing noisy or missing alerts, or writing a blameless post-mortem. Triggers include "prod is down", "we got paged", "SLO", "error budget", "alert fatigue", "post-mortem", "sự cố…
Use when designing or writing tests for a function, module, API, or bug fix — test plans, unit/integration test cases, edge cases, regression tests for a fixed bug, or characterization tests before a refactor. Derives expected values from the spec, runs the tests, and reports bugs or dead code found along the way.…
Use when building or restyling UI (pages, components, themes, landing pages) in any framework — applies the project's design system first, otherwise bundled contrast-checked light/dark palettes, type and spacing scales, interaction states, dark mode without flash, Core Web Vitals and SEO basics. Not for reviewing…
Use when the user wants a strict, high-standard review of a written document — PRD, design doc, RFC, runbook, guideline, process, onboarding doc, README, or any prose — for structure, clarity, consistency, accuracy against the repo, and whether a reader can act on it. Triggers: "review this document", "strict review"…
Use when the user wants a full, deep, or scored audit of a file, module, service, or whole codebase across many quality dimensions — a 0–10 scorecard over architecture, clean code, SOLID, patterns, performance, security, naming, structure, DI, async, error handling, logging, validation, testability, maintainability…
Use when deciding whether a release or deploy is safe to ship — go/no-go calls, release checklists, rollout/canary and rollback plans, release-window timing (freezes, peak events), rollback triggers, and stakeholder communication. Produces a GO / GO WITH CONDITIONS / NO-GO verdict. Not for designing or reviewing the…
Use when writing, scaffolding, or extending C# / .NET / ASP.NET Core backend code — new APIs, services, workers, solutions, csproj/Directory.Build.props/.editorconfig setup — or when the user asks for production-grade, "chuẩn", large-project-quality .NET code. Not for reviewing existing C# (use dotnet-code-review)…
★not rated 2 5d agoA119 tokens
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: