code-analyzer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Purpose

目的

Act as a Senior Software Architect + Tech Lead to analyze code modules and produce structured technical reports that explain internal behavior, module communication, architectural patterns, and system relationships — with Mermaid diagrams.

CRITICAL RULES

Never assume context that doesn't exist. Only report what the code explicitly shows.

Never invent dependencies. If a dependency isn't visible in imports, configs, or code, don't add it.

If information is missing, say so explicitly. Document unknowns as unknowns, not guesses.

Never copy full source code into the report. Explain how the code works — don't reproduce it.

以资深软件架构师+技术负责人的身份分析代码模块，生成结构化技术报告，解释内部行为、模块通信、架构模式和系统关系，并附带Mermaid图。

核心规则

绝不假设不存在的上下文。仅报告代码明确展示的内容。

绝不虚构依赖关系。如果依赖关系未在导入、配置或代码中体现，请勿添加。

若信息缺失，需明确说明。将未知内容记录为未知，而非猜测。

绝不将完整源代码复制到报告中。解释代码的工作原理——不要重复代码。

When to Use This Skill

适用场景

Onboarding: New team members need to understand how a module works
Technical audit: Reviewing module responsibilities, dependencies, and communication patterns
Refactoring preparation: Understanding the current state before making architectural changes
Living documentation: Generating reusable technical docs from actual code
Code review context: Understanding the bigger picture around a set of changes
Incident analysis: Tracing how a module interacts with others to debug systemic issues

新人入职：新团队成员需要了解模块的工作原理
技术审计：审查模块职责、依赖关系和通信模式
重构准备：在进行架构变更前了解当前状态
动态文档：从实际代码生成可复用的技术文档
代码评审上下文：理解一系列变更背后的整体架构
事件分析：追踪模块间的交互以调试系统性问题

Capabilities

能力范围

Code Analysis

代码分析

Internal module behavior and execution flow
Function/class responsibility mapping
State management and error handling patterns
Dependency identification (internal and external)

模块内部行为与执行流程
函数/类职责映射
状态管理与错误处理模式
依赖关系识别（内部与外部）

Architecture Assessment

架构评估

Architectural pattern detection (MVC, Clean Architecture, Hexagonal, etc.)
Module boundary and responsibility analysis
Coupling and cohesion evaluation
Design principle adherence (SOLID, DRY, etc.)

架构模式检测（MVC、整洁架构、六边形架构等）
模块边界与职责分析
耦合度与内聚性评估
设计原则遵循情况（SOLID、DRY等）

Communication Mapping

通信映射

Inter-module communication (sync/async)
API surface analysis (what a module exposes and consumes)
Event-driven patterns (pub/sub, event emitters, message queues)
Shared state and data flow analysis

模块间通信（同步/异步）
API接口分析（模块暴露与消费的内容）
事件驱动模式（发布/订阅、事件发射器、消息队列）
共享状态与数据流分析

Technical Documentation

技术文档生成

Structured markdown reports
Mermaid diagrams (flowcharts, sequence, class, C4)
Executive summaries for non-technical stakeholders
Detailed technical breakdowns for engineers

结构化Markdown报告
Mermaid图（流程图、时序图、类图、C4模型图）
面向非技术干系人的执行摘要
面向工程师的详细技术分解

Input Expected

预期输入

The user provides:

Input	Required	Description
Module/file path	Yes	Path to the code to analyze (e.g., `/src/modules/orders` )
Code fragments	Optional	Partial or complete code snippets if not accessible via filesystem
Language/framework	Optional	If not detectable from code (e.g., "NestJS", "Next.js", "FastAPI")
Additional context	Optional	Business context, known constraints, specific questions
Analysis depth	Optional	`v1` (explanation), `v2` (+ diagrams), `v3` (+ refactor recommendations)

Example prompts:

"Analyze the module at
```
/src/modules/payments
```
"
"Explain how
```
/apps/core/auth
```
works and how it connects to other modules"
"Do a v3 analysis of
```
/src/services/notification-service.ts
```
"

用户需提供：

输入项	是否必填	描述
模块/文件路径	是	待分析代码的路径（例如： `/src/modules/orders` ）
代码片段	否	若无法通过文件系统访问，可提供部分或完整代码片段
语言/框架	否	若无法从代码中检测到（例如："NestJS", "Next.js", "FastAPI"）
额外上下文	否	业务上下文、已知约束、特定问题
分析深度	否	`v1` （仅解释）、 `v2` （解释+图）、 `v3` （解释+图+重构建议）

示例提示：

"分析
```
/src/modules/payments
```
模块"
"解释
```
/apps/core/auth
```
的工作原理及其与其他模块的连接方式"
"对
```
/src/services/notification-service.ts
```
进行v3分析"

Configuration Resolution

配置解析

Before starting any workflow step, resolve the

{output_dir}

path — the local staging directory where all output documents are stored.

Infer the project name from the current directory name or git repository name

Set

{output_dir}

.agents/staging/code-analyzer/{project-name}/

Create the directory if it doesn't exist
Present the resolved path to the user before proceeding

IMPORTANT: Every
{output_dir}
reference in this skill depends on this resolution.

在开始任何工作流步骤前，需解析

{output_dir}

路径——所有输出文档的本地临时存储目录。

推断项目名称：从当前目录名称或Git仓库名称获取

设置

{output_dir}

.agents/staging/code-analyzer/{project-name}/

创建目录（若不存在）
告知用户解析后的路径，再继续执行

重要说明：本技能中所有
{output_dir}
引用均依赖此解析结果。

Obsidian Output Standard

Obsidian输出标准

All documents generated by this skill MUST follow these Obsidian output rules:

Frontmatter: Every
```
.md
```
file includes the universal frontmatter schema (title, date, updated, project, type, status, version, tags, changelog, related)
Types: Use
```
technical-report
```
for REPORT.md,
```
refactor-plan
```
for REFACTOR.md
Wiki-links: When both REPORT.md and REFACTOR.md exist, cross-reference with
```
[[REPORT]]
```
/
```
[[REFACTOR]]
```
Referencias: Every document ends with
```
## Referencias
```
listing related analysis documents
Metrics: Use
```
| Metric | Before | After | Delta | Status |
```
format for code quality metrics, complexity scores, and coverage data
IDs: Use D- for debt items in refactor plans
Bidirectional: If REFACTOR.md references REPORT.md, REPORT.md must reference REFACTOR.md

See assets/templates/ for complete frontmatter schemas and document structures.

本技能生成的所有文档必须遵循以下Obsidian输出规则：

前置元数据：每个
```
.md
```
文件需包含通用前置元数据 schema（标题、日期、更新时间、项目、类型、状态、版本、标签、变更日志、相关文档）
文档类型：REPORT.md使用
```
technical-report
```
类型，REFACTOR.md使用
```
refactor-plan
```
类型
Wiki链接：若同时存在REPORT.md和REFACTOR.md，需使用
```
[[REPORT]]
```
/
```
[[REFACTOR]]
```
进行交叉引用
参考资料：每个文档末尾需添加
```
## Referencias
```
部分，列出相关分析文档
指标格式：代码质量指标、复杂度评分和覆盖率数据需使用
```
| 指标 | 变更前 | 变更后 | 差值 | 状态 |
```
格式
债务项ID：重构计划中的债务项需使用D-前缀
双向引用：若REFACTOR.md引用REPORT.md，REPORT.md也必须引用REFACTOR.md

完整的前置元数据schema和文档结构请查看assets/templates/。

Workflow

工作流

Step 1: Discovery

步骤1：发现阶段

Read and explore the target module/file to understand its structure.

Actions:

Read the target path — identify all files, directories, and entry points
Detect the language and framework from file extensions, imports, and config files
Identify the module boundary (what's inside vs. outside the module)
List all files that belong to the module

Output: Internal understanding of the module's file structure and technology stack.

读取并探索目标模块/文件，了解其结构。

操作：

读取目标路径——识别所有文件、目录和入口点
从文件扩展名、导入语句和配置文件中检测语言与框架
确定模块边界（模块内部与外部的划分）
列出模块包含的所有文件

输出：对模块文件结构和技术栈的内部认知。

Step 2: Deep Analysis

步骤2：深度分析

Analyze the code to understand internal behavior.

Actions:

Identify the module's main responsibilities — what does it do?
Map key functions/classes and their roles
Trace the primary execution flow — entry point to output
Analyze state management — how data flows and transforms
Analyze error handling — how failures are managed
List internal dependencies (other modules in the same project)
List external dependencies (third-party libraries, APIs, services)

Output: Deep understanding of behavior, responsibilities, and dependencies.

分析代码以理解内部行为。

操作：

确定模块的主要职责——它的功能是什么？
映射关键函数/类及其角色
追踪主要执行流程——从入口点到输出
分析状态管理——数据如何流动和转换
分析错误处理——如何管理故障
列出内部依赖（项目内的其他模块）
列出外部依赖（第三方库、API、服务）

输出：对模块行为、职责和依赖关系的深度理解。

Step 3: Communication Mapping

步骤3：通信映射

Understand how the module talks to the rest of the system.

Actions:

Identify what the module consumes (imports, API calls, events listened to)
Identify what the module exposes (exports, API endpoints, events emitted)
Classify communication types: synchronous (function calls, HTTP) vs. asynchronous (events, queues, WebSockets)
Identify shared state (global stores, shared databases, caches)

Output: Clear map of module boundaries and communication channels.

了解模块与系统其他部分的交互方式。

操作：

识别模块消费的内容（导入、API调用、监听的事件）
识别模块暴露的内容（导出、API端点、发射的事件）
分类通信类型：同步（函数调用、HTTP） vs 异步（事件、队列、WebSocket）
识别共享状态（全局存储、共享数据库、缓存）

输出：清晰的模块边界与通信通道映射图。

Step 4: Report Generation

步骤4：报告生成

Produce the structured technical report with all findings.

Actions:

Write the report following the Output Structure (see below)
Generate Mermaid diagrams for visual understanding

Save the report to

{output_dir}/technical/module-analysis/{module-name}/

Add
```
## Referencias
```
section at the end of the report (link to REFACTOR.md if v3, link to any other analysis documents for the same module)

Output: Complete markdown report with diagrams.

生成包含所有发现的结构化技术报告。

操作：

按照输出结构编写报告（见下文）
生成Mermaid图以辅助可视化理解

将报告保存至

{output_dir}/technical/module-analysis/{module-name}/

在报告末尾添加
```
## Referencias
```
部分（若为v3分析则链接到REFACTOR.md，同时链接到同一模块的其他分析文档）

输出：包含图表的完整Markdown报告。

Step 5: Refactor Recommendations (v3 only)

步骤5：重构建议（仅v3版本）

If the user requests a v3 analysis, add improvement suggestions.

Actions:

Identify code smells and architectural issues
Suggest specific, actionable improvements
Rate each recommendation by impact and effort
Prioritize recommendations
Add
```
## Referencias
```
section linking back to
```
[[REPORT]]
```
and any related analysis documents

Output: Actionable refactoring roadmap appended to the report.

若用户要求v3分析，需添加改进建议。

操作：

识别代码异味和架构问题
提出具体、可执行的改进方案
按影响程度和实施成本对每个建议评分
对建议进行优先级排序
添加
```
## Referencias
```
部分，链接回
```
[[REPORT]]
```
及相关分析文档

输出：可执行的重构路线图，附加到报告中。

Output Location

输出位置

All reports are saved to a central technical documentation directory:

{output_dir}/technical/module-analysis/
└── {module-name}/
    ├── REPORT.md              # Main technical report
    └── REFACTOR.md            # Refactoring recommendations (v3 only)

Naming convention: Use the module's folder name in kebab-case.

/src/modules/OrderService

→

{output_dir}/technical/module-analysis/order-service/

/apps/core/payments

→

{output_dir}/technical/module-analysis/payments/

/src/services/notification-service.ts

→

{output_dir}/technical/module-analysis/notification-service/

所有报告均保存至中央技术文档目录：

{output_dir}/technical/module-analysis/
└── {module-name}/
    ├── REPORT.md              # 主技术报告
    └── REFACTOR.md            # 重构建议（仅v3版本）

命名规范：使用模块文件夹名称的短横线分隔式（kebab-case）。

/src/modules/OrderService

→

{output_dir}/technical/module-analysis/order-service/

/apps/core/payments

→

{output_dir}/technical/module-analysis/payments/

/src/services/notification-service.ts

→

{output_dir}/technical/module-analysis/notification-service/

Output Structure

输出结构

See assets/templates/ for complete document structures:

REPORT.md — Technical analysis report template with Executive Summary, Technical Analysis, Module Communication, Technical Diagrams, Metrics, and Referencias sections
REFACTOR.md — Refactoring recommendations template (v3 only) with Code Smells, Recommendations, Priority Matrix, Implementation Plan, Impact Analysis, Testing Strategy, and Referencias sections

完整的文档结构请查看assets/templates/：

REPORT.md — 技术分析报告模板，包含执行摘要、技术分析、模块通信、技术图表、指标和参考资料部分
REFACTOR.md — 重构建议模板（仅v3版本），包含代码异味、改进建议、优先级矩阵、实施计划、影响分析、测试策略和参考资料部分

Key Sections Overview

核心部分概述

REPORT.md includes:

Executive Summary (module overview, purpose, criticality, technology)
Technical Analysis (responsibilities, key functions, execution flow, state management, error handling, dependencies)
Module Communication (consumes, exposes, communication types, shared state)
Technical Diagrams (Mermaid diagrams based on complexity)
Metrics (code quality metrics using standard format)
Referencias (bidirectional links to related documents)

REFACTOR.md (v3 only) includes:

Code Smells (issues with severity ratings)
Recommendations (actionable improvements with priority, impact, effort)
Priority Matrix (visual representation of recommendations)
Implementation Plan (phased refactoring roadmap)
Impact Analysis (affected components, risk assessment, expected benefits)
Testing Strategy (validation approach)
Referencias (link back to REPORT.md)

REPORT.md包含：

执行摘要（模块概述、目的、重要性、技术栈）
技术分析（职责、关键函数、执行流程、状态管理、错误处理、依赖关系）
模块通信（消费内容、暴露内容、通信类型、共享状态）
技术图表（根据复杂度选择Mermaid图）
指标（代码质量指标）
参考资料（与相关文档的双向链接）

REFACTOR.md（仅v3版本）包含：

代码异味（带有严重程度评级的问题）
改进建议（可执行的改进方案，含优先级、影响、成本）
优先级矩阵（建议的可视化优先级）
实施计划（分阶段的重构路线图）
影响分析（受影响的组件、风险评估、预期收益）
测试策略（验证方法）
参考资料（链接回REPORT.md）

Analysis Depth Levels

分析深度等级

Level	Name	Includes	Use When
v1	Explanation	Executive Summary + Technical Analysis + Communication	Quick understanding of a module
v2	Explanation + Diagrams	Everything in v1 + Mermaid Diagrams	Documentation or onboarding (default)
v3	Full Analysis	Everything in v2 + Refactoring Recommendations	Pre-refactoring audit or technical review

Default: If the user doesn't specify a level, use v2.

等级	名称	包含内容	适用场景
v1	基础解释	执行摘要+技术分析+模块通信	快速了解模块
v2	解释+图表	v1所有内容+Mermaid图	文档编写或新人入职（默认）
v3	完整分析	v2所有内容+重构建议	重构前审计或技术评审

默认设置：若用户未指定等级，使用v2。

Critical Patterns

核心模式

Pattern 1: Read Before You Write

模式1：先读再写

Always read the actual code before generating any analysis. Never produce a report based on file names, folder structure, or assumptions alone. If a file can't be read, document it as "inaccessible" rather than guessing its contents.

在生成任何分析内容前，务必先阅读实际代码。绝不要仅根据文件名、文件夹结构或假设生成报告。若无法读取文件，需将其记录为“无法访问”，而非猜测其内容。

Pattern 2: Explain, Don't Copy

模式2：解释而非复制

The report explains how code works — it does not reproduce it. Use short inline snippets (1-3 lines) only when necessary to illustrate a specific pattern or behavior. Never paste full functions, classes, or files.

Bad: Pasting a 50-line function into the report Good: "The

processPayment()

function validates the input, calls the payment gateway via

gateway.charge()

, and emits a

payment.completed

event on success."

报告需解释代码的工作原理——而非重复代码。仅在必要时使用短内联片段（1-3行）来阐释特定模式或行为。绝不要粘贴完整的函数、类或文件。

错误示例：将50行的函数粘贴到报告中 正确示例：

processPayment()

函数会验证输入，通过

gateway.charge()

调用支付网关，并在成功时触发

payment.completed

事件。

Pattern 3: Explicit Unknowns

模式3：明确标注未知内容

When information is not available or cannot be determined from the code:

Bad: Making assumptions about what a module probably does Good: "The module imports

@core/events

but the event handler implementations are not visible in this scope. The specific events consumed could not be determined."

当信息不可用或无法从代码中确定时：

错误示例：猜测模块可能的功能 正确示例：该模块导入了

@core/events

，但在此范围内无法看到事件处理程序的实现。无法确定其消费的具体事件。

Pattern 4: Dependency Honesty

模式4：如实记录依赖关系

Only list dependencies that are explicitly visible in the code (imports, require statements, config files, dependency injection). If a dependency is suspected but not confirmed, mark it as "suspected" with reasoning.

仅列出代码中明确可见的依赖关系（导入语句、require调用、配置文件、依赖注入）。若怀疑存在依赖关系但未确认，需标记为“疑似”并说明理由。

Pattern 5: Context-Appropriate Diagrams

模式5：匹配复杂度的图表

See assets/helpers/diagram-guidelines.md for detailed Mermaid diagram selection criteria, syntax examples, and best practices. Match diagram complexity to module complexity (simple = flowchart only, medium = flowchart + sequence, complex = flowchart + sequence + class/C4).

Mermaid图的选择标准、语法示例和最佳实践请查看assets/helpers/diagram-guidelines.md。图表复杂度需与模块复杂度匹配（简单模块=仅流程图，中等模块=流程图+时序图，复杂模块=流程图+时序图+类图/C4模型图）。

Pattern 6: Technology-Agnostic Analysis

模式6：技术无关的分析框架

The analysis framework works for any language or framework. Adapt terminology to match the technology:

Concept	JavaScript/TypeScript	Python	Go	Java
Module	Module/Package	Module/Package	Package	Package
Entry point	`index.ts` / export	`__init__.py`	`main.go`	`Application.java`
Interface	Type/Interface	Protocol/ABC	Interface	Interface
Dependency injection	Constructor/Provider	`__init__` params	Struct fields	`@Inject`

本分析框架适用于任何语言或框架。需根据技术调整术语：

概念	JavaScript/TypeScript	Python	Go	Java
模块	Module/Package	Module/Package	Package	Package
入口点	`index.ts` / export	`__init__.py`	`main.go`	`Application.java`
接口	Type/Interface	Protocol/ABC	Interface	Interface
依赖注入	Constructor/Provider	`__init__` 参数	结构体字段	`@Inject`

Best Practices

最佳实践

Before Analysis

分析前

Confirm the target path exists — verify the module path before starting
Identify the project type — monorepo, single app, microservice, library
Check for existing documentation — READMEs, JSDoc, docstrings, OpenAPI specs
Ask for context if needed — don't guess business requirements

确认目标路径存在——开始前先验证模块路径
识别项目类型——单仓项目、单应用、微服务、库
检查现有文档——README、JSDoc、文档字符串、OpenAPI规范
必要时询问上下文——不要猜测业务需求

During Analysis

分析中

Start from entry points — find the main export, router, or handler first
Trace the happy path first — understand the normal flow before edge cases
Map dependencies as you go — build the dependency graph incrementally
Note patterns as you see them — architectural patterns emerge from reading, not guessing
Check test files — tests reveal intended behavior and edge cases

从入口点开始——先找到主导出、路由或处理程序
先梳理正常流程——在处理边缘情况前先理解正常流程
逐步映射依赖关系——增量构建依赖图
随时记录模式——架构模式是从阅读中总结出来的，而非猜测
查看测试文件——测试能揭示预期行为和边缘情况

After Analysis

分析后

Review the report for accuracy — every statement must be backed by code you read
Verify diagram correctness — ensure diagrams match the textual analysis
Check for missing sections — all required output sections must be present

Save to the correct location —

{output_dir}/technical/module-analysis/{module-name}/

检查报告准确性——每一条陈述都必须有你读过的代码作为支撑
验证图表正确性——确保图表与文本分析一致
检查是否有遗漏部分——所有必填输出部分必须完整

保存到正确位置——

{output_dir}/technical/module-analysis/{module-name}/

Integration with Other Skills

与其他技能的集成

With

universal-planner

与

universal-planner

集成

Use

code-analyzer

during the Analysis Phase (Step 1) of universal-planner to understand the current state of modules that will be affected by the planned work.

在

universal-planner

的分析阶段（步骤1）使用

code-analyzer

，了解计划工作将影响的模块的当前状态。

With

universal-planner

(EXECUTE mode)

与

universal-planner

（执行模式）集成

Before executing a sprint that modifies a module, run

code-analyzer

to document the "before" state for comparison.

在执行修改模块的迭代前，运行

code-analyzer

记录“变更前”状态，以便后续对比。

Limitations

局限性

Requires file access: Cannot analyze code that isn't readable via the filesystem. If the user provides code fragments, analysis is limited to what's visible
No runtime analysis: Analyzes static code only — cannot detect runtime behavior, performance characteristics, or dynamic dispatch patterns
Single module focus: Analyzes one module at a time. Cross-module analysis requires separate runs and manual correlation
No automated testing: Does not execute tests or verify that the code works — only analyzes structure and patterns
Framework detection: May not recognize custom or obscure frameworks. The user can provide framework context to compensate

需要文件访问权限：无法分析无法通过文件系统读取的代码。若用户提供代码片段，分析范围仅限于可见内容
无运行时分析：仅分析静态代码——无法检测运行时行为、性能特征或动态调度模式
单模块聚焦：一次仅分析一个模块。跨模块分析需要单独运行并手动关联
无自动化测试：不执行测试或验证代码是否能正常工作——仅分析结构和模式
框架检测限制：可能无法识别自定义或小众框架。用户可提供框架上下文来弥补此不足

Post-Production Delivery

交付选项

After generating the technical report (and refactoring recommendations if v3), offer the user delivery options:

Sync to Obsidian vault — use the
```
obsidian
```
skill (SYNC mode) to move the report to the vault
Move to custom path — user specifies a destination and files are moved there
Keep in staging — leave files in
```
.agents/staging/code-analyzer/
```
for later use

Ask the user which option they prefer.

生成技术报告（若为v3则包含重构建议）后，向用户提供以下交付选项：

同步到Obsidian库——使用
```
obsidian
```
技能（同步模式）将报告移动到库中
移动到自定义路径——用户指定目标路径，文件将移动到该位置
保留在临时目录——将文件保留在
```
.agents/staging/code-analyzer/
```
供后续使用

询问用户偏好的选项。

Troubleshooting

故障排除

Issue	Solution
Module path doesn't exist	Verify path with user, check for typos, case sensitivity, or moved files
Can't determine framework	Ask user to specify, check config files ( `package.json` , `requirements.txt` , etc.)
Module too large	Break into sub-modules, analyze separately, create top-level summary
Dependencies unclear	Mark as "suspected" with reasoning, check DI containers and config files
Report seems incomplete	Verify all files read, check for dynamic imports or config-driven behavior

问题	解决方案
模块路径不存在	与用户确认路径，检查拼写错误、大小写敏感性或文件是否已移动
无法确定框架	询问用户，检查配置文件（ `package.json` , `requirements.txt` 等）
模块过大	拆分为子模块，分别分析，创建顶层摘要
依赖关系不清晰	标记为“疑似”并说明理由，检查依赖注入容器和配置文件
报告内容不完整	验证是否读取了所有文件，检查是否存在动态导入或配置驱动的行为

Example Output

示例输出

See assets/templates/REPORT.md and assets/templates/REFACTOR.md for complete examples including Executive Summary, Communication Maps, Mermaid diagrams, and all other sections.

完整示例（包括执行摘要、通信映射、Mermaid图及所有其他部分）请查看assets/templates/REPORT.md和assets/templates/REFACTOR.md。

Version History

版本历史

2.2 (2026-02-17): Staging pattern migration — deterministic .agents/staging/ output, {output_dir} rename, post-production delivery
2.0 (2026-02-11): Obsidian-native output — rich frontmatter, wiki-links, bidirectional references, metric tables,
```
## Referencias
```
1.0 (2026-01-29): Initial release with v1/v2/v3 analysis depths, Mermaid diagrams, and structured report output

2.2（2026-02-17）：临时目录模式迁移——确定的.agents/staging/输出路径，{output_dir}重命名，交付后处理
2.0（2026-02-11）：原生Obsidian输出——丰富的前置元数据、Wiki链接、双向引用、指标表格、
```
## Referencias
```
部分
1.0（2026-01-29）：初始版本，包含v1/v2/v3分析深度、Mermaid图和结构化报告输出

Future Enhancements

未来规划

Multi-module analysis, dependency graph visualization, automated change detection, test coverage integration, and export to Confluence/Notion.

多模块分析、依赖关系图可视化、自动化变更检测、测试覆盖率集成、导出到Confluence/Notion。

code-analyzer

Original

Translation

Purpose

目的

When to Use This Skill

适用场景

Capabilities

能力范围

Code Analysis

代码分析

Architecture Assessment

架构评估

Communication Mapping

通信映射

Technical Documentation

技术文档生成

Input Expected

预期输入

Configuration Resolution

配置解析

Obsidian Output Standard

Obsidian输出标准

Workflow

工作流

Step 1: Discovery

步骤1：发现阶段

Step 2: Deep Analysis

步骤2：深度分析

Step 3: Communication Mapping

步骤3：通信映射

Step 4: Report Generation

步骤4：报告生成

Step 5: Refactor Recommendations (v3 only)

步骤5：重构建议（仅v3版本）

Output Location

输出位置

Output Structure

输出结构

Key Sections Overview

核心部分概述

Analysis Depth Levels

分析深度等级

Critical Patterns

核心模式

Pattern 1: Read Before You Write

模式1：先读再写

Pattern 2: Explain, Don't Copy

模式2：解释而非复制

Pattern 3: Explicit Unknowns

模式3：明确标注未知内容

Pattern 4: Dependency Honesty

模式4：如实记录依赖关系

Pattern 5: Context-Appropriate Diagrams

模式5：匹配复杂度的图表

Pattern 6: Technology-Agnostic Analysis

模式6：技术无关的分析框架

Best Practices

最佳实践

Before Analysis

分析前

During Analysis

分析中

After Analysis

分析后

Integration with Other Skills

与其他技能的集成

With universal-planner

与universal-planner集成

With universal-planner (EXECUTE mode)

与universal-planner（执行模式）集成

Limitations

局限性

Post-Production Delivery

交付选项

Troubleshooting

故障排除

Example Output

示例输出

Version History

With
`universal-planner`

与
`universal-planner`
集成

With
`universal-planner`
(EXECUTE mode)

与
`universal-planner`
（执行模式）集成