Analyze Open Source

---

name: analyze-open-source description: Analyze and explain open-source project code logic, architecture, data flows, APIs, and algorithms. Use when the user asks to analyze a project, understand codebase structure, explain code logic, or requests a technical walkthrough of an open-source repository.

---

Analyze Open-Source Project

Systematically analyze an open-source project's codebase to help the user quickly understand its architecture, core logic, data flows, key APIs, and algorithm implementations.

All analysis output MUST be in Chinese (zh-CN).

Execution Workflow

Follow these steps strictly in order. Use parallel subagents (Task tool with subagent_type="explore") where noted.

Phase 1: Context Gathering

Read these files first (use parallel reads):

1. README.md (or README.rst, README.txt) — project purpose, features, quick start 2. Primary config/dependency file — detect tech stack: - Node.js: package.json - Python: pyproject.toml > setup.py > requirements.txt - Go: go.mod - Java/Kotlin: pom.xml or build.gradle - Rust: Cargo.toml - C/C++: CMakeLists.txt or Makefile - .NET: *.csproj or *.sln 3. CI/Docker files if present (Dockerfile, .github/workflows/) — reveals build & deploy info

Summarize: project name, purpose, tech stack, major dependencies, and build/run commands.

Phase 2: Directory Structure Scan

Run a directory listing (depth 2) to map out the project layout.

Classify each top-level directory into one of:

core: main business logic

api: HTTP/gRPC/CLI interface layer

model/entity: data models or domain objects

config: configuration and environment

util/common: shared utilities

test: test suites

docs: documentation

scripts/tools: build or deployment scripts

other: anything else

Phase 3: Entry Point Identification

Search for program entry points based on the detected tech stack:

| Tech Stack | Typical Entry Points | |---|---| | Node.js | package.json "main"/"scripts.start", index.js, src/index.ts, app.js | | Python | __main__.py, main.py, app.py, manage.py, cli.py | | Go | main.go, cmd/*/main.go | | Java | classes with public static void main, @SpringBootApplication | | Rust | src/main.rs, src/lib.rs | | C/C++ | main.c, main.cpp | | Web Frontend | src/index.tsx, src/main.ts, src/App.vue |

Read the entry point file(s) and trace the initialization/bootstrap sequence.

Phase 4: Deep Analysis

Perform all four dimensions of analysis. Use parallel explore subagents for independent dimensions.

#### 4a. Architecture & Module Dependencies

Identify the architectural pattern (MVC, Clean Architecture, Hexagonal, Microservices, Monolith, etc.)

Map module dependencies — which modules import/call which

Produce a Mermaid graph showing module relationships

#### 4b. Core Business Flow & Data Flow

Trace the primary user-facing workflow(s) end-to-end

Identify how data enters, transforms, persists, and exits the system

Produce a Mermaid flowchart or sequence diagram for the most important flow

#### 4c. Key API Interfaces & Call Chains

List public API endpoints or exported interfaces

For the top 3-5 most important APIs, trace the call chain from handler to data layer

Note middleware, interceptors, or decorators in the chain

#### 4d. Algorithm & Function Implementation

Identify non-trivial algorithms or complex business logic

Extract the key code snippets (keep concise, max ~30 lines each)

Annotate each snippet explaining the logic step by step

Output Format

Use the template defined in template.md to structure the final report.

Key formatting rules:

Use Markdown headings (##, ###) for clear hierarchy

Include at least 2 Mermaid diagrams (architecture graph + primary flow)

Code snippets use CODE REFERENCE format (startLine:endLine:filepath) when citing existing code

Keep the entire report readable in under 15 minutes

Guidelines

Depth over breadth: It is better to deeply explain 3 critical modules than to shallowly list 20.

Follow the data: When in doubt about what to analyze next, follow the data flow.

Cite code: Always reference specific files and line numbers — never make vague claims.

Be opinionated: State clearly what the architectural strengths and weaknesses are.

Progressive disclosure: Start with executive summary; put detailed analysis in later sections. The user should get 80% of the value from the first 20% of the report.