All skills
google-gemini avatar

/codeexplorer

@d9b600b
by google-geminigoogle-gemini/gemini-cli107k stars
14,665

Explores the repository to locate primary source files, coupled UI components, and test files for bug reports or feature requests.

  • 1 file
  • 2.6 KB
  • Updated 2 months ago
  • GitHub

Use this Skill: https://skilld.dev/gh/google-gemini/gemini-cli/codeexplorer

This session only. Nothing lands on disk.

SKILL.md

≈36 tokens always: the name and description. ≈618 when used: this file.

Code Explorer Instructions

Explore the repository to find verified, existing file paths and technical context related to the reported issue.

Phase 1: Root Exploration & Related Area Discovery

  1. Understand Overall Codebase Structure: Before focusing on a single file, gain a high-level understanding of the repository structure (e.g. packages/cli, packages/core). This ensures you remain aware that a complete fix may require coordinating changes across other sibling packages. Never restrict your initial search to a single subfolder, as essential related files frequently reside in outside parent or sibling packages.
  2. Formulate an Initial Hypothesis: Before jumping to drafting a plan, analyze the issue title and body to form a high-level hypothesis about the issue domain and identify candidate directories across the codebase.

Phase 2: Directed Code Exploration & Traversal

  1. Error Tracing: If the issue body contains a stack trace, log, or file reference, start at that exact file. For code files, follow imports down to original definitions; for failing workflow steps, target the failing workflow/action file directly.
  2. Cross-Package & Side-Effect Traversal: IMPORTANT: Trace data flow across package boundaries (packages/cli <-> packages/core) and shared utilities to capture all affected caller/consumer files.
  3. Architectural Grounding: Ignore user-suggested workarounds in the issue description. Always investigate the underlying source code to derive a clean fix.

Phase 3: Test Applicability & Pattern Check

  1. Search Existing Test Patterns: Use find_file or list_directory in the target directory to check if automated unit/integration test files (e.g. *.test.ts or *.test.tsx) exist in that module.
  2. Evaluate Test Applicability / N/A: If an automated test does not logically apply or is not customary for the change (such as CI workflow YAML files or documentation updates), set test_file to "N/A" and provide manual or workflow verification steps.

Finally, review your suggested target files to ensure it is a minimal fix that does not touch unnecessary files.

Output Format:

Output a concise summary of the discovered file paths and technical context:

{
  "primary_source_files": ["path/to/source.ts"],
  "related_files": [],
  "test_file": "path/to/test.test.ts" | "N/A",
  "exploration_notes": "Brief explanation of discovered files and technical context."
}

Source: SKILL.md on GitHub

No third-party reports yet.

Signed by skilld at d9b600b. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub yesterday.

Activeupdated 2 months ago

README badge

README badge for google-gemini/gemini-cli/codeexplorer