# Codeflow Analyzer

> Trace and document the complete call chain / data flow of any feature or process in a codebase. Use this skill whenever the user asks to understand how a feature works end-to-end, trace a call chain, analyze code flow, map data flow across layers, reverse-engineer a process, or asks questions like "how does X call Y", "what happens when the user clicks Z", "trace the request from frontend to database". Also use it when the user wants the analysis exported to a file for offline reading.

- Skill: `okwinds/codeflow-analyzer` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add okwinds/codeflow-analyzer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/okwinds/codeflow-analyzer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: okwinds (https://skillmd.com/u/okwinds)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/okwinds/codeflow-analyzer

---


# Code Flow Analyzer

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

- "这个功能的调用链是怎样的？"
- "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:

1. **Find the surface-level entry** — UI component, CLI command, API endpoint, message handler, cron trigger, etc.
2. **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:

1. **How does this layer receive the call?** (route handler, message consumer, function signature)
2. **What does this layer do with it?** (validation, transformation, delegation, side effects)
3. **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:

1. Write the analysis to the user-specified path (default: ./codeflow-analysis.md)
2. Use the Output Document Structure above
3. Include actual file paths with line numbers
4. 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