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.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.