# 💡 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...**