Use this skill during code reviews to proactively investigate the codebase for duplicated functionality, reinvented wheels, or failure to reuse existing project best practices and…
This skill provides a structured workflow for investigating a codebase during a code review to identify duplicated logic, reinvented utilities, and missed opportunities to reuse established patterns. By executing this workflow, you ensure that new code integrates seamlessly with the existing project architecture.
Analyze the new code to identify the core algorithms, utility functions, generic data structures, or UI components being introduced. Look beyond the specific business logic to see the underlying mechanics.
Core Logic: Call out packages/core/ if functionality does not appear React UI specific.
Trace Third-Party Dependencies: If the PR introduces a new import for a utility library (e.g., lodash.merge, date-fns), trace how and where the project currently uses that library. There is likely an existing wrapper or shared utility.
Check Package Files: Before flagging a custom implementation of a complex algorithm, check package.json to see if a standard library (like lodash or uuid) is already installed that provides this functionality.
Delegate the heavy lifting of codebase investigation to specialized sub-agents. They are optimized to perform deep searches and semantic mapping without bloating your session history.
To ensure a comprehensive review, you MUST formulate highly specific objectives for the sub-agents, providing them with the “scents” you discovered in Step 1.
Codebase Investigator: Use the codebase_investigator as your primary researcher. When delegating, formulate an objective that asks specific, investigative questions about the codebase, explicitly including these search vectors:
Structural Similarity: Ask if existing code uses the same underlying APIs (e.g., “Does any existing code use Intl.DateTimeFormat or setTimeout for similar purposes?”).
Naming Conventions: Ask if there are existing symbols with similar naming patterns (e.g., “Are there existing symbols with naming patterns like *Format* or *Debounce*?”).
Comments & Documentation: Ask if keywords from the PR’s comments or JSDoc exist in describing similar behavior elsewhere.
Architectural Fit: Ask where this type of logic is currently centralized (e.g., “Where is centralized date formatting logic located?”).
Refactoring Guidance: Crucially, ask the sub-agent to explain how the new code could be refactored to use any existing logic it finds.
Generalist Agent: Use the generalist for detailed, turn-intensive comparisons. For example: “Review the implementation of MyNewComponent in the PR and compare it semantically against all components in packages/ui/src. Are there any existing components that could be extended or used instead?”
Retain Fast Path for Simple Searches: For extremely simple, unambiguous checks (e.g., “Does package.json include lodash?”), perform a direct search to save time. Default to delegation for any open-ended “investigations.”
Check if the new code aligns with the project’s established conventions.
Error Handling: Does it use the project’s standard error classes or logging mechanisms?
State Management: Does it bypass established stores or contexts?
Styling: Does it hardcode colors or spacing instead of using theme variables?
If the PR introduces a new pattern, compare it against the documented standards and explicitly confirm if an existing project pattern should have been used instead.
If you discover that the PR duplicates existing functionality or ignores a best practice:
Provide a clear review comment.
Identify the Source: Explicitly mention the absolute or project-relative file path and the specific symbol (function, component, class) that should be reused.
Implementation Guidance: Provide a brief code snippet or a clear explanation showing how to integrate the existing code to fulfill the task’s requirements.
Explain the Value: Briefly explain why reusing the existing code is beneficial (e.g., maintainability, consistency, built-in edge case handling).
Example comment:
“It looks like this PR introduces a new formatDate utility. We already have a robust, tested formatDate function in src/utils/dateHelpers.ts.
You can replace your implementation by importing it like this:
typescript
import { formatDate } from '../utils/dateHelpers';// Then use it here:const displayDate = formatDate(userDate, 'MMM Do, YYYY');
Reusing this ensures that the date formatting remains consistent with the rest of the application and handles timezone conversions correctly.”
About this skill
Trigger
Use this skill during code reviews to proactively investigate the codebase for duplicated functionality, reinvented wheels, or failure to reuse existing project best practices and shared utilities.
The verbatim description from this skill’s front matter — the string an agent matches on to decide whether to load it.
Apache-2.0 — the text of every skill is reproduced unmodified, frontmatter included, under the upstream licence.
Discovery
23 skills found by walking the repository tree for SKILL.md, not by matching a directory convention. 4 distinct layouts observed: .gemini/skills/*/SKILL.md, packages/core/src/skills/builtin/*/SKILL.md, tools/caretaker-agent/cloudrun/triage-worker/.gemini/skills/*/SKILL.md, tools/gemini-cli-bot/.gemini/skills/*/SKILL.md.
Authorship
4 of 23 skills are installed into the repository rather than published from it. They are shelved in the closing “Credited skills” part and remain the work of their own authors. A skill counts as credited when its only copy lives under one agent’s dot directory; visible directories, per-agent mirror sets, and skills installable from this repository on skills.sh all count as published.
Issue colours
Resolved from a curated brand profile — hue 288°, chroma 0.190. Two accent tones are generated per issue and each is proven against its own ground before it ships: a single accent that passes AA on both light and dark paper is arithmetically impossible.
Heading repairs
1 repair applied to this skill so the document has one h1 and no skipped levels:
Removed “Review Duplication”, a leading h1 that duplicated the skill title.
Spec compliance
2 editorial notes across 2 of 23 skills. They are printed in the margin of each skill rather than as errors here.
Images inside a skill come from the upstream repository. Where the author gave no alternative text we mark the image decorative rather than inventing a description — a plausible caption we made up is worse than none for the reader who depends on it.
Signal
Install counts come from skills.sh. They measure downloads, not quality, and an unranked repository is not an unread one.
Agent surfaces
The whole issue is available as one markdown document at /google-gemini/gemini-cli.md, and each skill at its own .md URL.
Publication
Set by Skills Docs from the source repository. Body text is Literata at the reader’s chosen size and measure; code is Geist Mono. Nothing on this page was written by us except this paragraph.