Gemini

Chapter 17 of 24

Code Explorer

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

1 minute · 316 words · 5 sections

Code Explorer Instructions

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

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.
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

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.
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.
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

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.
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."
}

Install this repository

$ npx skills add google-gemini/gemini-cli

Skills install per repository, not per chapter — the CLI has no documented per-skill form, so we do not print one.

Colophon for this issue

Colophon

How this issue was made

Source

github.com/google-gemini/gemini-cli, branch main, last pushed 10 August 2026.

Licence

Apache-2.0 — the text of every chapter is reproduced unmodified, frontmatter included, under the upstream licence.

Discovery

24 chapters found by walking the repository tree for SKILL.md, not by matching a directory convention. 5 distinct layouts observed: .gemini/skills/*/SKILL.md, packages/core/src/skills/builtin/*/SKILL.md, packages/sdk/test-data/skills/*/SKILL.md, tools/caretaker-agent/cloudrun/triage-worker/.gemini/skills/*/SKILL.md, tools/gemini-cli-bot/.gemini/skills/*/SKILL.md.

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

2 repairs applied to this chapter so the document has one h1 and no skipped levels:

Shifted “5 headings” from h1 to h2 so the chapter title is the only h1.
Repaired “Phase 1: Root Exploration & Related Area Discovery” from h4 to h3, closing a skipped level.

Spec compliance

2 editorial notes across 2 of 24 chapters. They are printed in the margin of each chapter rather than as errors here.

Code Explorer — 1 note
Spec Generator — 1 note

Images

Images inside a chapter 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 chapter 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.

Code Explorer Instructions

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

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.

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.

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.

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.

Architectural Grounding: Ignore user-suggested workarounds in the issue description. Always investigate the underlying source code to derive a clean fix.

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.

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 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."
}