Generate Standard OO Component Documentation

Create comprehensive documentation for the object-oriented component(s) at: ${input:ComponentPath}.

Analyze the component by examining code in the provided path. If folder, analyze all source files. If single file, treat as main component and analyze related files in same directory.

Documentation Standards

• DOC-001: Follow C4 Model documentation levels (Context, Containers, Components, Code)
• DOC-002: Align with Arc42 software architecture documentation template
• DOC-003: Comply with IEEE 1016 Software Design Description standard
• DOC-004: Use Agile Documentation principles (just enough documentation that adds value)
• DOC-005: Target developers and maintainers as primary audience

Analysis Instructions

• ANA-001: Determine path type (folder vs single file) and identify primary component
• ANA-002: Examine source code files for class structures and inheritance
• ANA-003: Identify design patterns and architectural decisions
• ANA-004: Document public APIs, interfaces, and dependencies
• ANA-005: Recognize creational/structural/behavioral patterns
• ANA-006: Document method parameters, return values, exceptions
• ANA-007: Assess performance, security, reliability, maintainability
• ANA-008: Infer integration patterns and data flow

Language-Specific Optimizations

• LNG-001: C#/.NET - async/await, dependency injection, configuration, disposal
• LNG-002: Java - Spring framework, annotations, exception handling, packaging
• LNG-003: TypeScript/JavaScript - modules, async patterns, types, npm
• LNG-004: Python - packages, virtual environments, type hints, testing

Error Handling

• ERR-001: Path doesn't exist - provide correct format guidance
• ERR-002: No source files found - suggest alternative locations
• ERR-003: Unclear structure - document findings and request clarification
• ERR-004: Non-standard patterns - document custom approaches
• ERR-005: Insufficient code - focus on available information, highlight gaps

Output Format

Generate well-structured Markdown with clear heading hierarchy, code blocks, tables, bullet points, and proper formatting for readability and maintainability.

File Location

The documentation should be saved in the /docs/components/ directory and named according to the convention: [component-name]-documentation.md.

Required Documentation Structure

The documentation file must follow the template below, ensuring that all sections are filled out appropriately. The front matter for the markdown should be structured correctly as per the example following:

md
1---
2title: [Component Name] - Technical Documentation
3component_path: `${input:ComponentPath}`
4version: [Optional: e.g., 1.0, Date]
5date_created: [YYYY-MM-DD]
6last_updated: [Optional: YYYY-MM-DD]
7owner: [Optional: Team/Individual responsible for this component]
8tags: [Optional: List of relevant tags or categories, e.g., `component`,`service`,`tool`,`infrastructure`,`documentation`,`architecture` etc]
9---
10
11# [Component Name] Documentation
12
13[A short concise introduction to the component and its purpose within the system.]
14
15## 1. Component Overview
16
17### Purpose/Responsibility
18- OVR-001: State component's primary responsibility
19- OVR-002: Define scope (included/excluded functionality)
20- OVR-003: Describe system context and relationships
21
22## 2. Architecture Section
23
24- ARC-001: Document design patterns used (Repository, Factory, Observer, etc.)
25- ARC-002: List internal and external dependencies with purposes
26- ARC-003: Document component interactions and relationships
27- ARC-004: Include visual diagrams (UML class, sequence, component)
28- ARC-005: Create mermaid diagram showing component structure, relationships, and dependencies
29
30### Component Structure and Dependencies Diagram
31
32Include a comprehensive mermaid diagram that shows:
33- **Component structure** - Main classes, interfaces, and their relationships
34- **Internal dependencies** - How components interact within the system
35- **External dependencies** - External libraries, services, databases, APIs
36- **Data flow** - Direction of dependencies and interactions
37- **Inheritance/composition** - Class hierarchies and composition relationships
38
39```mermaid
40graph TD
41    subgraph "Component System"
42        A[Main Component] --> B[Internal Service]
43        A --> C[Internal Repository]
44        B --> D[Business Logic]
45        C --> E[Data Access Layer]
46    end
47
48    subgraph "External Dependencies"
49        F[External API]
50        G[Database]
51        H[Third-party Library]
52        I[Configuration Service]
53    end
54
55    A --> F
56    E --> G
57    B --> H
58    A --> I
59
60    classDiagram
61        class MainComponent {
62            +property: Type
63            +method(): ReturnType
64            +asyncMethod(): Promise~Type~
65        }
66        class InternalService {
67            +businessOperation(): Result
68        }
69        class ExternalAPI {
70            <<external>>
71            +apiCall(): Data
72        }
73
74        MainComponent --> InternalService
75        MainComponent --> ExternalAPI

3. Interface Documentation

• INT-001: Document all public interfaces and usage patterns
• INT-002: Create method/property reference table
• INT-003: Document events/callbacks/notification mechanisms

4. Implementation Details

• IMP-001: Document main implementation classes and responsibilities
• IMP-002: Describe configuration requirements and initialization
• IMP-003: Document key algorithms and business logic
• IMP-004: Note performance characteristics and bottlenecks

5. Usage Examples

Basic Usage

csharp
1// Basic usage example
2var component = new ComponentName();
3component.DoSomething();

Advanced Usage

csharp
1// Advanced configuration patterns
2var options = new ComponentOptions();
3var component = ComponentFactory.Create(options);
4await component.ProcessAsync(data);

• USE-001: Provide basic usage examples
• USE-002: Show advanced configuration patterns
• USE-003: Document best practices and recommended patterns

6. Quality Attributes

• QUA-001: Security (authentication, authorization, data protection)
• QUA-002: Performance (characteristics, scalability, resource usage)
• QUA-003: Reliability (error handling, fault tolerance, recovery)
• QUA-004: Maintainability (standards, testing, documentation)
• QUA-005: Extensibility (extension points, customization options)

7. Reference Information

• REF-001: List dependencies with versions and purposes
• REF-002: Complete configuration options reference
• REF-003: Testing guidelines and mock setup
• REF-004: Troubleshooting (common issues, error messages)
• REF-005: Related documentation links
• REF-006: Change history and migration notes