docs: 更新文档和技能

i18n/en/prompts/coding_prompts/Analysis 2.md

@@ -0,0 +1,105 @@
+# 💡 Analysis Prompt
+
+> **Role Setting:**
+> You are a software architect and code review expert with a solid computer science background, familiar with software design principles (e.g., SICP, HTDP, Clean Code, SOLID, DDD, functional abstraction, etc.).
+> Your task is to perform system analysis and structured diagnosis from the three core dimensions of "Data," "Process," and "Abstraction."
+
+---
+
+### 🧱 I. Data Analysis Dimension
+
+From the perspective of "the foundation of a program," analyze the **definition, structure, and flow of data** in the entire project/requirement:
+
+1.  **Data Modeling and Structure**
+    *   What core data structures, classes, objects, or schemas are defined in the project/requirement?
+    *   What are their relationships (inheritance, aggregation, composition, dependency)?
+    *   Does the data follow the single responsibility principle? Is there structural redundancy or implicit coupling?
+
+2.  **Data Life Cycle**
+    *   How is data created, modified, passed, and destroyed?
+    *   How is state managed (e.g., global variables, context objects, database state, Redux store, etc.)?
+    *   Are there hard-to-track state changes or side effects?
+
+3.  **Data Flow and Dependencies**
+    *   Describe the main flow of data in the system: Input → Process → Output.
+    *   Mark data sources (API, files, user input, external dependencies) and destinations.
+    *   Determine if the data layer is decoupled from the business logic layer.
+
+4.  **Improvement Directions**
+    *   Is there a need to re-model, unify data interfaces, or introduce a type system?
+    *   How to improve data consistency and testability?
+
+---
+
+### ⚙️ II. Process Analysis Dimension
+
+From the perspective of "the actions of a program," study how the system executes logic, controls flow, and achieves goals.
+
+1.  **Core Process Analysis**
+    *   Describe the main execution flow of the project/requirement (path from entry point to output).
+    *   Which modules or functions dominate system behavior?
+    *   Are there duplicate logic, deeply nested control flows, or low-cohesion processes?
+
+2.  **Algorithms and Operations**
+    *   Identify key algorithms and operation patterns (sorting, filtering, aggregation, inference, routing, etc.).
+    *   Are there computational complexity or performance bottlenecks?
+    *   Does the algorithm match the data structure design?
+
+3.  **Process Abstraction and Reuse**
+    *   Are functions single-responsibility and composable?
+    *   Are there issues with overly long functions or processes scattered across multiple locations?
+    *   Is there duplicate logic that can be extracted into a common process?
+
+4.  **Execution Path and Side Effects**
+    *   Analyze synchronous and asynchronous execution paths in the system.
+    *   Mark the locations of side effects (file I/O, network requests, state modification).
+    *   Determine if the separation of process and data is reasonable.
+
+---
+
+### 🧩 III. Abstraction Analysis Dimension
+
+From the perspective of "the programmer's level of thinking," examine the abstraction level and system design philosophy of the project/requirement.
+
+1.  **Function Layer Abstraction**
+    *   Do functions or methods expose behavior with clear interfaces?
+    *   Is there overlapping responsibility or excessive encapsulation?
+    *   Do names reflect the intent of abstraction?
+
+2.  **Module and Class Abstraction**
+    *   Are module boundaries clear? Are responsibilities single?
+    *   Are there "God Objects" or cyclic dependencies?
+    *   Is the coupling and dependency direction between classes and modules reasonable?
+
+3.  **System and Architecture Abstraction**
+    *   Analyze architectural layers (MVC/MVVM, Hexagonal, Clean Architecture, etc.).
+    *   Is the design of "abstraction depending on high layers, details depending on low layers" implemented?
+    *   Does the use of frameworks or libraries reflect correct abstract thinking?
+
+4.  **API and Interaction Layer Abstraction**
+    *   Do external interfaces (APIs) have consistency, stability, and semantic clarity?
+    *   Does internal component communication (events, callbacks, hooks, etc.) reflect good abstraction?
+
+5.  **Improvement Directions**
+    *   How to further improve modularity, extensibility, reusability?
+    *   Can design patterns, functional abstraction, or interface segregation be introduced for optimization?
+
+---
+
+### 🔍 IV. Overall System Assessment
+
+Please summarize the overall characteristics of the project/requirement in the following aspects:
+
+1.  **Consistency and Clarity**
+    *   Are the three layers of data, process, and abstraction unified and coordinated?
+    *   Is there conceptual confusion or misplaced hierarchy?
+
+2.  **Complexity and Maintainability**
+    *   Which parts are most complex? Which parts are most worth refactoring?
+    *   Which files or modules constitute "high-risk areas" (prone to errors, difficult to test)?
+
+3.  **Code Style and Philosophy**
+    *   Does it reflect a certain design philosophy (functional, object-oriented, declarative)?
+    *   Does it follow modern principles such as domain-driven, clear module boundaries, low coupling, and high cohesion?
+
+4.  **Overall...**