workspace-architect 1.3.0

package/assets/prompts/create-github-issues-for-unmet-specification-requirements.prompt.md

@@ -0,0 +1,35 @@
+---
+mode: 'agent'
+description: 'Create GitHub Issues for unimplemented requirements from specification files using feature_request.yml template.'
+tools: ['search/codebase', 'search', 'github', 'create_issue', 'search_issues', 'update_issue']
+---
+# Create GitHub Issues for Unmet Specification Requirements
+
+Create GitHub Issues for unimplemented requirements in the specification at `${file}`.
+
+## Process
+
+1. Analyze specification file to extract all requirements
+2. Check codebase implementation status for each requirement
+3. Search existing issues using `search_issues` to avoid duplicates
+4. Create new issue per unimplemented requirement using `create_issue`
+5. Use `feature_request.yml` template (fallback to default)
+
+## Requirements
+
+- One issue per unimplemented requirement from specification
+- Clear requirement ID and description mapping
+- Include implementation guidance and acceptance criteria
+- Verify against existing issues before creation
+
+## Issue Content
+
+- Title: Requirement ID and brief description
+- Description: Detailed requirement, implementation method, and context
+- Labels: feature, enhancement (as appropriate)
+
+## Implementation Check
+
+- Search codebase for related code patterns
+- Check related specification files in `/spec/` directory
+- Verify requirement isn't partially implemented

package/assets/prompts/create-github-pull-request-from-specification.prompt.md

@@ -0,0 +1,24 @@
+---
+mode: 'agent'
+description: 'Create GitHub Pull Request for feature request from specification file using pull_request_template.md template.'
+tools: ['search/codebase', 'search', 'github', 'create_pull_request', 'update_pull_request', 'get_pull_request_diff']
+---
+# Create GitHub Pull Request from Specification
+
+Create GitHub Pull Request for the specification at `${workspaceFolder}/.github/pull_request_template.md` .
+
+## Process
+
+1. Analyze specification file template from '${workspaceFolder}/.github/pull_request_template.md' to extract requirements by 'search' tool.
+2. Create pull request draft template by using 'create_pull_request' tool on to `${input:targetBranch}`. and make sure don't have any pull request of current branch was exist `get_pull_request`. If has continue to step 4, and skip step 3.
+3. Get changes in pull request by using 'get_pull_request_diff' tool to analyze information that was changed in pull Request.
+4. Update the pull request body and title created in the previous step using the 'update_pull_request' tool. Incorporate the information from the template obtained in the first step to update the body and title as needed.
+5. Switch from draft to ready for review by using 'update_pull_request' tool. To update state of pull request.
+6. Using 'get_me' to get username of person was created pull request and assign to `update_issue` tool. To assign pull request
+7. Response URL Pull request was create to user.
+
+## Requirements
+- Single pull request for the complete specification
+- Clear title/pull_request_template.md identifying the specification
+- Fill enough information into pull_request_template.md
+- Verify against existing pull requests before creation

package/assets/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', 'search/codebase', 'edit/editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/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/assets/prompts/create-llms.prompt.md

@@ -0,0 +1,210 @@
+---
+mode: 'agent'
+description: 'Create an llms.txt file from scratch based on repository structure 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']
+---
+# Create LLMs.txt File from Repository Structure
+
+Create a new `llms.txt` file from scratch in the root of the repository following the official llms.txt specification at https://llmstxt.org/. 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
+
+Create a comprehensive `llms.txt` file that serves as an entry point for LLMs to understand and navigate the repository effectively. The file must comply with the llms.txt specification and be optimized for LLM consumption while remaining human-readable.
+
+## Analysis and Planning Phase
+
+Before creating the `llms.txt` file, you must complete a thorough analysis:
+
+### Step 1: Review llms.txt Specification
+
+- Review the official specification at https://llmstxt.org/ to ensure full compliance
+- Understand the required format structure and guidelines
+- Note the specific markdown structure requirements
+
+### Step 2: Repository Structure Analysis
+
+- Examine the complete repository structure using appropriate tools
+- Identify the primary purpose and scope of the repository
+- Catalog all important directories and their purposes
+- List key files that would be valuable for LLM understanding
+
+### Step 3: Content Discovery
+
+- Identify README files and their locations
+- Find documentation files (`.md` files in `/docs/`, `/spec/`, etc.)
+- Locate specification files and their purposes
+- Discover configuration files and their relevance
+- Find example files and code samples
+- Identify any existing documentation structure
+
+### Step 4: Create Implementation Plan
+
+Based on your analysis, create a structured plan that includes:
+
+- Repository purpose and scope summary
+- Priority-ordered list of essential files for LLM understanding
+- Secondary files that provide additional context
+- Organizational structure for the llms.txt file
+
+## Implementation Requirements
+
+### Format Compliance
+
+The `llms.txt` file must follow 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: Repository Analysis
+
+1. Examine the repository structure completely
+2. Read the main README.md to understand the project
+3. Identify all documentation directories and files
+4. Catalog specification files and their purposes
+5. Find example files and configuration files
+
+### Step 2: Content Planning
+
+1. Determine the primary purpose statement
+2. Write a concise summary for the blockquote
+3. Group identified files into logical categories
+4. Prioritize files by importance for LLM understanding
+5. Create descriptions for each file link
+
+### Step 3: File Creation
+
+1. Create the `llms.txt` file in the repository root
+2. Follow the exact format specification
+3. Include all required sections
+4. Use proper markdown formatting
+5. Ensure all links are valid relative paths
+
+### Step 4: Validation
+1. Verify compliance with https://llmstxt.org/ specification
+2. Check that all links are valid and accessible
+3. Ensure the file serves as an effective LLM navigation tool
+4. Confirm the file is 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`)
+
+## Example Structure Template
+
+```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 created `llms.txt` file should:
+1. Enable LLMs to quickly understand the repository's purpose
+2. Provide clear navigation to essential documentation
+3. Follow the official llms.txt specification exactly
+4. Be comprehensive yet concise
+5. Serve both human and machine readers effectively
+6. Include all critical files for project understanding
+7. Use clear, unambiguous language throughout
+8. Organize content logically for easy consumption

package/assets/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', 'search/codebase', 'edit/editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/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
+
+```

package/assets/prompts/create-readme.prompt.md

@@ -0,0 +1,21 @@
+---
+mode: 'agent'
+description: 'Create a README.md file for the project'
+---
+
+## Role
+
+You're a senior expert software engineer with extensive experience in open source projects. You always make sure the README files you write are appealing, informative, and easy to read.
+
+## Task
+
+1. Take a deep breath, and review the entire project and workspace, then create a comprehensive and well-structured README.md file for the project.
+2. Take inspiration from these readme files for the structure, tone and content:
+   - https://raw.githubusercontent.com/Azure-Samples/serverless-chat-langchainjs/refs/heads/main/README.md
+   - https://raw.githubusercontent.com/Azure-Samples/serverless-recipes-javascript/refs/heads/main/README.md
+   - https://raw.githubusercontent.com/sinedied/run-on-output/refs/heads/main/README.md
+   - https://raw.githubusercontent.com/sinedied/smoke/refs/heads/main/README.md
+3. Do not overuse emojis, and keep the readme concise and to the point.
+4. Do not include sections like "LICENSE", "CONTRIBUTING", "CHANGELOG", etc. There are dedicated files for those sections.
+5. Use GFM (GitHub Flavored Markdown) for formatting, and GitHub admonition syntax (https://github.com/orgs/community/discussions/16925) where appropriate.
+6. If you find a logo or icon for the project, use it in the readme's header.