Claude-skill-registry gsd-codebase-mapper

Explores codebase and writes structured analysis documents. Spawned by map-codebase with a focus area.

install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/codebase-mapper" ~/.claude/skills/majiayu000-claude-skill-registry-gsd-codebase-mapper && rm -rf "$T"
manifest: skills/data/codebase-mapper/SKILL.md
source content

GSD Codebase Mapper

Explores a codebase for a specific focus area and writes analysis documents directly to

.planning/codebase/
.

When to Use

Use this agent when:

  • You need to understand an existing codebase structure
  • Starting work on a brownfield project (existing code)
  • Need to document technology stack, architecture, or patterns
  • Want to identify technical debt and concerns
  • Preparing for a new phase that requires codebase context

Focus Areas

The mapper is spawned with one of four focus areas:

  • tech - Analyze technology stack and external integrations → writes STACK.md and INTEGRATIONS.md
  • arch - Analyze architecture and file structure → writes ARCHITECTURE.md and STRUCTURE.md
  • quality - Analyze coding conventions and testing patterns → writes CONVENTIONS.md and TESTING.md
  • concerns - Identify technical debt and issues → writes CONCERNS.md

Core Responsibilities

  1. Explore thoroughly - Read relevant files, understand patterns, identify key components
  2. Write directly - Create documents in
    .planning/codebase/
    to reduce orchestrator context load
  3. Be prescriptive - Document HOW things are done, not just WHAT exists
  4. Include file paths - Every finding should have a file path in backticks for navigation
  5. Return confirmation only - Don't return document contents, just confirm what was written

Why This Matters

These documents are consumed by other GSD commands:

/gsd:plan-phase
loads relevant codebase docs when creating implementation plans:

Phase TypeDocuments Loaded
UI, frontend, componentsCONVENTIONS.md, STRUCTURE.md
API, backend, endpointsARCHITECTURE.md, CONVENTIONS.md
database, schema, modelsARCHITECTURE.md, STACK.md
testing, testsTESTING.md, CONVENTIONS.md
integration, external APIINTEGRATIONS.md, STACK.md
refactor, cleanupCONCERNS.md, ARCHITECTURE.md
setup, configSTACK.md, STRUCTURE.md

/gsd:execute-phase
references codebase docs to:

  • Follow existing conventions when writing code
  • Know where to place new files (STRUCTURE.md)
  • Match testing patterns (TESTING.md)
  • Avoid introducing more technical debt (CONCERNS.md)

Process

Step 1: Parse Focus Area

Read the focus area from your prompt. It will be one of:

tech
,
arch
,
quality
,
concerns
.

Step 2: Determine Output Documents

Based on focus, determine which documents to write:

  • tech
    → STACK.md, INTEGRATIONS.md
  • arch
    → ARCHITECTURE.md, STRUCTURE.md
  • quality
    → CONVENTIONS.md, TESTING.md
  • concerns
    → CONCERNS.md

Step 3: Explore Codebase

Use appropriate exploration commands for your focus area:

For tech focus:

# Package manifests
ls package.json requirements.txt Cargo.toml go.mod pyproject.toml 2>/dev/null
cat package.json 2>/dev/null | head -100

# Config files
ls -la *.config.* .env* tsconfig.json .nvmrc .python-version 2>/dev/null

# Find SDK/API imports
grep -r "import.*stripe\|import.*supabase\|import.*aws\|import.*@" src/ --include="*.ts" --include="*.tsx" 2>/dev/null | head -50

For arch focus:

# Directory structure
find . -type d -not -path '*/node_modules/*' -not -path '*/.git/*' | head -50

# Entry points
ls src/index.* src/main.* src/app.* src/server.* app/page.* 2>/dev/null

# Import patterns to understand layers
grep -r "^import" src/ --include="*.ts" --include="*.tsx" 2>/dev/null | head -100

For quality focus:

# Linting/formatting config
ls .eslintrc* .prettierrc* eslint.config.* biome.json 2>/dev/null
cat .prettierrc 2>/dev/null

# Test files and config
ls jest.config.* vitest.config.* 2>/dev/null
find . -name "*.test.*" -o -name "*.spec.*" | head -30

# Sample source files for convention analysis
ls src/**/*.ts 2>/dev/null | head -10

For concerns focus:

# TODO/FIXME comments
grep -rn "TODO\|FIXME\|HACK\|XXX" src/ --include="*.ts" --include="*.tsx" 2>/dev/null | head -50

# Large files (potential complexity)
find src/ -name "*.ts" -o -name "*.tsx" | xargs wc -l 2>/dev/null | sort -rn | head -20

# Empty returns/stubs
grep -rn "return null\|return \[\]\|return {}" src/ --include="*.ts" --include="*.tsx" 2>/dev/null | head -30

Step 4: Write Documents

Write documents to

.planning/codebase/
using the templates. Use the Write tool.

Document naming: UPPERCASE.md (e.g., STACK.md, ARCHITECTURE.md)

Template filling:

  1. Replace
    [YYYY-MM-DD]
    with current date
  2. Replace
    [Placeholder text]
    with findings from exploration
  3. If something is not found, use "Not detected" or "Not applicable"
  4. Always include file paths with backticks

Step 5: Return Confirmation

Return a brief confirmation. DO NOT include document contents.

Format:

## Mapping Complete

**Focus:** {focus}
**Documents written:**
- `.planning/codebase/{DOC1}.md` ({N} lines)
- `.planning/codebase/{DOC2}.md` ({N} lines)

Ready for orchestrator summary.

Document Templates

STACK.md Template

# Technology Stack

**Analysis Date:** [YYYY-MM-DD]

## Languages

**Primary:**
- [Language] [Version] - [Where used]

**Secondary:**
- [Language] [Version] - [Where used]

## Runtime

**Environment:**
- [Runtime] [Version]

**Package Manager:**
- [Manager] [Version]
- Lockfile: [present/missing]

## Frameworks

**Core:**
- [Framework] [Version] - [Purpose]

**Testing:**
- [Framework] [Version] - [Purpose]

**Build/Dev:**
- [Tool] [Version] - [Purpose]

## Key Dependencies

**Critical:**
- [Package] [Version] - [Why it matters]

**Infrastructure:**
- [Package] [Version] - [Purpose]

## Configuration

**Environment:**
- [How configured]
- [Key configs required]

**Build:**
- [Build config files]

## Platform Requirements

**Development:**
- [Requirements]

**Production:**
- [Deployment target]

---

*Stack analysis: [date]*

ARCHITECTURE.md Template

# Architecture

**Analysis Date:** [YYYY-MM-DD]

## Pattern Overview

**Overall:** [Pattern name]

**Key Characteristics:**
- [Characteristic 1]
- [Characteristic 2]
- [Characteristic 3]

## Layers

**[Layer Name]:**
- Purpose: [What this layer does]
- Location: `[path]`
- Contains: [Types of code]
- Depends on: [What it uses]
- Used by: [What uses it]

## Data Flow

**[Flow Name]:**

1. [Step 1]
2. [Step 2]
3. [Step 3]

**State Management:**
- [How state is handled]

## Key Abstractions

**[Abstraction Name]:**
- Purpose: [What it represents]
- Examples: `[file paths]`
- Pattern: [Pattern used]

## Entry Points

**[Entry Point]:**
- Location: `[path]`
- Triggers: [What invokes it]
- Responsibilities: [What it does]

## Error Handling

**Strategy:** [Approach]

**Patterns:**
- [Pattern 1]
- [Pattern 2]

## Cross-Cutting Concerns

**Logging:** [Approach]
**Validation:** [Approach]
**Authentication:** [Approach]

---

*Architecture analysis: [date]*

STRUCTURE.md Template

# Codebase Structure

**Analysis Date:** [YYYY-MM-DD]

## Directory Layout

[project-root]/ ├── [dir]/ # [Purpose] ├── [dir]/ # [Purpose] └── [file] # [Purpose]


## Directory Purposes

**[Directory Name]:**
- Purpose: [What lives here]
- Contains: [Types of files]
- Key files: `[important files]`

## Key File Locations

**Entry Points:**
- `[path]`: [Purpose]

**Configuration:**
- `[path]`: [Purpose]

**Core Logic:**
- `[path]`: [Purpose]

**Testing:**
- `[path]`: [Purpose]

## Naming Conventions

**Files:**
- [Pattern]: [Example]

**Directories:**
- [Pattern]: [Example]

## Where to Add New Code

**New Feature:**
- Primary code: `[path]`
- Tests: `[path]`

**New Component/Module:**
- Implementation: `[path]`

**Utilities:**
- Shared helpers: `[path]`

## Special Directories

**[Directory]:**
- Purpose: [What it contains]
- Generated: [Yes/No]
- Committed: [Yes/No]

---

*Structure analysis: [date]*

CONVENTIONS.md Template

# Coding Conventions

**Analysis Date:** [YYYY-MM-DD]

## Naming Patterns

**Files:**
- [Pattern observed]

**Functions:**
- [Pattern observed]

**Variables:**
- [Pattern observed]

**Types:**
- [Pattern observed]

## Code Style

**Formatting:**
- [Tool used]
- [Key settings]

**Linting:**
- [Tool used]
- [Key rules]

## Import Organization

**Order:**
1. [First group]
2. [Second group]
3. [Third group]

**Path Aliases:**
- [Aliases used]

## Error Handling

**Patterns:**
- [How errors are handled]

## Logging

**Framework:** [Tool or "console"]

**Patterns:**
- [When/how to log]

## Comments

**When to Comment:**
- [Guidelines observed]

**JSDoc/TSDoc:**
- [Usage pattern]

## Function Design

**Size:** [Guidelines]

**Parameters:** [Pattern]

**Return Values:** [Pattern]

## Module Design

**Exports:** [Pattern]

**Barrel Files:** [Usage]

---

*Convention analysis: [date]*

TESTING.md Template

# Testing Patterns

**Analysis Date:** [YYYY-MM-DD]

## Test Framework

**Runner:**
- [Framework] [Version]
- Config: `[config file]`

**Assertion Library:**
- [Library]

**Run Commands:**
```bash
[command]              # Run all tests
[command]              # Watch mode
[command]              # Coverage

Test File Organization

Location:

  • [Pattern: co-located or separate]

Naming:

  • [Pattern]

Structure:

[Directory pattern]

Test Structure

Suite Organization:

[Show actual pattern from codebase]

Patterns:

  • [Setup pattern]
  • [Teardown pattern]
  • [Assertion pattern]

Mocking

Framework: [Tool]

Patterns:

[Show actual mocking pattern from codebase]

What to Mock:

  • [Guidelines]

What NOT to Mock:

  • [Guidelines]

Fixtures and Factories

Test Data:

[Show pattern from codebase]

Location:

  • [Where fixtures live]

Coverage

Requirements: [Target or "None enforced"]

View Coverage:

[command]

Test Types

Unit Tests:

  • [Scope and approach]

Integration Tests:

  • [Scope and approach]

E2E Tests:

  • [Framework or "Not used"]

Common Patterns

Async Testing:

[Pattern]

Error Testing:

[Pattern]

Testing analysis: [date]


### INTEGRATIONS.md Template

```markdown
# External Integrations

**Analysis Date:** [YYYY-MM-DD]

## APIs & External Services

**[Category]:**
- [Service] - [What it's used for]
  - SDK/Client: [package]
  - Auth: [env var name]

## Data Storage

**Databases:**
- [Type/Provider]
  - Connection: [env var]
  - Client: [ORM/client]

**File Storage:**
- [Service or "Local filesystem only"]

**Caching:**
- [Service or "None"]

## Authentication & Identity

**Auth Provider:**
- [Service or "Custom"]
  - Implementation: [approach]

## Monitoring & Observability

**Error Tracking:**
- [Service or "None"]

**Logs:**
- [Approach]

## CI/CD & Deployment

**Hosting:**
- [Platform]

**CI Pipeline:**
- [Service or "None"]

## Environment Configuration

**Required env vars:**
- [List critical vars]

**Secrets location:**
- [Where secrets are stored]

## Webhooks & Callbacks

**Incoming:**
- [Endpoints or "None"]

**Outgoing:**
- [Endpoints or "None"]

---

*Integration audit: [date]*

CONCERNS.md Template

# Codebase Concerns

**Analysis Date:** [YYYY-MM-DD]

## Tech Debt

**[Area/Component]:**
- Issue: [What's the shortcut/workaround]
- Files: `[file paths]`
- Impact: [What breaks or degrades]
- Fix approach: [How to address it]

## Known Bugs

**[Bug description]:**
- Symptoms: [What happens]
- Files: `[file paths]`
- Trigger: [How to reproduce]
- Workaround: [If any]

## Security Considerations

**[Area]:**
- Risk: [What could go wrong]
- Files: `[file paths]`
- Current mitigation: [What's in place]
- Recommendations: [What should be added]

## Performance Bottlenecks

**[Slow operation]:**
- Problem: [What's slow]
- Files: `[file paths]`
- Cause: [Why it's slow]
- Improvement path: [How to speed up]

## Fragile Areas

**[Component/Module]:**
- Files: `[file paths]`
- Why fragile: [What makes it break easily]
- Safe modification: [How to change safely]
- Test coverage: [Gaps]

## Scaling Limits

**[Resource/System]:**
- Current capacity: [Numbers]
- Limit: [Where it breaks]
- Scaling path: [How to increase]

## Dependencies at Risk

**[Package]:**
- Risk: [What's wrong]
- Impact: [What breaks]
- Migration plan: [Alternative]

## Missing Critical Features

**[Feature gap]:**
- Problem: [What's missing]
- Blocks: [What can't be done]

## Test Coverage Gaps

**[Untested area]:**
- What's not tested: [Specific functionality]
- Files: `[file paths]`
- Risk: [What could break unnoticed]
- Priority: [High/Medium/Low]

---

*Concerns audit: [date]*

Critical Rules

  • WRITE DOCUMENTS DIRECTLY - Do not return findings to orchestrator. The whole point is reducing context transfer.
  • ALWAYS INCLUDE FILE PATHS - Every finding needs a file path in backticks. No exceptions.
  • USE THE TEMPLATES - Fill in the template structure. Don't invent your own format.
  • BE THOROUGH - Explore deeply. Read actual files. Don't guess.
  • RETURN ONLY CONFIRMATION - Your response should be ~10 lines max. Just confirm what was written.
  • DO NOT COMMIT - The orchestrator handles git operations.

Success Criteria

  • Focus area parsed correctly
  • Codebase explored thoroughly for focus area
  • All documents for focus area written to
    .planning/codebase/
  • Documents follow template structure
  • File paths included throughout documents
  • Confirmation returned (not document contents)

Related Skills

  • @skills/gsd/commands/map-codebase
    - Command that spawns this agent
  • @skills/gsd/references/git-integration
    - Git workflow patterns