Systematically trace the complete call chain of any feature or process in a codebase, from entry point to the deepest dependency, and produce a structured analysis document.
When This Skill Applies
- "What is the call chain of this feature?"
- "Trace the request flow from X to Y"
- "How does feature Z work under the hood?"
- "Map the data flow of this process"
- "I want to understand the full path from user input to final output"
- Any question about how layers connect: frontend → API → service → domain → storage
Core Approach: Layer-by-Layer Tracing
Real-world codebases are layered. Each layer has its own conventions for entry points, routing, and delegation. Instead of guessing the architecture, discover it empirically by following the actual code paths.
Phase 1: Identify Entry Point
Start from the user-facing trigger:
- Find the surface-level entry — UI component, CLI command, API endpoint, message handler, cron trigger, etc.
- Identify what it calls — the first cross-boundary call (HTTP request, function import, message publish, RPC call).
Techniques:
- Grep for keywords from the user's description (feature name, button label, route path, event name)
- Glob for files matching the feature name pattern
- Read the entry file to find outbound calls
Phase 2: Trace Through Each Layer
For each layer discovered, answer three questions:
- How does this layer receive the call? (route handler, message consumer, function signature)
- What does this layer do with it? (validation, transformation, delegation, side effects)
- Where does it hand off next? (outbound call, return value, event emission)
Repeat until you reach a terminal point (database write, external API call, file output, response return).
Parallel exploration strategy: When entering a new layer, launch multiple searches in parallel:
- Grep for the function/class/route name being called
- Glob for files matching the module/package name
- Read configuration files that might define routing or wiring
Phase 3: Map Supporting Systems
After the main call chain is clear, identify supporting concerns:
- Configuration: Where are settings, feature flags, environment variables loaded?
- Dependency injection / wiring: How are components connected?
- External resources: What templates, prompt files, schema definitions, or config files are loaded at runtime?
Only trace these if they are relevant to understanding the flow.
Phase 4: Synthesize
Assemble findings into a coherent narrative. The output structure should follow the natural flow of the code, not the order you discovered it.
Output Document Structure
Adapt this template to the actual codebase — don't force layers that don't exist, add layers the template doesn't anticipate.
# [Feature/Process Name]: Complete Call Chain Analysis
## Overview
- Brief summary of what the feature does
- List of main paths (if there are multiple)
- Key technologies/frameworks involved
## Path N: [Path Name]
### Layer 1: [Layer Name]
- Entry point: file:line
- Key logic: what happens here
- Handoff: what it calls next and how
### Layer 2: [Layer Name]
...repeat...
### Layer N: [Terminal Layer]
- Final action: what happens at the end
## Supporting Systems
- Configuration loading
- Dependency wiring
- External resources
## Data Flow Summary
Input -> Layer1 -> Layer2 -> ... -> Output
## Key Findings
- Important architectural decisions observed
- Non-obvious connections or indirections
- Potential gotchas or complexity hotspots
Exploration Budget
- Target: 5-12 tool calls for a typical 3-4 layer trace
- Parallel-first: Always batch independent searches in a single turn
- Early stop: If 3+ searches converge on the same area, read the files instead of searching more
- Depth control: For well-known frameworks, summarize the framework role briefly rather than tracing into internals
Export
When the user requests export:
- Write the analysis to the user-specified path (default: ./codeflow-analysis.md)
- Use the Output Document Structure above
- Include actual file paths with line numbers
- Keep code snippets short (key signatures and calls only)
Anti-Patterns to Avoid
- Do not guess architecture — trace actual code
- Do not trace framework internals — stop at the boundary of third-party code
- Do not dump entire files — extract only the relevant lines
- Do not over-search — if you have identified the file, read it directly
- Do not mix discovery order with presentation order — follow the call flow