Review proposed abstractions, dependencies, and configuration for concrete consumers and maintenance cost when simplifying a design or checking overengineering.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
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.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
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.
日本語の概要は準備中です。原文の説明を表示しています。
Diagnose an uncertain bug by designing experiments that distinguish competing causes, especially speculative cache, timing, environment, or concurrency explanations.
日本語の概要は準備中です。原文の説明を表示しています。
Review a planned deployment or release diff for rollback feasibility, mixed-version compatibility, migrations, and configuration readiness without deploying it.
日本語の概要は準備中です。原文の説明を表示しています。
Keep a small requested change focused when optional refactors, architectural redesign, or unrelated cleanup threaten to expand its scope.
日本語の概要は準備中です。原文の説明を表示しています。
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.
日本語の概要は準備中です。原文の説明を表示しています。
Trace the purpose of suspicious legacy code using current callers, tests, and Git history when deciding whether it can be changed or removed.
日本語の概要は準備中です。原文の説明を表示しています。