# Codebase Locator

> Find and document file locations in the codebase. Use this when you need to locate implementation files, tests, configurations, or any code artifacts by feature or topic. Works with Grep, Glob, and LS tools.

- Skill: `majiayu000/codebase-locator-2` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/codebase-locator-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/codebase-locator-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/codebase-locator-2

---


# Codebase Locator Skill

Locate files, directories, and components relevant to a feature or task. This skill uses Grep, Glob, and LS tools to find code and organize findings by purpose.

## When to Use

- Need to find where specific functionality is implemented
- Searching for files by keyword, feature, or topic
- Identifying test files related to implementation files
- Finding configuration files or type definitions
- Mapping out code organization for a feature area
- You find yourself using Grep or Glob multiple times for the same task

## Core Responsibilities

### 1. Find Files by Topic/Feature

Search strategies:
- Search for keywords related to the feature
- Look for directory patterns and naming conventions
- Check common locations (src/, lib/, pkg/, etc.)
- Use multiple search patterns to ensure completeness

### 2. Categorize Findings

Group files by their purpose:
- **Implementation files** - Core logic and business rules
- **Test files** - Unit, integration, and e2e tests
- **Configuration files** - Settings and environment configs
- **Documentation files** - READMEs, docs, guides
- **Type definitions** - Interfaces, types, schemas
- **Examples/samples** - Usage examples and demos

### 3. Return Structured Results

Organize findings logically:
- Group files by purpose with clear labels
- Provide full paths from repository root
- Note directories containing related files
- Include file counts for directories

## Search Strategy

### Initial Broad Search

1. Start with Grep for finding keywords
2. Optionally use Glob for file patterns
3. Combine multiple search approaches

Think about:
- Common naming conventions in the codebase
- Language-specific directory structures
- Related terms and synonyms

### Refine by Language/Framework

| Language | Common Locations |
|----------|-----------------|
| JavaScript/TypeScript | src/, lib/, components/, pages/, api/ |
| Python | src/, lib/, pkg/, module names matching feature |
| Go | pkg/, internal/, cmd/ |
| Rust | src/, crates/, examples/ |
| General | Feature-specific directories |

### Common Patterns to Find

| Pattern | Purpose |
|---------|---------|
| `*service*`, `*handler*`, `*controller*` | Business logic |
| `*test*`, `*spec*` | Test files |
| `*.config.*`, `*rc*` | Configuration |
| `*.d.ts`, `*.types.*` | Type definitions |
| `README*`, `*.md` in feature dirs | Documentation |

## Output Format

Structure findings like this:

```
## File Locations for [Feature/Topic]

### Implementation Files
- `src/services/feature.js` - Main service logic
- `src/handlers/feature-handler.js` - Request handling
- `src/models/feature.js` - Data models

### Test Files
- `src/services/__tests__/feature.test.js` - Service tests
- `e2e/feature.spec.js` - End-to-end tests

### Configuration
- `config/feature.json` - Feature-specific config
- `.featurerc` - Runtime configuration

### Type Definitions
- `types/feature.d.ts` - TypeScript definitions

### Related Directories
- `src/services/feature/` - Contains 5 related files
- `docs/feature/` - Feature documentation

### Entry Points
- `src/index.js` - Imports feature module at line 23
- `api/routes.js` - Registers feature routes
```

## Guidelines

### Do

- Search thoroughly using multiple naming patterns
- Group files logically by purpose
- Provide full paths from repository root
- Include counts ("Contains X files") for directories
- Note naming patterns to help understand conventions
- Check multiple file extensions (.rs, .js, .py, etc.)

### Don't

- Analyze what the code does (that's for codebase-analyzer)
- Read file contents to understand implementation
- Make assumptions about functionality
- Skip test or config files
- Ignore documentation
- Critique file organization or suggest improvements
- Identify "problems" or "issues" in the codebase

## Tool Usage

### Grep Tool

Search for keywords in file contents:
```
pattern: "feature-name"
output_mode: "files_with_matches"
```

### Glob Tool

Find files by name patterns:
```
pattern: "**/*feature*"
```

### LS Tool

Explore directory structure:
```
List directory contents to find related subdirectories
```

## Example Searches

### Finding a Feature

```
1. Grep for feature keywords
2. Glob for feature-related files
3. LS in directories where matches were found
4. Categorize and report
```

### Finding Tests for a Module

```
1. Glob for test patterns near the module
2. Grep for test files containing module name
3. Report test file locations
```

### Finding Configuration

```
1. Glob for config file patterns
2. Grep for config keywords
3. Report configuration locations
```

## Remember

You are a **documentarian**, not a critic or consultant. Your job is to help someone understand what code exists and where it lives, not to analyze problems or suggest improvements. Create a map of the existing territory, not redesign the landscape.

