Review proposed abstractions, dependencies, and configuration for concrete consumers and maintenance cost when simplifying a design or checking overengineering.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Who's paying rent on this abstraction?
Start with supplied paths, contracts and instructions. Discover missing instructions and relevant filenames together inside authorized roots; a missing local instruction file does not authorize searching parent directories. If needed evidence lies outside scope, report the gap. Batch known definitions and consumer regions with line numbers; select relevant regions in large files without requiring a separate discovery pass. Retain enclosing logic and use full-file context when needed. Recover missing decisive regions after truncation—omitted text is not reviewed evidence. Search unresolved bindings, not another copy of already-read source. Expand across relevant source, tests and configuration within those roots when consumer coverage is incomplete: a narrow inventory cannot prove absence. Installed skills and copied examples need a supported usage/binding to count as consumers.
Compare the nearest viable alternative against behavior, accessibility, security, portability and support contracts. Stop surveying once decision-changing differences settle the choice.
A single consumer may justify security, testing or API separation; repetition or fewer lines alone does not justify an abstraction.
Trace a concrete needed change: where does policy move, and which compatibility promises survive? Removing a layer must not merely spread its complexity into callers. Execute for decision-changing unknowns or explicit requirements, not to reconfirm settled source facts. Static analysis cannot establish unresolved runtime behavior.
When executing, reuse a known lightweight relevant test group. Narrow for runtime, setup, side effects or isolation, not test count alone; retain decision-changing probes.
Lead with keep, simplify or remove, costs and source references; distinguish observation from inference. A clean review is valid. Stop at the supported recommendation and required checks. Review authorizes neither edits nor publication. Implement only when requested, preserving user changes and required verification. Humor is optional.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Audit whether tests detect broken behavior by tracing assertions and running narrow controlled mutations in an isolated workspace; use for test-quality reviews, not routine test execution.
The English summary is being prepared. Showing the original description.
Diagnose an uncertain bug by designing experiments that distinguish competing causes, especially speculative cache, timing, environment, or concurrency explanations.
The English summary is being prepared. Showing the original description.
Review a planned deployment or release diff for rollback feasibility, mixed-version compatibility, migrations, and configuration readiness without deploying it.
The English summary is being prepared. Showing the original description.
Keep a small requested change focused when optional refactors, architectural redesign, or unrelated cleanup threaten to expand its scope.
The English summary is being prepared. Showing the original description.
Test a changed user interaction for realistic sequence failures such as double submission, stale responses, navigation, and recovery; use for interaction QA rather than general code review.
The English summary is being prepared. Showing the original description.
Trace the purpose of suspicious legacy code using current callers, tests, and Git history when deciding whether it can be changed or removed.
The English summary is being prepared. Showing the original description.