Codebase Explore

Codebase Explore

Return raw exploration findings for a planned change. No plan, no tests, no implementation steps. Just facts about the codebase that a planning skill needs to make informed decisions.

When to Use

• Called by /flagrare:atdd-plan before it writes acceptance tests
• Called directly when you need to understand a codebase area before making decisions
• User says "explore the codebase for X", "what exists for X", "find patterns for X"

Inputs

Receive one of:

• A context brief (from /flagrare:intake)
• A ticket summary describing what will be built
• A plain-text description of the change

Step 1: Check for prior attempts

Search for branches, PRs, and commits related to this work:

git branch -a | grep -i "<ticket-key-or-keyword>"
git log --all --oneline | grep -i "<ticket-key-or-keyword>"
gh pr list --search "<ticket-key-or-keyword>" --state all

If found, read them. They reveal: abandoned approaches, partial implementations, reviewer feedback, constraints discovered during prior attempts.

Step 2: Identify the feature area

From the context brief or description, determine which directories and files the change will touch. Start broad, narrow fast:

1. Search for the main entry point (component, route, controller, endpoint)
2. Trace one level out: what calls it, what it calls
3. Map the data flow: where does data come from, how is it transformed, where does it go

Step 3: Find analogous features

The strongest predictor of how new code should look is how the codebase already solved a similar problem.

Search for:

• Features with similar UI patterns (if frontend)
• Endpoints with similar request/response shapes (if backend)
• Services with similar responsibilities
• Components with similar conditional logic

Read 1-2 complete analogous files. These become the template.

Step 4: Map conventions

For the feature area, identify:

Step 5: Inventory reusable pieces

Find utilities, helpers, shared components, and abstractions that the implementation should use instead of creating from scratch:

• Shared component libraries
• Path/route generators
• API client wrappers
• Validation utilities
• State selectors
• Test helpers and factories

For each, note the import path and a one-line description of what it does.

Step 6: Check constraints

• Linting / formatting: Read .eslintrc, prettier.config, or equivalent
• Type system: What type definitions exist for this area?
• Build / bundling: Any special considerations (lazy loading, code splitting)?
• Feature flags / gating: How are features gated in this codebase?
• CLAUDE.md / DEVELOPMENT_GUIDELINES.md: Read project-level guidance if it exists

Output Format

Return findings in this structure (no headers beyond these, no plan, no steps):

## Prior Attempts
[branches, PRs, commits found, or "none found"]

## Feature Area Map
[entry point → data flow → dependencies, with file paths]

## Analogous Features
[1-2 similar features with file paths and what makes them analogous]

## Conventions
[table of conventions observed in this area]

## Reusable Utilities
[list: import path + one-line description]

## Constraints
[lint rules, type system requirements, gating, project guidelines]

Anti-patterns

• Don't write a plan. Return findings only.
• Don't write tests or implementation steps. That's atdd-plan's job.
• Don't summarize or interpret beyond what you directly observed in the code.
• Don't read entire codebases. Focus on the feature area and one level out.
• Don't guess file paths. Verify they exist before reporting them.
• Don't skip Step 1 (prior attempts). Abandoned PRs contain critical context.

Flow position

/flagrare:intake              ← context brief produced
     ↓
/flagrare:atdd-plan
     ├── /flagrare:codebase-explore   ← THIS SKILL (returns raw findings)
     ├── writes acceptance tests
     ├── names design patterns
     ├── SOLID audit
     └── gap review