Credited skills

Skill 20 of 23

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

Credited

This skill is installed in google-gemini/gemini-cli — in use here rather than published from here — so there is no install command for it on this page.

Colophon for this issue

Colophon

How this issue was made

Source

github.com/google-gemini/gemini-cli, branch main, last pushed 8 November 2026.

Licence

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

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

Shifted “5 headings” from h1 to h2 so the skill 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 23 skills. They are printed in the margin of each skill rather than as errors here.

Code Explorer — 1 note
Spec Generator — 1 note

Images

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.

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