• Code ≤ 2000 lines: Uses progressive generation (sequential chapter filling)
• Code > 2000 lines: Automatically enables parallel processing (sub-Agents analyze chapters in parallel)

"Able to read code ≠ Able to write code"
"Able to understand explanations ≠ Able to implement independently"
"Feel like understanding ≠ Truly understand"

• Understand the WHY, not just the WHAT
• Enforce self-explanation to verify true understanding
• Establish conceptual connections, not isolated memory
• Test transfer ability through application variants

• Dunlosky et al. - Elaborative interrogation is significantly more effective than passive reading
• Chi et al. - Self-explainers are more likely to acquire correct mental models
• Karpicke & Roediger - Retrieval practice is 250% better than repeated reading

• Quickly identify code type and core functions
• List key concepts (no in-depth verification required)

• Conduct self-explanation tests on core concepts
• Verify ability to explain the "WHY"

• Full self-explanation test
• Application transfer ability verification

undefined

• Programming language and version
• Code scale and type
• Core dependencies

• What is the main function (WHAT)
• Brief explanation of WHY it's needed

• Algorithm complexity (if applicable)
• Design patterns used (if applicable)
• WHY this algorithm/pattern was chosen

• 3-5 core code snippets
• Brief explanation of each snippet's role

• List of external libraries and their uses

• Simple runnable example

undefined

• Programming language, scale, dependencies

• WHY this code is needed
• WHY this solution was chosen
• WHY other solutions were not chosen

• List key concepts
• Answer 2-3 WHY questions for each concept

• Complexity analysis
• WHY this algorithm was chosen
• Reference materials

• Identified patterns
• WHY they are used

• Line-by-line WHY analysis
• Execution flow example

• Detailed WHY comments

undefined

• Core concept list (3 WHY questions each)
• Concept relationship matrix
• Connection to existing knowledge

• Multi-scenario execution flow
• Boundary condition explanation
• Error-prone point annotations

• Test file list and coverage analysis
• Boundary conditions discovered from tests
• Test-driven understanding verification

• Scenario 1: Invariant principles + modified parts + WHY
• Scenario 2: Invariant principles + modified parts + WHY
• Extract general patterns

• Detailed WHY comments

• Understanding depth verification
• Technical accuracy verification
• Practicality verification
• Final "Four Abilities" test

undefined

• Project/Code Name: [Project/Code Name]
• Programming Language: [Language]
• Code Scale: [Line count]
• Core Concepts: [Concept list from Main Agent]

1. Content Depth: This chapter must be at least [X] words
2. WHY Analysis: Each key point must answer 3 WHY questions
3. Code Comments: Use scenario/step + WHY style
4. Citation Sources: Provide authoritative reference links
5. Independence: Generate complete independent chapter content, no need to reference other chapters

• All sub-items are covered (no "brief" or "same as above")
• Each WHY has at least 2-3 sentences of explanation
• Code examples have complete comments
• Execution flow has specific data tracking

undefined

1. Read All Sub-Chapters

   chapter_1_background_and_motivation.md
   chapter_2_core_concepts.md
   chapter_3_algorithms_and_theory.md
   chapter_4_design_patterns.md
   chapter_5_code_analysis.md
   chapter_6_test_case_analysis.md (if applicable)
   chapter_7_application_transfer.md
   chapter_8_dependency_relationships.md
   chapter_9_quality_verification.md

2. Merge Order
   markdown

   # [Project/Code Name] Complete Mastery Analysis (Parallel Deep Version)
   
   ## Understanding Verification Status
   [Generated from Main Agent's preliminary analysis]
   
   [Insert chapter content in order]

3. Cross-Check
   • Core concepts are consistently defined across chapters
   • WHY explanations have no contradictions
   • Cited code examples are consistent
4. Depth Verification
   • Each chapter meets word count requirements
   • WHY analysis is sufficient
   • Execution examples are complete

undefined

• All sub-items of the chapter are covered (no "brief" or "same as above")
• Each WHY has specific explanations (not just one sentence)
• Code examples have complete comments (scenario/step + WHY)

• Each core concept has complete answers to 3 WHY questions
• Algorithms have complexity analysis + selection reasons
• Design patterns have WHY to use + consequences of not using
• Execution flow has specific data tracking

• Error-prone points are annotated
• Boundary conditions are explained
• At least 2 application transfer scenarios

**Implementation Method (Pseudocode Flow):**

// Generate chapter content (focus on one task at a time to ensure depth)
chapter_content = generate_deep_chapter(chapter, code)
// Requirement: Each chapter is at least 300-500 words, code snippets have complete comments

// Depth Self-Check
if not pass_depth_check(chapter_content):
  chapter_content = append_details(chapter_content)

// Update File
new_content = current_content.replace(chapter_placeholder, chapter_content)
write_file(file_path, new_content)

---

• Programming Language and version
• File/project scale
• Core Dependencies
• Code type (algorithm, business logic, framework code, etc.)

1. WHY: Why is this code needed?
   • What practical problem does it solve?
   • What would happen if this code didn't exist?
2. WHY: Why was this technical solution chosen?
   • What alternative solutions are there?
   • Why weren't other solutions chosen?
   • What are the trade-offs of this solution?
3. WHY: Why is it needed in this timing/scenario?
   • In what business process is it used?
   • What are the preconditions and postconditions?

undefined

• Advantages: [List 2-3 key advantages]
• Disadvantages: [List 1-2 known limitations]
• Trade-offs: [Explain what trade-offs were made]

• Solution A: [Brief description] - WHY not chosen: [Reason]
• Solution B: [Brief description] - WHY not chosen: [Reason]

1. Core Concept Extraction
   • Identify all key concepts (classes, functions, algorithms, data structures)
   • Each concept must answer 3 WHY questions
2. Concept Relationship Mapping
   • Dependency relationship: A depends on B - WHY?
   • Comparison relationship: A vs B - WHY choose A?
   • Combination relationship: A + B → C - WHY combine this way?
3. Knowledge Connection
   • Connect to known concepts
   • Connect to design patterns
   • Connect to theoretical foundations

undefined

• What it is: The process of verifying user identity
• WHY needed: Protect system resources from unauthorized access
• WHY implemented this way: Use JWT for stateless authentication to reduce server pressure
• WHY not use other methods: Session-based methods require server storage, which is not conducive to horizontal scaling

• What it is: Convert plaintext passwords into irreversible hash values
• WHY needed: Even if the database is compromised, attackers cannot obtain original passwords
• WHY use bcrypt: Built-in salt, adjustable computational cost to resist brute-force attacks
• WHY not use MD5/SHA1: Too fast to compute, vulnerable to brute-force attacks

• Connection to Design Patterns: [Detailed below]
• Connection to Algorithm Theory: [Detailed below]
• Connection to Security Principles: Least privilege principle, defense-in-depth principle

---

1. Mark time/space complexity
2. Explain "WHY this complexity is acceptable"
3. Provide authoritative reference materials
4. Explain scenarios where performance degrades

undefined

• Time Complexity: Average O(n log n), Worst O(n²)
• Space Complexity: O(log n)

• Excellent average performance, usually the fastest in practical applications
• In-place sorting, high space efficiency
• Cache-friendly, good access locality

• Worst-case scenario has very low probability (can be avoided through randomization)
• Actual data is usually not fully sorted/reverse sorted
• Can be optimized with Median-of-Three method

• Merge Sort: Requires O(n) additional space, not suitable for memory-constrained scenarios
• Heap Sort: Although stable O(n log n), poor cache performance, slower than Quick Sort in practice
• Insertion Sort: Excellent for small datasets, but O(n²) is not suitable for large-scale data

• Input is already sorted or reverse sorted (can be solved with randomization)
• Poor pivot selection (can be solved with Median-of-Three)
• Large number of duplicate elements (can be optimized with three-way Quick Sort)

• Quick Sort - Wikipedia
• Quick Sort Analysis - Princeton
• Why is QuickSort better than MergeSort?

• Stateless authentication, no need for server to store Sessions
• Self-contained, Token carries all necessary information
• Cross-domain friendly, suitable for microservice architecture

• Uses signature to verify integrity
• Cannot be forged (unless private key is leaked)
• Can set expiration time (exp)

• Cannot be invalidated proactively (unless maintaining a blacklist, which undermines stateless advantage)
• Token size is relatively large (Base64 encoding increases size by about 33%)
• Sensitive information needs encryption, signature alone does not provide confidentiality

• JWT.io - Introduction
• RFC 7519 - JWT Specification

---

1. Clearly mark the pattern name
2. Explain WHY this pattern is used
3. Explain what would happen if this pattern was not used
4. Provide standard references

undefined

DatabaseConnection

• Database connections have high overhead, reusing a single instance saves resources
• Avoids connection pool chaos, unified connection lifecycle management
• Global unique access point, easy to control concurrency

• Creating new connections for each operation leads to resource exhaustion
• Multiple connection instances may cause transaction inconsistencies
• Difficult to control concurrent access

class DatabaseConnection:
    _instance = None
    
    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
            # WHY initialize in __new__:
            # Ensure singleton before object creation, thread-safe
        return cls._instance

• Use

  __new__

  instead of

  __init__

  : Control instance creation, not initialization
• Class variable

  _instance

  : Stores the unique instance
• Lazy Loading: Only creates instance when first used

• ⚠️ Not thread-safe (needs locking in multi-threaded environments)
• ⚠️ Difficult unit testing (global state is hard to isolate)
• ⚠️ Violates single responsibility principle (class manages its own instance)

• Dependency Injection: More flexible, easier to test
• Module-level variables: Python modules are naturally singletons

• Singleton Pattern - Refactoring Guru
• Singleton Pattern in Python - Real Python

---

• Select 3-5 most critical code snippets
• Each line of code must explain "what it does" + "WHY it's done this way"
• Provide execution flow examples with specific data
• Annotate error-prone points and boundary conditions

undefined

def authenticate_user(username, password):
    user = db.find_user(username)
    if not user:
        return None
    if verify_password(password, user.password_hash):
        return generate_token(user.id)
    return None

Comment Style Explanation:

• # Scenario N: [Description]

  /

  // Scenario N: [Description]

  - Mark different execution paths for conditional branches (if/else, switch, match, etc.)

• # Step N: [Description]

  /

  // Step N: [Description]

  - Mark serial execution flows (initialization order, function call sequence, etc.)
• Comment symbols match the language: Use

  #

  for Python,

  //

  for C++/Java
• Track execution flow with specific variable values (

  # Current state: xxx

  /

  // Current state: xxx

  )
• Note iteration status of loops/recursion
• Mark change trajectories of key data

def authenticate_user(username, password):
    # Step 1: Query user
    user = db.find_user(username)
    # WHY query user first: Avoid password hashing for non-existent usernames (save computation)

    # Scenario 1: If user does not exist, immediately return None
    if not user:
        return None
        # WHY return None instead of throwing exception: Authentication failure is a normal business process, not an exception
        # WHY not distinguish between "user does not exist" and "wrong password": Prevent username enumeration attacks

    # Scenario 2: If password verification passes, generate and return Token
    if verify_password(password, user.password_hash):
        # verify_password internal flow:
        #   1. Extract salt from password_hash
        #   2. Hash plaintext password with the same salt
        #   3. Constant-time comparison of two hash values (prevent timing attacks)
        return generate_token(user.id)
        # Current state: user.id = 42 (example)
        # generate_token(42) → "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

    # Scenario 3: Wrong password, return None
    return None
    # WHY same return value as "user does not exist": Prevent attackers from distinguishing between the two failure cases

// Example: Trace function that produces tensors (typical compiler code style)

Value getProducerOfTensor(Value tensor) {
  Value opResult;

  while (true) {
    // Scenario 1: If tensor is defined by LinalgOp, return directly
    if (auto linalgOp = tensor.getDefiningOp<LinalgOp>()) {
      opResult = cast<OpResult>(tensor);
      // while loop runs only once
      return;
    }

    // According to this section's example, first call to this function: tensor = %2_tile
    // Scenario 2: If tensor is linked via ExtractSliceOp, continue tracing source
    if (auto sliceOp = tensor.getDefiningOp<tensor::ExtractSliceOp>()) {
      tensor = sliceOp.getSource();
      // Current state: tensor = %2, defined by linalg.matmul
      // Execute second while loop, will enter Scenario 1 branch (linalg.matmul is LinalgOp)
      continue;
    }

    // Scenario 3: Via scf.for iteration parameter
    // Example IR:
    // %1 = linalg.generic ins(%A) outs(%init) { ... }
    // %2 = scf.for %i = 0 to 10 iter_args(%arg = %1) {
    //   %3 = linalg.generic ins(%arg) outs(%init2) { ... }
    //   scf.yield %3
    // }
    // getProducerOfTensor(%arg)
    if (auto blockArg = dyn_cast<BlockArgument>(tensor)) {
      // First while loop: tensor = %arg, which is BlockArgument
      if (auto forOp = blockArg.getDefiningOp<scf::ForOp>()) {
        // %arg is defined by scf.for, get loop's initial value: %1
        // blockArg.getArgNumber() = 0 (%arg is the 0th iteration parameter)
        // forOp.getInitArgs()[0] = %1
        tensor = forOp.getInitArgs()[blockArg.getArgNumber()];
        // Current state: tensor = %1, defined by linalg.generic
        // Execute second while loop, will enter Scenario 1 branch
        continue;
      }
    }

    return;  // Not found (may be function parameter)
  }
}

undefined

Current state: user exists, skip return None in Scenario 1

Final return: Token string

Current state: user = None, enter Scenario 1 branch

Scenarios 2 and 3 are not executed

Current state: user exists, skip return None in Scenario 1

Scenario 3: Password verification fails, return None

• Test cases reflect the expected behavior of the code, making them the most accurate "user manual"
• Tests usually cover boundary conditions and exception scenarios, which are easily overlooked in the main code
• Tests can verify if understanding is correct, avoiding false assumptions

// Test: generic region must have exactly one block
func.func @invalid_generic_empty_region(%arg0: tensor<10xf32>) -> tensor<10xf32> {
  %0 = linalg.generic {indexing_maps = [affine_map<(d0) -> (d0)>],
                     iterator_types = ["parallel"]}
    outs(%arg0) {
    // Empty region - should report error
  } -> tensor<10xf32>
  return %0 : tensor<10xf32>
}

• Reveals structural constraints of

  linalg.generic

  : Must have a block
• Clearly defines error conditions through negative testing (invalid test)
• Boundary condition: Number of region blocks must = 1

// Test: Number of inputs and outputs must match indexing_maps
func.func @generic_mismatched_maps(%a: tensor<10xf32>, %b: tensor<10xf32>) -> tensor<10xf32> {
  %0 = linalg.generic {
    indexing_maps = [
      affine_map<(d0) -> (d0)>,  // Map for 1 input
      affine_map<(d0) -> (d0)>   // Map for 1 output
    ],
    iterator_types = ["parallel"]
  } ins(%a, %b : tensor<10xf32>, tensor<10xf32>)  // But there are 2 inputs
  outs(%0 : tensor<10xf32>) {
  ^bb0(%in: f32, %in_2: f32, %out: f32):
    linalg.yield %in : f32
  } -> tensor<10xf32>
  return %0 : tensor<10xf32>
}

• Verifies type system constraints: Number of inputs/outputs must match maps
• Tests static verification logic, catches errors at compile time
• Illustrates MLIR's static strong typing feature

// Test: Concurrent insertion of the same key
TEST(ConcurrentMapTest, ConcurrentInsertSameKey) {
  ConcurrentMap<int, int> map;
  const int num_threads = 10;
  const int key = 42;

  std::vector<std::thread> threads;
  for (int i = 0; i < num_threads; ++i) {
    threads.emplace_back([&map, key, i]() {
      map.Insert(key, i);  // All threads insert the same key
    });
  }

  for (auto& t : threads) t.join();

  // Verify: Only one insertion succeeds
  EXPECT_EQ(map.Size(), 1);
  EXPECT_TRUE(map.Contains(key));
}

• Verifies thread safety: Multi-threaded concurrent access does not cause crashes
• Illustrates conflict handling strategy: Later insertions overwrite earlier ones (or vice versa)
• Tests consistency guarantees: Final state meets expectations

undefined

linalg.tile

decomposes linalg operations into smaller fragments

1. How is tile size determined?
2. Which operations support tiling?
3. What is the loop order after tiling?
4. How to handle remaining elements?

• Look for

  test_*.py

  or

  *_test.py

• Pay attention to

  @pytest.mark.parametrize

  parameterized tests
• Focus on

  pytest.raises

  exception tests
• Look for fixtures (

  conftest.py

  ) to understand test context

• Look for

  *_test.cpp

  or

  test/*.cpp

• TEST_F

  indicates fixture tests with preconditions

• EXPECT_*

  vs

  ASSERT_*

  : Whether to continue after failure

• TEST_P

  indicates parameterized tests

• Test files are usually

  .mlir

  or

  .td

• RUN:

  commands specify how to execute tests

• // EXPECTED:

  marks expected output

• // ERROR:

  marks expected compilation errors
• FileCheck directives:

  CHECK-

  ,

  CHECK-NOT:

  ,

  CHECK-DAG:

• *.test.ts

  ,

  *.spec.ts

• describe/it

  nested structure

• expect(...).toThrow()

  exception tests

• beforeEach/afterEach

  hook functions

• Tests are in the same directory as source code:

  *_test.go

• TestXxx(t *testing.T)

  basic tests

• TableDrivenTests

  table-driven tests

• TestMain

  test entry point

• *_test.rs

  inline tests

• tests/

  directory integration tests

• #[should_panic]

  exception tests

• #[ignore]

  skipped tests

undefined

• ✅ Normal flow
• ✅ Boundary inputs
• ✅ Exception inputs
• ⚠️ Concurrent scenarios
• ❌ Performance tests

• ✅ Positive tests (valid.mlir)
• ✅ Negative tests (invalid.mlir)
• ⚠️ Performance regression tests
• ❌ Cross-dialect interaction tests

⚠️ Warning: This module has insufficient test coverage

• Uncovered scenarios: [List specifically]
• Recommended supplements: [Specific suggestions]

undefined

• Core function coverage: X%
• Boundary condition coverage: [Sufficient/Insufficient]

• At least 2 application scenarios in different domains
• Explain how to adjust code to adapt to new scenarios
• Mark which principles remain unchanged and which need modification

undefined

• Core process of verifying "who is calling"
• Hash-stored credentials (API keys should also be hashed)
• Access token generation mechanism

undefined

• Divide and conquer idea: Recursively decompose problems
• Pivot selection: Key factor affecting performance
• In-place sorting: Saves space

undefined

• Purpose: Password Hashing
• WHY Choose bcrypt:
  • Built-in salt, no manual management needed
  • Adjustable computational cost (cost factor)
  • Resists GPU/ASIC accelerated attacks
• WHY Not Use SHA256: Too fast to compute, vulnerable to brute-force attacks
• WHY Not Use scrypt/argon2: bcrypt is more mature and has better compatibility

• Purpose: JWT token generation and verification
• WHY Choose JWT: Stateless authentication, suitable for distributed systems
• WHY Not Use Session: Session requires server storage, not conducive to scaling

• Dependency Reason: Authentication requires querying user data
• WHY This Design: Separate data access and business logic (single responsibility principle)

• Dependency Reason: Authentication requires password hashing and verification
• WHY Encapsulate into Utility Module: Encryption logic is complex, centralized management is more secure

• Each core concept answers 3 WHY questions
  • WHY this concept is needed
  • WHY it's implemented this way
  • WHY other methods are not used
• Self-explanation test passed
  • Can explain each core concept without looking at code
  • Can explain "why" instead of just "what"
  • Can apply it in different scenarios (transfer test)
• Concept connections established
  • Marked dependency/comparison/combination relationships between concepts
  • Connected to existing knowledge (design patterns, algorithm theory)
  • Explained reasons for each connection (WHY)

• Algorithm analysis complete
  • Time/space complexity marked
  • WHY this algorithm was chosen
  • WHY complexity is acceptable
  • Provided authoritative reference materials
• Design pattern identification
  • All patterns are marked
  • WHY this pattern is used
  • What would happen if not used
  • Provided standard references
• Code analysis detailed
  • Key code snippets have line-by-line analysis
  • Each line includes "what it does" + "WHY it's done this way"
  • Provided execution examples with specific data
  • Annotated error-prone points and boundary conditions

• Application transfer test
  • At least 2 transfer examples in different scenarios
  • Explained what remains unchanged and what needs to be changed
  • Extracted general patterns
• Usage examples are runnable
  • Example code is complete
  • Includes detailed WHY comments
  • Explained execution results
• Issues and improvement suggestions
  • Pointed out potential issues
  • WHY it's an issue
  • Provided improvement solutions
  • WHY the improvement solution is better

1. ✅ Can you understand the code's design ideas?
2. ✅ Can you implement similar functions independently?
3. ✅ Can you apply it to different scenarios?
4. ✅ Can you explain it clearly to others?

---

• Programming language:
• Code scale:
• Core dependencies:

• Problem essence (WHY needed)
• Solution selection (WHY chosen + WHY other solutions not chosen)
• Application scenarios (WHY applicable + WHY not applicable)

• Core concept list (3 WHY questions per concept)
• Concept relationship matrix
• Connection to existing knowledge

• Each algorithm: Complexity + WHY chosen + WHY acceptable + reference materials
• Each theory: WHY used + WHY effective + WHY limited

• Each pattern: WHY used + WHY not used + implementation details + reference materials

• Each code snippet: Line-by-line analysis (what it does + WHY) + execution examples + key takeaways

• Test file list and coverage analysis
• Boundary conditions discovered from tests
• Test-driven understanding verification

• Each scenario: Invariant principles + modified parts + WHY transferred this way

• Each dependency: WHY chosen + WHY other solutions not chosen
• Examples include detailed WHY comments

1. Overall Architecture Analysis
   • Project structure tree + WHY organized this way
   • Entry file + WHY start here
   • Module division + WHY divided this way
2. Inter-Module Relationships
   • Dependency graph + WHY dependent this way
   • Data flow graph + WHY flows this way
   • Call chain + WHY called this way
3. Module-by-Module Analysis
   • Analyze each core module according to standard process
   • Emphasize WHY relationships between modules

1. Layered Explanation
   • First describe ideas in natural language
   • Then show structure with pseudocode
   • Finally analyze implementation line by line
2. WHY Throughout
   • WHY this algorithm was chosen
   • WHY each step is done this way
   • WHY complexity is as such
3. Visualization Assistance
   • Show execution process with specific data
   • Explain WHY at each step

1. Technology Background Explanation
   • What this technology stack is
   • WHY this technology stack exists
   • WHY the project chose it
2. Key Concept Explanation
   • Concepts unique to this technology stack
   • WHY designed this way
   • Comparison with other technology stacks
3. Learning Resources
   • Official documentation links
   • WHY recommend these resources
   • Learning path suggestions

• Understood user's real needs (learning? review? interview preparation?)
• Identified code language, framework, scale
• Determined analysis focus (comprehensive understanding vs specific aspects)
• Ready to ask "WHY" at any time
• Ready to conduct self-explanation tests
• Ready to find concept connections
• Ready to think about application transfer

1. Prohibit outputting complete analysis in conversation
   • Complete analysis is written directly to file, not output to conversation
   • Only output analysis summary + file path in conversation
2. Chunk processing for large projects
   • Single-file analysis: Generate single document
   • Multi-file project: Generate multiple documents by module
   • Ultra-long analysis: Split into

     overview.md

     +

     module-name-detailed-analysis.md

3. Progressive Generation (for Deep Mode)
   • First generate framework document (table of contents + overview)
   • Fill content section by section, use Write to append updates each time

1. File Naming Format
   • Single file:

     [code-name]-deep-analysis.md

     or

     [代码名称]-深度分析.md

   • Multi-file project:

     [project-name]-overview.md

     +

     [module-name]-analysis.md

   • Examples:

     jwt-authentication-deep-analysis.md

     ,

     quicksort-deep-analysis.md

2. Generation Method (Token-Optimized Flow)
   Method 1: Direct Write (Recommended)

   User: Conduct in-depth analysis of this code
   
   1. [Complete analysis process, do not output complete content]
   
   2. Use Write tool directly to generate document:
      File path: [code-name]-deep-analysis.md
      Content: [Complete analysis content]
   
   3. Output brief summary in conversation:
      - Mode: Standard/Deep
      - Key findings: 3-5 key points
      - File path: [code-name]-deep-analysis.md

   Method 2: Chunk Generation for Multi-File Projects

   1. [Complete overall analysis]
   
   2. Generate overview document:
      Write: [project-name]-overview.md
      Content: Overall architecture, module relationship diagram, analysis framework
   
   3. Generate detailed documents by module:
      Write: [moduleA]-analysis.md
      Write: [moduleB]-analysis.md
      Write: [moduleC]-analysis.md
   
   4. Output summary:
      - Generated 4 documents
      - List all file paths

   Method 3: Deep Mode (Automatically select strategy based on code scale)

   Deep Mode automatically selects optimal strategy based on code scale.
   
   [Strategy A: Progressive Generation] When code ≤ 2000 lines
   - First generate framework document (table of contents + overview)
   - Fill content section by section, use Write to append updates each time
   - Refer to "Deep Mode Output Structure - Strategy A" section above
   
   [Strategy B: Parallel Processing] When code > 2000 lines
   1. Main Agent generates framework and task allocation
   2. Use Task tool to create multiple parallel sub-Agents
   3. Each sub-Agent focuses on one chapter, generates independent file
   4. Main Agent aggregates all chapters, generates final document
   
   File structure:
   work/
   ├── 00-framework.json           # Framework generated by Main Agent
   ├── tasks/                 # Sub-task description directory
   ├── chapters/              # Chapters generated by sub-Agents
   └── [project-name]-complete-mastery-analysis.md  # Final aggregated document
   
   Example Task call:
   Task(
     description: "In-depth analysis of [chapter-name] chapter",
     prompt: "You are a [chapter-name] analysis expert, please conduct in-depth analysis...[specific instructions]",
     subagent_type: "general-purpose"
   )

3. Conversation Output Format (Simplified Version)
   markdown

   ## Analysis Completed
   
   **Mode:** Standard Mode
   
   **Key Findings:**
   - Code implements [core function]
   - Uses [algorithm/pattern] to solve [problem]
   - Key optimization points: [optimization point1], [optimization point2]
   - Potential issues: [issue1], [issue2]
   
   **Complete Document:** `[code-name]-deep-analysis.md`