Create or update CLAUDE.md documentation using unified module/file template.

## ⚠️ FILE NAMING RULE (CRITICAL)
- Target file: MUST be named exactly `CLAUDE.md` in the current directory
- NEVER create files like `ToolSidebar.CLAUDE.md` or `[filename].CLAUDE.md`
- ALWAYS use the fixed name: `CLAUDE.md`

## CORE CHECKLIST ⚡
□ MUST create/update file named exactly 'CLAUDE.md' (not variants)
□ MUST include all 6 sections: Purpose, Structure, Components, Dependencies, Integration, Implementation
□ For code files: Document all public/exported APIs with complete parameter details
□ For folders: Reference subdirectory CLAUDE.md files instead of duplicating
□ Provide method signatures with parameter types, descriptions, defaults, and return values
□ Distinguish internal dependencies from external libraries
□ Apply RULES template requirements exactly as specified

## DOCUMENTATION REQUIREMENTS

### Analysis Strategy
- **Folders/Modules**: Analyze directory structure, sub-modules, and architectural patterns
- **Code Files**: Analyze classes, functions, interfaces, and implementation details

### Required Sections (ALL 6 MUST BE INCLUDED)

#### 1. Purpose and Scope
- Clear description of what this module/file does
- Main responsibilities and boundaries
- Role within the larger system

#### 2. Structure Overview
**For Folders**: Directory organization, sub-module categorization, architectural layout
**For Code Files**: File organization (imports, exports), class hierarchy, function grouping

#### 3. Key Components
**For Folders**: Sub-modules, major components, entry points, public interfaces
**For Code Files**:
- Core classes with descriptions and responsibilities
- Key methods with complete signatures:
  ```
  methodName(param1: Type1, param2: Type2): ReturnType
  - Purpose: [what it does]
  - Parameters:
    • param1 (Type1): [description] [default: value]
    • param2 (Type2): [description] [optional]
  - Returns: (ReturnType) [description]
  - Throws: [exception types and conditions]
  - Example: [usage example for complex methods]
  ```
- Important interfaces/types
- Exported APIs

#### 4. Dependencies
**Internal Dependencies**: Other modules/files within project (with purpose)
**External Dependencies**: Third-party libraries and frameworks (with purpose, version constraints if critical)

#### 5. Integration Points
- How this connects to other parts
- Public APIs or interfaces exposed
- Data flow patterns (input → processing → output)
- Event handling or callbacks
- Extension points for customization

#### 6. Implementation Notes
- Key design patterns used (e.g., Singleton, Factory, Observer)
- Important technical decisions and rationale
- Configuration requirements or environment variables
- Performance considerations
- Security considerations if applicable
- Known limitations or caveats

## OUTPUT REQUIREMENTS

### File Naming (CRITICAL)
- **Output file**: MUST be named exactly `CLAUDE.md` in the current directory
- **Examples of WRONG naming**: `ToolSidebar.CLAUDE.md`, `index.CLAUDE.md`, `utils.CLAUDE.md`
- **Correct naming**: `CLAUDE.md` (always, for all directories)

### Template Structure
```markdown
# [Module/File Name]

## Purpose and Scope
[Clear description of responsibilities and role]

## Structure Overview
[Directory structure for modules OR File organization for code files]

## Key Components
### [Component/Class Name]
- Description: [Brief description]
- Responsibilities: [What it does]
- Key Methods:
  #### `methodName(param1: Type1, param2?: Type2): ReturnType`
  - Purpose: [what this method does]
  - Parameters:
    • param1 (Type1): [description]
    • param2 (Type2): [description] [optional] [default: value]
  - Returns: (ReturnType) [description]
  - Throws: [exceptions if applicable]

## Dependencies
### Internal Dependencies
- `[module/file path]` - [purpose]

### External Dependencies
- `[library name]` - [purpose and usage]

## Integration Points
### Public APIs
- `[API/function signature]` - [description]

### Data Flow
[How data flows through this module/file]

## Implementation Notes
### Design Patterns
- [Pattern name]: [Usage and rationale]

### Technical Decisions
- [Decision]: [Rationale]

### Considerations
- Performance: [notes]
- Security: [notes]
- Limitations: [notes]
```

### Documentation Style
- **Concise but complete** - Focus on "what" and "why", not detailed "how"
- **Code signatures** for key APIs - Include all parameter details
- **Parameters**: Name, type, description, optional/default indicators, constraints
- **Return values**: Type, description, special conditions (null, undefined, empty)
- **Evidence-based** - Reference related documentation when appropriate
- **Examples** for complex methods - Show usage patterns

### Content Restrictions (STRICTLY AVOID)
- ❌ Duplicating content from other CLAUDE.md files (reference instead)
- ❌ Overly detailed code explanations (code should be self-documenting)
- ❌ Complete code listings (use signatures and descriptions)
- ❌ Version-specific details unless critical
- ❌ Documenting every single function (focus on public/exported APIs)

### Method Documentation Rules
- **Public/Exported methods**: MUST document with full parameter details
- **Private/Internal methods**: Only document if complex or critical
- **Parameters**: MUST include type, description, constraints, defaults
- **Return values**: MUST document type and description
- **Exceptions**: Document all thrown errors

### Special Instructions
- If analyzing folder with existing subdirectory CLAUDE.md files → reference them
- For code files → prioritize exported/public APIs
- Keep dependency lists focused on direct dependencies (not transitive)
- Update existing CLAUDE.md files rather than creating duplicate sections

## VERIFICATION CHECKLIST ✓
□ Output file is named exactly 'CLAUDE.md' (not [filename].CLAUDE.md)
□ All 6 required sections included (Purpose, Structure, Components, Dependencies, Integration, Implementation)
□ All public/exported APIs documented with complete signatures
□ Parameters documented with types, descriptions, and defaults
□ References used instead of duplicating subdirectory documentation
□ Internal vs external dependencies clearly distinguished
□ Examples provided for non-trivial methods

Focus: Comprehensive yet concise documentation covering all essential aspects without redundancy.