@mark-gozner/aigile-method 0.4.5

package/core/prompts/copilot-instructions-blueprint-generator.prompt.md

@@ -0,0 +1,294 @@
+---
+description: 'Technology-agnostic blueprint generator for creating comprehensive copilot-instructions.md files that guide GitHub Copilot to produce code consistent with project standards, architecture patterns, and exact technology versions by analyzing existing codebase patterns and avoiding assumptions.'
+mode: 'agent'
+---
+
+# Copilot Instructions Blueprint Generator
+
+## Configuration Variables
+${PROJECT_TYPE="Auto-detect|.NET|Java|JavaScript|TypeScript|React|Angular|Python|Multiple|Other"} <!-- Primary technology -->
+${ARCHITECTURE_STYLE="Layered|Microservices|Monolithic|Domain-Driven|Event-Driven|Serverless|Mixed"} <!-- Architectural approach -->
+${CODE_QUALITY_FOCUS="Maintainability|Performance|Security|Accessibility|Testability|All"} <!-- Quality priorities -->
+${DOCUMENTATION_LEVEL="Minimal|Standard|Comprehensive"} <!-- Documentation requirements -->
+${TESTING_REQUIREMENTS="Unit|Integration|E2E|TDD|BDD|All"} <!-- Testing approach -->
+${VERSIONING="Semantic|CalVer|Custom"} <!-- Versioning approach -->
+
+## Generated Prompt
+
+"Generate a comprehensive copilot-instructions.md file that will guide GitHub Copilot to produce code consistent with our project's standards, architecture, and technology versions. The instructions must be strictly based on actual code patterns in our codebase and avoid making any assumptions. Follow this approach:
+
+### 1. Core Instruction Structure
+
+```markdown
+# GitHub Copilot Instructions
+
+## Priority Guidelines
+
+When generating code for this repository:
+
+1. **Version Compatibility**: Always detect and respect the exact versions of languages, frameworks, and libraries used in this project
+2. **Context Files**: Prioritize patterns and standards defined in the .github/copilot directory
+3. **Codebase Patterns**: When context files don't provide specific guidance, scan the codebase for established patterns
+4. **Architectural Consistency**: Maintain our ${ARCHITECTURE_STYLE} architectural style and established boundaries
+5. **Code Quality**: Prioritize ${CODE_QUALITY_FOCUS == "All" ? "maintainability, performance, security, accessibility, and testability" : CODE_QUALITY_FOCUS} in all generated code
+
+## Technology Version Detection
+
+Before generating code, scan the codebase to identify:
+
+1. **Language Versions**: Detect the exact versions of programming languages in use
+   - Examine project files, configuration files, and package managers
+   - Look for language-specific version indicators (e.g., <LangVersion> in .NET projects)
+   - Never use language features beyond the detected version
+
+2. **Framework Versions**: Identify the exact versions of all frameworks
+   - Check package.json, .csproj, pom.xml, requirements.txt, etc.
+   - Respect version constraints when generating code
+   - Never suggest features not available in the detected framework versions
+
+3. **Library Versions**: Note the exact versions of key libraries and dependencies
+   - Generate code compatible with these specific versions
+   - Never use APIs or features not available in the detected versions
+
+## Context Files
+
+Prioritize the following files in .github/copilot directory (if they exist):
+
+- **architecture.md**: System architecture guidelines
+- **tech-stack.md**: Technology versions and framework details
+- **coding-standards.md**: Code style and formatting standards
+- **folder-structure.md**: Project organization guidelines
+- **exemplars.md**: Exemplary code patterns to follow
+
+## Codebase Scanning Instructions
+
+When context files don't provide specific guidance:
+
+1. Identify similar files to the one being modified or created
+2. Analyze patterns for:
+   - Naming conventions
+   - Code organization
+   - Error handling
+   - Logging approaches
+   - Documentation style
+   - Testing patterns
+   
+3. Follow the most consistent patterns found in the codebase
+4. When conflicting patterns exist, prioritize patterns in newer files or files with higher test coverage
+5. Never introduce patterns not found in the existing codebase
+
+## Code Quality Standards
+
+${CODE_QUALITY_FOCUS.includes("Maintainability") || CODE_QUALITY_FOCUS == "All" ? `### Maintainability
+- Write self-documenting code with clear naming
+- Follow the naming and organization conventions evident in the codebase
+- Follow established patterns for consistency
+- Keep functions focused on single responsibilities
+- Limit function complexity and length to match existing patterns` : ""}
+
+${CODE_QUALITY_FOCUS.includes("Performance") || CODE_QUALITY_FOCUS == "All" ? `### Performance
+- Follow existing patterns for memory and resource management
+- Match existing patterns for handling computationally expensive operations
+- Follow established patterns for asynchronous operations
+- Apply caching consistently with existing patterns
+- Optimize according to patterns evident in the codebase` : ""}
+
+${CODE_QUALITY_FOCUS.includes("Security") || CODE_QUALITY_FOCUS == "All" ? `### Security
+- Follow existing patterns for input validation
+- Apply the same sanitization techniques used in the codebase
+- Use parameterized queries matching existing patterns
+- Follow established authentication and authorization patterns
+- Handle sensitive data according to existing patterns` : ""}
+
+${CODE_QUALITY_FOCUS.includes("Accessibility") || CODE_QUALITY_FOCUS == "All" ? `### Accessibility
+- Follow existing accessibility patterns in the codebase
+- Match ARIA attribute usage with existing components
+- Maintain keyboard navigation support consistent with existing code
+- Follow established patterns for color and contrast
+- Apply text alternative patterns consistent with the codebase` : ""}
+
+${CODE_QUALITY_FOCUS.includes("Testability") || CODE_QUALITY_FOCUS == "All" ? `### Testability
+- Follow established patterns for testable code
+- Match dependency injection approaches used in the codebase
+- Apply the same patterns for managing dependencies
+- Follow established mocking and test double patterns
+- Match the testing style used in existing tests` : ""}
+
+## Documentation Requirements
+
+${DOCUMENTATION_LEVEL == "Minimal" ? 
+`- Match the level and style of comments found in existing code
+- Document according to patterns observed in the codebase
+- Follow existing patterns for documenting non-obvious behavior
+- Use the same format for parameter descriptions as existing code` : ""}
+
+${DOCUMENTATION_LEVEL == "Standard" ? 
+`- Follow the exact documentation format found in the codebase
+- Match the XML/JSDoc style and completeness of existing comments
+- Document parameters, returns, and exceptions in the same style
+- Follow existing patterns for usage examples
+- Match class-level documentation style and content` : ""}
+
+${DOCUMENTATION_LEVEL == "Comprehensive" ? 
+`- Follow the most detailed documentation patterns found in the codebase
+- Match the style and completeness of the best-documented code
+- Document exactly as the most thoroughly documented files do
+- Follow existing patterns for linking documentation
+- Match the level of detail in explanations of design decisions` : ""}
+
+## Testing Approach
+
+${TESTING_REQUIREMENTS.includes("Unit") || TESTING_REQUIREMENTS == "All" ? 
+`### Unit Testing
+- Match the exact structure and style of existing unit tests
+- Follow the same naming conventions for test classes and methods
+- Use the same assertion patterns found in existing tests
+- Apply the same mocking approach used in the codebase
+- Follow existing patterns for test isolation` : ""}
+
+${TESTING_REQUIREMENTS.includes("Integration") || TESTING_REQUIREMENTS == "All" ? 
+`### Integration Testing
+- Follow the same integration test patterns found in the codebase
+- Match existing patterns for test data setup and teardown
+- Use the same approach for testing component interactions
+- Follow existing patterns for verifying system behavior` : ""}
+
+${TESTING_REQUIREMENTS.includes("E2E") || TESTING_REQUIREMENTS == "All" ? 
+`### End-to-End Testing
+- Match the existing E2E test structure and patterns
+- Follow established patterns for UI testing
+- Apply the same approach for verifying user journeys` : ""}
+
+${TESTING_REQUIREMENTS.includes("TDD") || TESTING_REQUIREMENTS == "All" ? 
+`### Test-Driven Development
+- Follow TDD patterns evident in the codebase
+- Match the progression of test cases seen in existing code
+- Apply the same refactoring patterns after tests pass` : ""}
+
+${TESTING_REQUIREMENTS.includes("BDD") || TESTING_REQUIREMENTS == "All" ? 
+`### Behavior-Driven Development
+- Match the existing Given-When-Then structure in tests
+- Follow the same patterns for behavior descriptions
+- Apply the same level of business focus in test cases` : ""}
+
+## Technology-Specific Guidelines
+
+${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### .NET Guidelines
+- Detect and strictly adhere to the specific .NET version in use
+- Use only C# language features compatible with the detected version
+- Follow LINQ usage patterns exactly as they appear in the codebase
+- Match async/await usage patterns from existing code
+- Apply the same dependency injection approach used in the codebase
+- Use the same collection types and patterns found in existing code` : ""}
+
+${PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Java Guidelines
+- Detect and adhere to the specific Java version in use
+- Follow the exact same design patterns found in the codebase
+- Match exception handling patterns from existing code
+- Use the same collection types and approaches found in the codebase
+- Apply the dependency injection patterns evident in existing code` : ""}
+
+${PROJECT_TYPE == "JavaScript" || PROJECT_TYPE == "TypeScript" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### JavaScript/TypeScript Guidelines
+- Detect and adhere to the specific ECMAScript/TypeScript version in use
+- Follow the same module import/export patterns found in the codebase
+- Match TypeScript type definitions with existing patterns
+- Use the same async patterns (promises, async/await) as existing code
+- Follow error handling patterns from similar files` : ""}
+
+${PROJECT_TYPE == "React" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### React Guidelines
+- Detect and adhere to the specific React version in use
+- Match component structure patterns from existing components
+- Follow the same hooks and lifecycle patterns found in the codebase
+- Apply the same state management approach used in existing components
+- Match prop typing and validation patterns from existing code` : ""}
+
+${PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Angular Guidelines
+- Detect and adhere to the specific Angular version in use
+- Follow the same component and module patterns found in the codebase
+- Match decorator usage exactly as seen in existing code
+- Apply the same RxJS patterns found in the codebase
+- Follow existing patterns for component communication` : ""}
+
+${PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Python Guidelines
+- Detect and adhere to the specific Python version in use
+- Follow the same import organization found in existing modules
+- Match type hinting approaches if used in the codebase
+- Apply the same error handling patterns found in existing code
+- Follow the same module organization patterns` : ""}
+
+## Version Control Guidelines
+
+${VERSIONING == "Semantic" ? 
+`- Follow Semantic Versioning patterns as applied in the codebase
+- Match existing patterns for documenting breaking changes
+- Follow the same approach for deprecation notices` : ""}
+
+${VERSIONING == "CalVer" ? 
+`- Follow Calendar Versioning patterns as applied in the codebase
+- Match existing patterns for documenting changes
+- Follow the same approach for highlighting significant changes` : ""}
+
+${VERSIONING == "Custom" ? 
+`- Match the exact versioning pattern observed in the codebase
+- Follow the same changelog format used in existing documentation
+- Apply the same tagging conventions used in the project` : ""}
+
+## General Best Practices
+
+- Follow naming conventions exactly as they appear in existing code
+- Match code organization patterns from similar files
+- Apply error handling consistent with existing patterns
+- Follow the same approach to testing as seen in the codebase
+- Match logging patterns from existing code
+- Use the same approach to configuration as seen in the codebase
+
+## Project-Specific Guidance
+
+- Scan the codebase thoroughly before generating any code
+- Respect existing architectural boundaries without exception
+- Match the style and patterns of surrounding code
+- When in doubt, prioritize consistency with existing code over external best practices
+```
+
+### 2. Codebase Analysis Instructions
+
+To create the copilot-instructions.md file, first analyze the codebase to:
+
+1. **Identify Exact Technology Versions**:
+   - ${PROJECT_TYPE == "Auto-detect" ? "Detect all programming languages, frameworks, and libraries by scanning file extensions and configuration files" : `Focus on ${PROJECT_TYPE} technologies`}
+   - Extract precise version information from project files, package.json, .csproj, etc.
+   - Document version constraints and compatibility requirements
+
+2. **Understand Architecture**:
+   - Analyze folder structure and module organization
+   - Identify clear layer boundaries and component relationships
+   - Document communication patterns between components
+
+3. **Document Code Patterns**:
+   - Catalog naming conventions for different code elements
+   - Note documentation styles and completeness
+   - Document error handling patterns
+   - Map testing approaches and coverage
+
+4. **Note Quality Standards**:
+   - Identify performance optimization techniques actually used
+   - Document security practices implemented in the code
+   - Note accessibility features present (if applicable)
+   - Document code quality patterns evident in the codebase
+
+### 3. Implementation Notes
+
+The final copilot-instructions.md should:
+- Be placed in the .github/copilot directory
+- Reference only patterns and standards that exist in the codebase
+- Include explicit version compatibility requirements
+- Avoid prescribing any practices not evident in the code
+- Provide concrete examples from the codebase
+- Be comprehensive yet concise enough for Copilot to effectively use
+
+Important: Only include guidance based on patterns actually observed in the codebase. Explicitly instruct Copilot to prioritize consistency with existing code over external best practices or newer language features.
+"
+
+## Expected Output
+
+A comprehensive copilot-instructions.md file that will guide GitHub Copilot to produce code that is perfectly compatible with your existing technology versions and follows your established patterns and architecture.

package/core/prompts/create-implementation-plan.prompt.md

@@ -0,0 +1,157 @@
+---
+mode: 'agent'
+description: 'Create a new implementation plan file for new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.'
+tools: ['changes', 'codebase', 'edit/editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
+---
+# Create Implementation Plan
+
+## Primary Directive
+
+Your goal is to create a new implementation plan file for `${input:PlanPurpose}`. Your output must be machine-readable, deterministic, and structured for autonomous execution by other AI systems or humans.
+
+## Execution Context
+
+This prompt is designed for AI-to-AI communication and automated processing. All instructions must be interpreted literally and executed systematically without human interpretation or clarification.
+
+## Core Requirements
+
+- Generate implementation plans that are fully executable by AI agents or humans
+- Use deterministic language with zero ambiguity
+- Structure all content for automated parsing and execution
+- Ensure complete self-containment with no external dependencies for understanding
+
+## Plan Structure Requirements
+
+Plans must consist of discrete, atomic phases containing executable tasks. Each phase must be independently processable by AI agents or humans without cross-phase dependencies unless explicitly declared.
+
+## Phase Architecture
+
+- Each phase must have measurable completion criteria
+- Tasks within phases must be executable in parallel unless dependencies are specified
+- All task descriptions must include specific file paths, function names, and exact implementation details
+- No task should require human interpretation or decision-making
+
+## AI-Optimized Implementation Standards
+
+- Use explicit, unambiguous language with zero interpretation required
+- Structure all content as machine-parseable formats (tables, lists, structured data)
+- Include specific file paths, line numbers, and exact code references where applicable
+- Define all variables, constants, and configuration values explicitly
+- Provide complete context within each task description
+- Use standardized prefixes for all identifiers (REQ-, TASK-, etc.)
+- Include validation criteria that can be automatically verified
+
+## Output File Specifications
+
+- Save implementation plan files in `/plan/` directory
+- Use naming convention: `[purpose]-[component]-[version].md`
+- Purpose prefixes: `upgrade|refactor|feature|data|infrastructure|process|architecture|design`
+- Example: `upgrade-system-command-4.md`, `feature-auth-module-1.md`
+- File must be valid Markdown with proper front matter structure
+
+## Mandatory Template Structure
+
+All implementation plans must strictly adhere to the following template. Each section is required and must be populated with specific, actionable content. AI agents must validate template compliance before execution.
+
+## Template Validation Rules
+
+- All front matter fields must be present and properly formatted
+- All section headers must match exactly (case-sensitive)
+- All identifier prefixes must follow the specified format
+- Tables must include all required columns
+- No placeholder text may remain in the final output
+
+## Status
+
+The status of the implementation plan must be clearly defined in the front matter and must reflect the current state of the plan. The status can be one of the following (status_color in brackets): `Completed` (bright green badge), `In progress` (yellow badge), `Planned` (blue badge), `Deprecated` (red badge), or `On Hold` (orange badge). It should also be displayed as a badge in the introduction section.
+
+```md
+---
+goal: [Concise Title Describing the Package Implementation Plan's Goal]
+version: [Optional: e.g., 1.0, Date]
+date_created: [YYYY-MM-DD]
+last_updated: [Optional: YYYY-MM-DD]
+owner: [Optional: Team/Individual responsible for this spec]
+status: 'Completed'|'In progress'|'Planned'|'Deprecated'|'On Hold'
+tags: [Optional: List of relevant tags or categories, e.g., `feature`, `upgrade`, `chore`, `architecture`, `migration`, `bug` etc]
+---
+
+# Introduction
+
+![Status: <status>](https://img.shields.io/badge/status-<status>-<status_color>)
+
+[A short concise introduction to the plan and the goal it is intended to achieve.]
+
+## 1. Requirements & Constraints
+
+[Explicitly list all requirements & constraints that affect the plan and constrain how it is implemented. Use bullet points or tables for clarity.]
+
+- **REQ-001**: Requirement 1
+- **SEC-001**: Security Requirement 1
+- **[3 LETTERS]-001**: Other Requirement 1
+- **CON-001**: Constraint 1
+- **GUD-001**: Guideline 1
+- **PAT-001**: Pattern to follow 1
+
+## 2. Implementation Steps
+
+### Implementation Phase 1
+
+- GOAL-001: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
+
+| Task | Description | Completed | Date |
+|------|-------------|-----------|------|
+| TASK-001 | Description of task 1 | ✅ | 2025-04-25 |
+| TASK-002 | Description of task 2 | |  |
+| TASK-003 | Description of task 3 | |  |
+
+### Implementation Phase 2
+
+- GOAL-002: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
+
+| Task | Description | Completed | Date |
+|------|-------------|-----------|------|
+| TASK-004 | Description of task 4 | |  |
+| TASK-005 | Description of task 5 | |  |
+| TASK-006 | Description of task 6 | |  |
+
+## 3. Alternatives
+
+[A bullet point list of any alternative approaches that were considered and why they were not chosen. This helps to provide context and rationale for the chosen approach.]
+
+- **ALT-001**: Alternative approach 1
+- **ALT-002**: Alternative approach 2
+
+## 4. Dependencies
+
+[List any dependencies that need to be addressed, such as libraries, frameworks, or other components that the plan relies on.]
+
+- **DEP-001**: Dependency 1
+- **DEP-002**: Dependency 2
+
+## 5. Files
+
+[List the files that will be affected by the feature or refactoring task.]
+
+- **FILE-001**: Description of file 1
+- **FILE-002**: Description of file 2
+
+## 6. Testing
+
+[List the tests that need to be implemented to verify the feature or refactoring task.]
+
+- **TEST-001**: Description of test 1
+- **TEST-002**: Description of test 2
+
+## 7. Risks & Assumptions
+
+[List any risks or assumptions related to the implementation of the plan.]
+
+- **RISK-001**: Risk 1
+- **ASSUMPTION-001**: Assumption 1
+
+## 8. Related Specifications / Further Reading
+
+[Link to related spec 1]
+[Link to relevant external documentation]
+```

package/core/prompts/create-oo-component-documentation.prompt.md

@@ -0,0 +1,193 @@
+---
+mode: 'agent'
+description: 'Create comprehensive, standardized documentation for object-oriented components following industry best practices and architectural documentation standards.'
+tools: ['changes', 'codebase', 'edit/editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
+---
+# 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
+---
+title: [Component Name] - Technical Documentation
+component_path: `${input:ComponentPath}`
+version: [Optional: e.g., 1.0, Date]
+date_created: [YYYY-MM-DD]
+last_updated: [Optional: YYYY-MM-DD]
+owner: [Optional: Team/Individual responsible for this component]
+tags: [Optional: List of relevant tags or categories, e.g., `component`,`service`,`tool`,`infrastructure`,`documentation`,`architecture` etc]
+---
+
+# [Component Name] Documentation
+
+[A short concise introduction to the component and its purpose within the system.]
+
+## 1. Component Overview
+
+### Purpose/Responsibility
+- OVR-001: State component's primary responsibility
+- OVR-002: Define scope (included/excluded functionality)
+- OVR-003: Describe system context and relationships
+
+## 2. Architecture Section
+
+- ARC-001: Document design patterns used (Repository, Factory, Observer, etc.)
+- ARC-002: List internal and external dependencies with purposes
+- ARC-003: Document component interactions and relationships
+- ARC-004: Include visual diagrams (UML class, sequence, component)
+- ARC-005: Create mermaid diagram showing component structure, relationships, and dependencies
+
+### Component Structure and Dependencies Diagram
+
+Include a comprehensive mermaid diagram that shows:
+- **Component structure** - Main classes, interfaces, and their relationships
+- **Internal dependencies** - How components interact within the system
+- **External dependencies** - External libraries, services, databases, APIs
+- **Data flow** - Direction of dependencies and interactions
+- **Inheritance/composition** - Class hierarchies and composition relationships
+
+```mermaid
+graph TD
+    subgraph "Component System"
+        A[Main Component] --> B[Internal Service]
+        A --> C[Internal Repository]
+        B --> D[Business Logic]
+        C --> E[Data Access Layer]
+    end
+
+    subgraph "External Dependencies"
+        F[External API]
+        G[Database]
+        H[Third-party Library]
+        I[Configuration Service]
+    end
+
+    A --> F
+    E --> G
+    B --> H
+    A --> I
+
+    classDiagram
+        class MainComponent {
+            +property: Type
+            +method(): ReturnType
+            +asyncMethod(): Promise~Type~
+        }
+        class InternalService {
+            +businessOperation(): Result
+        }
+        class ExternalAPI {
+            <<external>>
+            +apiCall(): Data
+        }
+
+        MainComponent --> InternalService
+        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
+
+| Method/Property | Purpose | Parameters | Return Type | Usage Notes |
+|-----------------|---------|------------|-------------|-------------|
+| [Name] | [Purpose] | [Parameters] | [Type] | [Notes] |
+
+## 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
+// Basic usage example
+var component = new ComponentName();
+component.DoSomething();
+```
+
+### Advanced Usage
+
+```csharp
+// Advanced configuration patterns
+var options = new ComponentOptions();
+var component = ComponentFactory.Create(options);
+await 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
+
+```