---
name: codeflow-analyzer
version: 0.1.0
description: >
  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.
---

# 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