workspace-architect 1.3.0

package/assets/prompts/update-llms.prompt.md

@@ -0,0 +1,216 @@
+---
+mode: 'agent'
+description: 'Update the llms.txt file in the root folder to reflect changes in documentation or specifications following the llms.txt specification at https://llmstxt.org/'
+tools: ['changes', 'search/codebase', 'edit/editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
+---
+# Update LLMs.txt File
+
+Update the existing `llms.txt` file in the root of the repository to reflect changes in documentation, specifications, or repository structure. This file provides high-level guidance to large language models (LLMs) on where to find relevant content for understanding the repository's purpose and specifications.
+
+## Primary Directive
+
+Update the existing `llms.txt` file to maintain accuracy and compliance with the llms.txt specification while reflecting current repository structure and content. The file must remain optimized for LLM consumption while staying human-readable.
+
+## Analysis and Planning Phase
+
+Before updating the `llms.txt` file, you must complete a thorough analysis:
+
+### Step 1: Review Current File and Specification
+- Read the existing `llms.txt` file to understand current structure
+- Review the official specification at https://llmstxt.org/ to ensure continued compliance
+- Identify areas that may need updates based on repository changes
+
+### Step 2: Repository Structure Analysis
+- Examine the current repository structure using appropriate tools
+- Compare current structure with what's documented in existing `llms.txt`
+- Identify new directories, files, or documentation that should be included
+- Note any removed or relocated files that need to be updated
+
+### Step 3: Content Discovery and Change Detection
+- Identify new README files and their locations
+- Find new documentation files (`.md` files in `/docs/`, `/spec/`, etc.)
+- Locate new specification files and their purposes
+- Discover new configuration files and their relevance
+- Find new example files and code samples
+- Identify any changes to existing documentation structure
+
+### Step 4: Create Update Plan
+Based on your analysis, create a structured plan that includes:
+- Changes needed to maintain accuracy
+- New files to be added to the llms.txt
+- Outdated references to be removed or updated
+- Organizational improvements to maintain clarity
+
+## Implementation Requirements
+
+### Format Compliance
+The updated `llms.txt` file must maintain this exact structure per the specification:
+
+1. **H1 Header**: Single line with repository/project name (required)
+2. **Blockquote Summary**: Brief description in blockquote format (optional but recommended)
+3. **Additional Details**: Zero or more markdown sections without headings for context
+4. **File List Sections**: Zero or more H2 sections containing markdown lists of links
+
+### Content Requirements
+
+#### Required Elements
+- **Project Name**: Clear, descriptive title as H1
+- **Summary**: Concise blockquote explaining the repository's purpose
+- **Key Files**: Essential files organized by category (H2 sections)
+
+#### File Link Format
+Each file link must follow: `[descriptive-name](relative-url): optional description`
+
+#### Section Organization
+Organize files into logical H2 sections such as:
+- **Documentation**: Core documentation files
+- **Specifications**: Technical specifications and requirements
+- **Examples**: Sample code and usage examples
+- **Configuration**: Setup and configuration files
+- **Optional**: Secondary files (special meaning - can be skipped for shorter context)
+
+### Content Guidelines
+
+#### Language and Style
+- Use concise, clear, unambiguous language
+- Avoid jargon without explanation
+- Write for both human and LLM readers
+- Be specific and informative in descriptions
+
+#### File Selection Criteria
+Include files that:
+- Explain the repository's purpose and scope
+- Provide essential technical documentation
+- Show usage examples and patterns
+- Define interfaces and specifications
+- Contain configuration and setup instructions
+
+Exclude files that:
+- Are purely implementation details
+- Contain redundant information
+- Are build artifacts or generated content
+- Are not relevant to understanding the project
+
+## Execution Steps
+
+### Step 1: Current State Analysis
+1. Read the existing `llms.txt` file thoroughly
+2. Examine the current repository structure completely
+3. Compare existing file references with actual repository content
+4. Identify outdated, missing, or incorrect references
+5. Note any structural issues with the current file
+
+### Step 2: Content Planning
+1. Determine if the primary purpose statement needs updates
+2. Review and update the summary blockquote if needed
+3. Plan additions for new files and directories
+4. Plan removals for outdated or moved content
+5. Reorganize sections if needed for better clarity
+
+### Step 3: File Updates
+1. Update the existing `llms.txt` file in the repository root
+2. Maintain compliance with the exact format specification
+3. Add new file references with appropriate descriptions
+4. Remove or update outdated references
+5. Ensure all links are valid relative paths
+
+### Step 4: Validation
+1. Verify continued compliance with https://llmstxt.org/ specification
+2. Check that all links are valid and accessible
+3. Ensure the file still serves as an effective LLM navigation tool
+4. Confirm the file remains both human and machine readable
+
+## Quality Assurance
+
+### Format Validation
+- ✅ H1 header with project name
+- ✅ Blockquote summary (if included)
+- ✅ H2 sections for file lists
+- ✅ Proper markdown link format
+- ✅ No broken or invalid links
+- ✅ Consistent formatting throughout
+
+### Content Validation
+- ✅ Clear, unambiguous language
+- ✅ Comprehensive coverage of essential files
+- ✅ Logical organization of content
+- ✅ Appropriate file descriptions
+- ✅ Serves as effective LLM navigation tool
+
+### Specification Compliance
+- ✅ Follows https://llmstxt.org/ format exactly
+- ✅ Uses required markdown structure
+- ✅ Implements optional sections appropriately
+- ✅ File located at repository root (`/llms.txt`)
+
+## Update Strategy
+
+### Addition Process
+When adding new content:
+1. Identify the appropriate section for new files
+2. Create clear, descriptive names for links
+3. Write concise but informative descriptions
+4. Maintain alphabetical or logical ordering within sections
+5. Consider if new sections are needed for new content types
+
+### Removal Process
+When removing outdated content:
+1. Verify files are actually removed or relocated
+2. Check if relocated files should be updated rather than removed
+3. Remove entire sections if they become empty
+4. Update cross-references if needed
+
+### Reorganization Process
+When restructuring content:
+1. Maintain logical flow from general to specific
+2. Keep essential documentation in primary sections
+3. Move secondary content to "Optional" section if appropriate
+4. Ensure new organization improves LLM navigation
+
+Example structure for `llms.txt`:
+
+```txt
+# [Repository Name]
+
+> [Concise description of the repository's purpose and scope]
+
+[Optional additional context paragraphs without headings]
+
+## Documentation
+
+- [Main README](README.md): Primary project documentation and getting started guide
+- [Contributing Guide](CONTRIBUTING.md): Guidelines for contributing to the project
+- [Code of Conduct](CODE_OF_CONDUCT.md): Community guidelines and expectations
+
+## Specifications
+
+- [Technical Specification](spec/technical-spec.md): Detailed technical requirements and constraints
+- [API Specification](spec/api-spec.md): Interface definitions and data contracts
+
+## Examples
+
+- [Basic Example](examples/basic-usage.md): Simple usage demonstration
+- [Advanced Example](examples/advanced-usage.md): Complex implementation patterns
+
+## Configuration
+
+- [Setup Guide](docs/setup.md): Installation and configuration instructions
+- [Deployment Guide](docs/deployment.md): Production deployment guidelines
+
+## Optional
+
+- [Architecture Documentation](docs/architecture.md): Detailed system architecture
+- [Design Decisions](docs/decisions.md): Historical design decision records
+```
+
+## Success Criteria
+
+The updated `llms.txt` file should:
+1. Accurately reflect the current repository structure and content
+2. Maintain compliance with the llms.txt specification
+3. Provide clear navigation to essential documentation
+4. Remove outdated or incorrect references
+5. Include new important files and documentation
+6. Maintain logical organization for easy LLM consumption
+7. Use clear, unambiguous language throughout
+8. Continue to serve both human and machine readers effectively

package/assets/prompts/update-markdown-file-index.prompt.md

@@ -0,0 +1,76 @@
+---
+mode: 'agent'
+description: 'Update a markdown file section with an index/table of files from a specified folder.'
+tools: ['changes', 'search/codebase', 'edit/editFiles', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'openSimpleBrowser', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
+---
+# Update Markdown File Index
+
+Update markdown file `${file}` with an index/table of files from folder `${input:folder}`.
+
+## Process
+
+1. **Scan**: Read the target markdown file `${file}` to understand existing structure
+2. **Discover**: List all files in the specified folder `${input:folder}` matching pattern `${input:pattern}`
+3. **Analyze**: Identify if an existing table/index section exists to update, or create new structure
+4. **Structure**: Generate appropriate table/list format based on file types and existing content
+5. **Update**: Replace existing section or add new section with file index
+6. **Validate**: Ensure markdown syntax is valid and formatting is consistent
+
+## File Analysis
+
+For each discovered file, extract:
+
+- **Name**: Filename with or without extension based on context
+- **Type**: File extension and category (e.g., `.md`, `.js`, `.py`)
+- **Description**: First line comment, header, or inferred purpose
+- **Size**: File size for reference (optional)
+- **Modified**: Last modified date (optional)
+
+## Table Structure Options
+
+Choose format based on file types and existing content:
+
+### Option 1: Simple List
+
+```markdown
+## Files in ${folder}
+
+- [filename.ext](path/to/filename.ext) - Description
+- [filename2.ext](path/to/filename2.ext) - Description
+```
+
+### Option 2: Detailed Table
+
+| File | Type | Description |
+|------|------|-------------|
+| [filename.ext](path/to/filename.ext) | Extension | Description |
+| [filename2.ext](path/to/filename2.ext) | Extension | Description |
+
+### Option 3: Categorized Sections
+
+Group files by type/category with separate sections or sub-tables.
+
+## Update Strategy
+
+- 🔄 **Update existing**: If table/index section exists, replace content while preserving structure
+- ➕ **Add new**: If no existing section, create new section using best-fit format
+- 📋 **Preserve**: Maintain existing markdown formatting, heading levels, and document flow
+- 🔗 **Links**: Use relative paths for file links within the repository
+
+## Section Identification
+
+Look for existing sections with these patterns:
+
+- Headings containing: "index", "files", "contents", "directory", "list"
+- Tables with file-related columns
+- Lists with file links
+- HTML comments marking file index sections
+
+## Requirements
+
+- Preserve existing markdown structure and formatting
+- Use relative paths for file links
+- Include file descriptions when available
+- Sort files alphabetically by default
+- Handle special characters in filenames
+- Validate all generated markdown syntax

package/assets/prompts/update-oo-component-documentation.prompt.md

@@ -0,0 +1,162 @@
+---
+mode: 'agent'
+description: 'Update existing object-oriented component documentation following industry best practices and architectural documentation standards.'
+tools: ['changes', 'search/codebase', 'edit/editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
+---
+# Update Standard OO Component Documentation
+
+Update the existing documentation file at: `${file}` by analyzing the corresponding component code.
+
+Extract the component path from the existing documentation's front matter (`component_path` field) or infer it from the documentation content. Analyze the current component implementation and update the documentation accordingly.
+
+**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: Read existing documentation to understand component context and structure
+- ANA-002: Identify component path from front matter or content analysis
+- ANA-003: Examine current source code files for class structures and inheritance
+- ANA-004: Compare existing documentation with current implementation
+- ANA-005: Identify design patterns and architectural changes
+- ANA-006: Update public APIs, interfaces, and dependencies
+- ANA-007: Recognize new/changed creational/structural/behavioral patterns
+- ANA-008: Update method parameters, return values, exceptions
+- ANA-009: Reassess performance, security, reliability, maintainability
+- ANA-010: Update 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
+
+**Update Strategy:**
+
+- UPD-001: Preserve existing documentation structure and format
+- UPD-002: Update `last_updated` field to current date
+- UPD-003: Maintain version history in front matter if present
+- UPD-004: Add new sections if component has significantly expanded
+- UPD-005: Mark deprecated features or breaking changes
+- UPD-006: Update examples to reflect current API
+- UPD-007: Refresh dependency lists and versions
+- UPD-008: Update mermaid diagrams to reflect current architecture
+
+**Error Handling:**
+
+- ERR-001: Documentation file doesn't exist - provide guidance on file location
+- ERR-002: Component path not found in documentation - request clarification
+- ERR-003: Source code has moved - suggest updated paths
+- ERR-004: Major architectural changes - highlight breaking changes
+- ERR-005: Insufficient access to source - document limitations
+
+**Output Format:**
+
+Update the existing Markdown file maintaining its structure while refreshing content to match current implementation. Preserve formatting, heading hierarchy, and existing organizational decisions.
+
+**Required Documentation Structure:**
+
+Update the existing documentation following the same template structure, ensuring all sections reflect current implementation:
+
+```md
+---
+title: [Component Name] - Technical Documentation
+component_path: [Current component path]
+version: [Updated version if applicable]
+date_created: [Original creation date - preserve]
+last_updated: [YYYY-MM-DD - update to current date]
+owner: [Preserve existing or update if changed]
+tags: [Update tags as needed based on current functionality]
+---
+
+# [Component Name] Documentation
+
+[Update introduction to reflect current component purpose and capabilities]
+
+## 1. Component Overview
+
+### Purpose/Responsibility
+- OVR-001: Update component's primary responsibility
+- OVR-002: Refresh scope (included/excluded functionality)
+- OVR-003: Update system context and relationships
+
+## 2. Architecture Section
+
+- ARC-001: Update design patterns used (Repository, Factory, Observer, etc.)
+- ARC-002: Refresh internal and external dependencies with current purposes
+- ARC-003: Update component interactions and relationships
+- ARC-004: Update visual diagrams (UML class, sequence, component)
+- ARC-005: Refresh mermaid diagram showing current component structure, relationships, and dependencies
+
+### Component Structure and Dependencies Diagram
+
+Update the mermaid diagram to show current:
+- **Component structure** - Current classes, interfaces, and their relationships
+- **Internal dependencies** - How components currently interact within the system
+- **External dependencies** - Current external libraries, services, databases, APIs
+- **Data flow** - Current direction of dependencies and interactions
+- **Inheritance/composition** - Current class hierarchies and composition relationships
+
+```mermaid
+[Update diagram to reflect current architecture]
+```
+
+## 3. Interface Documentation
+
+- INT-001: Update all public interfaces and current usage patterns
+- INT-002: Refresh method/property reference table with current API
+- INT-003: Update events/callbacks/notification mechanisms
+
+| Method/Property | Purpose | Parameters | Return Type | Usage Notes |
+|-----------------|---------|------------|-------------|-------------|
+| [Update table with current API] | | | | |
+
+## 4. Implementation Details
+
+- IMP-001: Update main implementation classes and current responsibilities
+- IMP-002: Refresh configuration requirements and initialization patterns
+- IMP-003: Update key algorithms and business logic
+- IMP-004: Update performance characteristics and bottlenecks
+
+## 5. Usage Examples
+
+### Basic Usage
+
+```csharp
+// Update basic usage example to current API
+```
+
+### Advanced Usage
+
+```csharp
+// Update advanced configuration patterns to current implementation
+```
+
+- USE-001: Update basic usage examples
+- USE-002: Refresh advanced configuration patterns
+- USE-003: Update best practices and recommended patterns
+
+## 6. Quality Attributes
+
+- QUA-001: Update security (authentication, authorization, data protection)
+- QUA-002: Refresh performance (characteristics, scalability, resource usage)
+- QUA-003: Update reliability (error handling, fault tolerance, recovery)
+- QUA-004: Refresh maintainability (standards, testing, documentation)
+- QUA-005: Update extensibility (extension points, customization options)
+
+## 7. Reference Information
+
+- REF-001: Update dependencies with current versions and purposes
+- REF-002: Refresh configuration options reference
+- REF-003: Update testing guidelines and mock setup
+- REF-004: Refresh troubleshooting (common issues, error messages)
+- REF-005: Update related documentation links
+- REF-006: Add change history and migration notes for this update
+
+```

package/assets/prompts/update-specification.prompt.md

@@ -0,0 +1,127 @@
+---
+mode: 'agent'
+description: 'Update an existing specification file for the solution, optimized for Generative AI consumption based on new requirements or updates to any existing code.'
+tools: ['changes', 'search/codebase', 'edit/editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
+---
+# Update Specification
+
+Your goal is to update the existing specification file `${file}` based on new requirements or updates to any existing code.
+
+The specification file must define the requirements, constraints, and interfaces for the solution components in a manner that is clear, unambiguous, and structured for effective use by Generative AIs. Follow established documentation standards and ensure the content is machine-readable and self-contained.
+
+## Best Practices for AI-Ready Specifications
+
+- Use precise, explicit, and unambiguous language.
+- Clearly distinguish between requirements, constraints, and recommendations.
+- Use structured formatting (headings, lists, tables) for easy parsing.
+- Avoid idioms, metaphors, or context-dependent references.
+- Define all acronyms and domain-specific terms.
+- Include examples and edge cases where applicable.
+- Ensure the document is self-contained and does not rely on external context.
+
+The specification should be saved in the [/spec/](/spec/) directory and named according to the following convention: `[a-z0-9-]+.md`, where the name should be descriptive of the specification's content and starting with the highlevel purpose, which is one of [schema, tool, data, infrastructure, process, architecture, or design].
+
+The specification file must be formatted in well formed Markdown.
+
+Specification files 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: [Concise Title Describing the Specification's Focus]
+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]
+tags: [Optional: List of relevant tags or categories, e.g., `infrastructure`, `process`, `design`, `app` etc]
+---
+
+# Introduction
+
+[A short concise introduction to the specification and the goal it is intended to achieve.]
+
+## 1. Purpose & Scope
+
+[Provide a clear, concise description of the specification's purpose and the scope of its application. State the intended audience and any assumptions.]
+
+## 2. Definitions
+
+[List and define all acronyms, abbreviations, and domain-specific terms used in this specification.]
+
+## 3. Requirements, Constraints & Guidelines
+
+[Explicitly list all requirements, constraints, rules, and guidelines. 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
+
+## 4. Interfaces & Data Contracts
+
+[Describe the interfaces, APIs, data contracts, or integration points. Use tables or code blocks for schemas and examples.]
+
+## 5. Acceptance Criteria
+
+[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]
+
+- **AC-001**: Given [context], When [action], Then [expected outcome]
+- **AC-002**: The system shall [specific behavior] when [condition]
+- **AC-003**: [Additional acceptance criteria as needed]
+
+## 6. Test Automation Strategy
+
+[Define the testing approach, frameworks, and automation requirements.]
+
+- **Test Levels**: Unit, Integration, End-to-End
+- **Frameworks**: MSTest, FluentAssertions, Moq (for .NET applications)
+- **Test Data Management**: [approach for test data creation and cleanup]
+- **CI/CD Integration**: [automated testing in GitHub Actions pipelines]
+- **Coverage Requirements**: [minimum code coverage thresholds]
+- **Performance Testing**: [approach for load and performance testing]
+
+## 7. Rationale & Context
+
+[Explain the reasoning behind the requirements, constraints, and guidelines. Provide context for design decisions.]
+
+## 8. Dependencies & External Integrations
+
+[Define the external systems, services, and architectural dependencies required for this specification. Focus on **what** is needed rather than **how** it's implemented. Avoid specific package or library versions unless they represent architectural constraints.]
+
+### External Systems
+- **EXT-001**: [External system name] - [Purpose and integration type]
+
+### Third-Party Services
+- **SVC-001**: [Service name] - [Required capabilities and SLA requirements]
+
+### Infrastructure Dependencies
+- **INF-001**: [Infrastructure component] - [Requirements and constraints]
+
+### Data Dependencies
+- **DAT-001**: [External data source] - [Format, frequency, and access requirements]
+
+### Technology Platform Dependencies
+- **PLT-001**: [Platform/runtime requirement] - [Version constraints and rationale]
+
+### Compliance Dependencies
+- **COM-001**: [Regulatory or compliance requirement] - [Impact on implementation]
+
+**Note**: This section should focus on architectural and business dependencies, not specific package implementations. For example, specify "OAuth 2.0 authentication library" rather than "Microsoft.AspNetCore.Authentication.JwtBearer v6.0.1".
+
+## 9. Examples & Edge Cases
+
+```code
+// Code snippet or data example demonstrating the correct application of the guidelines, including edge cases
+```
+
+## 10. Validation Criteria
+
+[List the criteria or tests that must be satisfied for compliance with this specification.]
+
+## 11. Related Specifications / Further Reading
+
+[Link to related spec 1]
+[Link to relevant external documentation]
+
+```