Claude-Code-Workflow/.claude/workflows/cli-templates/prompts/memory/claude-module-unified.txt

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

## Unified Module Documentation Requirements

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

### Content Focus (MUST INCLUDE):

#### 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/Modules**:
- Directory organization and file structure
- Sub-module categorization
- Architectural layout

**For Code Files**:
- File organization (imports, exports, structure)
- Core classes and their hierarchy
- Main functions and their grouping

#### 3. Key Components
**For Folders/Modules**:
- Sub-modules and their responsibilities
- Major components and their interactions
- Entry points and public interfaces

**For Code Files**:
- Core classes with brief descriptions
- Key methods/functions with complete signatures and parameter details
  - Method name and purpose
  - **Parameters**: name, type, description, default values (if any)
  - **Return value**: type and description
  - **Throws**: exceptions or errors (if applicable)
- Important interfaces/types
- Exported APIs with usage examples

#### 4. Dependencies
- **Internal Dependencies**: Other modules/files within the project
  - What it imports/requires
  - Dependency relationships and flow
- **External Dependencies**: Third-party libraries and frameworks
  - Critical dependencies and their purposes
  - Version constraints if important

#### 5. Integration Points
- How this module/file 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

### Documentation Style Guidelines:
- Be concise but complete
- Use clear, descriptive language
- Include code signatures for key APIs
- **For method parameters**:
  - Always document each parameter with name, type, and description
  - Indicate optional parameters with `[optional]`
  - Show default values with `[default: value]`
  - Include parameter constraints if applicable (e.g., range, format)
- **For return values**:
  - Specify return type clearly
  - Describe what the returned value represents
  - Document special return conditions (null, undefined, empty, etc.)
- Focus on "what" and "why", not detailed "how"
- Reference related documentation when appropriate
- Use bullet points for readability
- Provide usage examples for complex methods

### 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 1]
- Description: [Brief description]
- Responsibilities: [What it does]
- Key Methods:

  #### `methodName(param1: Type1, param2: Type2, ...): ReturnType`
  - **Purpose**: [What this method does]
  - **Parameters**:
    - `param1` (Type1): [Description of param1] [default: value]
    - `param2` (Type2): [Description of param2] [optional]
  - **Returns**: (ReturnType) [Description of return value]
  - **Throws**: [Exception types and conditions]
  - **Example**:
    ```
    const result = instance.methodName(value1, value2);
    ```

### [Component/Class Name 2]
...

## 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]

### Extension Points
[How this can be extended or customized]

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

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

### Configuration
- [Config item]: [Purpose and default]

### Considerations
- Performance: [Any performance notes]
- Security: [Any security considerations]
- Limitations: [Known limitations]
```

### Content Restrictions (STRICTLY AVOID):
- Don't duplicate content from other CLAUDE.md files - reference them instead
- Avoid overly detailed code explanations (code should be self-documenting)
- Don't include complete code listings (use signatures and descriptions)
- Avoid version-specific implementation details unless critical
- Don't document every single function - focus on key components
- **BUT DO document**: All public/exported APIs with complete parameter details
- **Internal/private methods**: Only document if they are complex or critical to understanding

### Special Instructions:
- If analyzing a folder with existing CLAUDE.md files in subdirectories, reference them rather than duplicating their content
- For code files, prioritize exported/public APIs over internal implementation details
- **For method documentation**:
  - MUST document all parameters for public/exported methods
  - Include parameter types, descriptions, and constraints
  - Document return values and exceptions
  - Add usage examples for non-trivial methods
  - Private/internal methods: document only if complex or critical
- Keep dependency lists focused on direct dependencies, not transitive ones
- Update existing CLAUDE.md files rather than creating new sections unnecessarily

Remember: This template serves both folder-level module documentation and file-level implementation documentation. Adapt the sections based on what you're documenting.