workspace-architect 1.3.0

package/assets/prompts/csharp-async.prompt.md

@@ -0,0 +1,50 @@
+---
+mode: 'agent'
+tools: ['changes', 'search/codebase', 'edit/editFiles', 'problems']
+description: 'Get best practices for C# async programming'
+---
+
+# C# Async Programming Best Practices
+
+Your goal is to help me follow best practices for asynchronous programming in C#.
+
+## Naming Conventions
+
+- Use the 'Async' suffix for all async methods
+- Match method names with their synchronous counterparts when applicable (e.g., `GetDataAsync()` for `GetData()`)
+
+## Return Types
+
+- Return `Task<T>` when the method returns a value
+- Return `Task` when the method doesn't return a value
+- Consider `ValueTask<T>` for high-performance scenarios to reduce allocations
+- Avoid returning `void` for async methods except for event handlers
+
+## Exception Handling
+
+- Use try/catch blocks around await expressions
+- Avoid swallowing exceptions in async methods
+- Use `ConfigureAwait(false)` when appropriate to prevent deadlocks in library code
+- Propagate exceptions with `Task.FromException()` instead of throwing in async Task returning methods
+
+## Performance
+
+- Use `Task.WhenAll()` for parallel execution of multiple tasks
+- Use `Task.WhenAny()` for implementing timeouts or taking the first completed task
+- Avoid unnecessary async/await when simply passing through task results
+- Consider cancellation tokens for long-running operations
+
+## Common Pitfalls
+
+- Never use `.Wait()`, `.Result`, or `.GetAwaiter().GetResult()` in async code
+- Avoid mixing blocking and async code
+- Don't create async void methods (except for event handlers)
+- Always await Task-returning methods
+
+## Implementation Patterns
+
+- Implement the async command pattern for long-running operations
+- Use async streams (IAsyncEnumerable<T>) for processing sequences asynchronously
+- Consider the task-based asynchronous pattern (TAP) for public APIs
+
+When reviewing my C# code, identify these issues and suggest improvements that follow these best practices.

package/assets/prompts/csharp-docs.prompt.md

@@ -0,0 +1,63 @@
+---
+mode: 'agent'
+tools: ['changes', 'search/codebase', 'edit/editFiles', 'problems']
+description: 'Ensure that C# types are documented with XML comments and follow best practices for documentation.'
+---
+
+# C# Documentation Best Practices
+
+- Public members should be documented with XML comments.
+- It is encouraged to document internal members as well, especially if they are complex or not self-explanatory.
+
+## Guidance for all APIs
+
+- Use `<summary>` to provide a brief, one sentence, description of what the type or member does. Start the summary with a present-tense, third-person verb.
+- Use `<remarks>` for additional information, which can include implementation details, usage notes, or any other relevant context.
+- Use `<see langword>` for language-specific keywords like `null`, `true`, `false`, `int`, `bool`, etc.
+- Use `<c>` for inline code snippets.
+- Use `<example>` for usage examples on how to use the member.
+  - Use `<code>` for code blocks. `<code>` tags should be placed within an `<example>` tag. Add the language of the code example using the `language` attribute, for example, `<code language="csharp">`.
+- Use `<see cref>` to reference other types or members inline (in a sentence).
+- Use `<seealso>` for standalone (not in a sentence) references to other types or members in the "See also" section of the online docs.
+- Use `<inheritdoc/>` to inherit documentation from base classes or interfaces.
+  - Unless there is major behavior change, in which case you should document the differences.
+
+## Methods
+
+- Use `<param>` to describe method parameters.
+  - The description should be a noun phrase that doesn't specify the data type.
+  - Begin with an introductory article.
+  - If the parameter is a flag enum, start the description with "A bitwise combination of the enumeration values that specifies...".
+  - If the parameter is a non-flag enum, start the description with "One of the enumeration values that specifies...".
+  - If the parameter is a Boolean, the wording should be of the form "`<see langword="true" />` to ...; otherwise, `<see langword="false" />`.".
+  - If the parameter is an "out" parameter, the wording should be of the form "When this method returns, contains .... This parameter is treated as uninitialized.".
+- Use `<paramref>` to reference parameter names in documentation.
+- Use `<typeparam>` to describe type parameters in generic types or methods.
+- Use `<typeparamref>` to reference type parameters in documentation.
+- Use `<returns>` to describe what the method returns.
+  - The description should be a noun phrase that doesn't specify the data type.
+  - Begin with an introductory article.
+  - If the return type is Boolean, the wording should be of the form "`<see langword="true" />` if ...; otherwise, `<see langword="false" />`.".
+
+## Constructors
+
+- The summary wording should be "Initializes a new instance of the <Class> class [or struct].".
+
+## Properties
+
+- The `<summary>` should start with:
+  - "Gets or sets..." for a read-write property.
+  - "Gets..." for a read-only property.
+  - "Gets [or sets] a value that indicates whether..." for properties that return a Boolean value.
+- Use `<value>` to describe the value of the property.
+  - The description should be a noun phrase that doesn't specify the data type.
+  - If the property has a default value, add it in a separate sentence, for example, "The default is `<see langword="false" />`".
+  - If the value type is Boolean, the wording should be of the form "`<see langword="true" />` if ...; otherwise, `<see langword="false" />`. The default is ...".
+
+## Exceptions
+
+- Use `<exception cref>` to document exceptions thrown by constructors, properties, indexers, methods, operators, and events.
+- Document all exceptions thrown directly by the member.
+- For exceptions thrown by nested members, document only the exceptions users are most likely to encounter.
+- The description of the exception describes the condition under which it's thrown.
+  - Omit "Thrown if ..." or "If ..." at the beginning of the sentence. Just state the condition directly, for example "An error occurred when accessing a Message Queuing API."

package/assets/prompts/csharp-mcp-server-generator.prompt.md

@@ -0,0 +1,59 @@
+---
+mode: 'agent'
+description: 'Generate a complete MCP server project in C# with tools, prompts, and proper configuration'
+---
+
+# Generate C# MCP Server
+
+Create a complete Model Context Protocol (MCP) server in C# with the following specifications:
+
+## Requirements
+
+1. **Project Structure**: Create a new C# console application with proper directory structure
+2. **NuGet Packages**: Include ModelContextProtocol (prerelease) and Microsoft.Extensions.Hosting
+3. **Logging Configuration**: Configure all logs to stderr to avoid interfering with stdio transport
+4. **Server Setup**: Use the Host builder pattern with proper DI configuration
+5. **Tools**: Create at least one useful tool with proper attributes and descriptions
+6. **Error Handling**: Include proper error handling and validation
+
+## Implementation Details
+
+### Basic Project Setup
+- Use .NET 8.0 or later
+- Create a console application
+- Add necessary NuGet packages with --prerelease flag
+- Configure logging to stderr
+
+### Server Configuration
+- Use `Host.CreateApplicationBuilder` for DI and lifecycle management
+- Configure `AddMcpServer()` with stdio transport
+- Use `WithToolsFromAssembly()` for automatic tool discovery
+- Ensure the server runs with `RunAsync()`
+
+### Tool Implementation
+- Use `[McpServerToolType]` attribute on tool classes
+- Use `[McpServerTool]` attribute on tool methods
+- Add `[Description]` attributes to tools and parameters
+- Support async operations where appropriate
+- Include proper parameter validation
+
+### Code Quality
+- Follow C# naming conventions
+- Include XML documentation comments
+- Use nullable reference types
+- Implement proper error handling with McpProtocolException
+- Use structured logging for debugging
+
+## Example Tool Types to Consider
+- File operations (read, write, search)
+- Data processing (transform, validate, analyze)
+- External API integrations (HTTP requests)
+- System operations (execute commands, check status)
+- Database operations (query, update)
+
+## Testing Guidance
+- Explain how to run the server
+- Provide example commands to test with MCP clients
+- Include troubleshooting tips
+
+Generate a complete, production-ready MCP server with comprehensive documentation and error handling.

package/assets/prompts/csharp-mstest.prompt.md

@@ -0,0 +1,67 @@
+---
+mode: 'agent'
+tools: ['changes', 'search/codebase', 'edit/editFiles', 'problems', 'search']
+description: 'Get best practices for MSTest unit testing, including data-driven tests'
+---
+
+# MSTest Best Practices
+
+Your goal is to help me write effective unit tests with MSTest, covering both standard and data-driven testing approaches.
+
+## Project Setup
+
+- Use a separate test project with naming convention `[ProjectName].Tests`
+- Reference MSTest package
+- Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`)
+- Use .NET SDK test commands: `dotnet test` for running tests
+
+## Test Structure
+
+- Use `[TestClass]` attribute for test classes
+- Use `[TestMethod]` attribute for test methods
+- Follow the Arrange-Act-Assert (AAA) pattern
+- Name tests using the pattern `MethodName_Scenario_ExpectedBehavior`
+- Use `[TestInitialize]` and `[TestCleanup]` for per-test setup and teardown
+- Use `[ClassInitialize]` and `[ClassCleanup]` for per-class setup and teardown
+- Use `[AssemblyInitialize]` and `[AssemblyCleanup]` for assembly-level setup and teardown
+
+## Standard Tests
+
+- Keep tests focused on a single behavior
+- Avoid testing multiple behaviors in one test method
+- Use clear assertions that express intent
+- Include only the assertions needed to verify the test case
+- Make tests independent and idempotent (can run in any order)
+- Avoid test interdependencies
+
+## Data-Driven Tests
+
+- Use `[TestMethod]` combined with data source attributes
+- Use `[DataRow]` for inline test data
+- Use `[DynamicData]` for programmatically generated test data
+- Use `[TestProperty]` to add metadata to tests
+- Use meaningful parameter names in data-driven tests
+
+## Assertions
+
+- Use `Assert.AreEqual` for value equality
+- Use `Assert.AreSame` for reference equality
+- Use `Assert.IsTrue`/`Assert.IsFalse` for boolean conditions
+- Use `CollectionAssert` for collection comparisons
+- Use `StringAssert` for string-specific assertions
+- Use `Assert.Throws<T>` to test exceptions
+- Ensure assertions are simple in nature and have a message provided for clarity on failure
+
+## Mocking and Isolation
+
+- Consider using Moq or NSubstitute alongside MSTest
+- Mock dependencies to isolate units under test
+- Use interfaces to facilitate mocking
+- Consider using a DI container for complex test setups
+
+## Test Organization
+
+- Group tests by feature or component
+- Use test categories with `[TestCategory("Category")]`
+- Use test priorities with `[Priority(1)]` for critical tests
+- Use `[Owner("DeveloperName")]` to indicate ownership

package/assets/prompts/csharp-nunit.prompt.md

@@ -0,0 +1,72 @@
+---
+mode: 'agent'
+tools: ['changes', 'search/codebase', 'edit/editFiles', 'problems', 'search']
+description: 'Get best practices for NUnit unit testing, including data-driven tests'
+---
+
+# NUnit Best Practices
+
+Your goal is to help me write effective unit tests with NUnit, covering both standard and data-driven testing approaches.
+
+## Project Setup
+
+- Use a separate test project with naming convention `[ProjectName].Tests`
+- Reference Microsoft.NET.Test.Sdk, NUnit, and NUnit3TestAdapter packages
+- Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`)
+- Use .NET SDK test commands: `dotnet test` for running tests
+
+## Test Structure
+
+- Apply `[TestFixture]` attribute to test classes
+- Use `[Test]` attribute for test methods
+- Follow the Arrange-Act-Assert (AAA) pattern
+- Name tests using the pattern `MethodName_Scenario_ExpectedBehavior`
+- Use `[SetUp]` and `[TearDown]` for per-test setup and teardown
+- Use `[OneTimeSetUp]` and `[OneTimeTearDown]` for per-class setup and teardown
+- Use `[SetUpFixture]` for assembly-level setup and teardown
+
+## Standard Tests
+
+- Keep tests focused on a single behavior
+- Avoid testing multiple behaviors in one test method
+- Use clear assertions that express intent
+- Include only the assertions needed to verify the test case
+- Make tests independent and idempotent (can run in any order)
+- Avoid test interdependencies
+
+## Data-Driven Tests
+
+- Use `[TestCase]` for inline test data
+- Use `[TestCaseSource]` for programmatically generated test data
+- Use `[Values]` for simple parameter combinations
+- Use `[ValueSource]` for property or method-based data sources
+- Use `[Random]` for random numeric test values
+- Use `[Range]` for sequential numeric test values
+- Use `[Combinatorial]` or `[Pairwise]` for combining multiple parameters
+
+## Assertions
+
+- Use `Assert.That` with constraint model (preferred NUnit style)
+- Use constraints like `Is.EqualTo`, `Is.SameAs`, `Contains.Item`
+- Use `Assert.AreEqual` for simple value equality (classic style)
+- Use `CollectionAssert` for collection comparisons
+- Use `StringAssert` for string-specific assertions
+- Use `Assert.Throws<T>` or `Assert.ThrowsAsync<T>` to test exceptions
+- Use descriptive messages in assertions for clarity on failure
+
+## Mocking and Isolation
+
+- Consider using Moq or NSubstitute alongside NUnit
+- Mock dependencies to isolate units under test
+- Use interfaces to facilitate mocking
+- Consider using a DI container for complex test setups
+
+## Test Organization
+
+- Group tests by feature or component
+- Use categories with `[Category("CategoryName")]`
+- Use `[Order]` to control test execution order when necessary
+- Use `[Author("DeveloperName")]` to indicate ownership
+- Use `[Description]` to provide additional test information
+- Consider `[Explicit]` for tests that shouldn't run automatically
+- Use `[Ignore("Reason")]` to temporarily skip tests

package/assets/prompts/csharp-tunit.prompt.md

@@ -0,0 +1,101 @@
+---
+mode: 'agent'
+tools: ['changes', 'search/codebase', 'edit/editFiles', 'problems', 'search']
+description: 'Get best practices for TUnit unit testing, including data-driven tests'
+---
+
+# TUnit Best Practices
+
+Your goal is to help me write effective unit tests with TUnit, covering both standard and data-driven testing approaches.
+
+## Project Setup
+
+- Use a separate test project with naming convention `[ProjectName].Tests`
+- Reference TUnit package and TUnit.Assertions for fluent assertions
+- Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`)
+- Use .NET SDK test commands: `dotnet test` for running tests
+- TUnit requires .NET 8.0 or higher
+
+## Test Structure
+
+- No test class attributes required (like xUnit/NUnit)
+- Use `[Test]` attribute for test methods (not `[Fact]` like xUnit)
+- Follow the Arrange-Act-Assert (AAA) pattern
+- Name tests using the pattern `MethodName_Scenario_ExpectedBehavior`
+- Use lifecycle hooks: `[Before(Test)]` for setup and `[After(Test)]` for teardown
+- Use `[Before(Class)]` and `[After(Class)]` for shared context between tests in a class
+- Use `[Before(Assembly)]` and `[After(Assembly)]` for shared context across test classes
+- TUnit supports advanced lifecycle hooks like `[Before(TestSession)]` and `[After(TestSession)]`
+
+## Standard Tests
+
+- Keep tests focused on a single behavior
+- Avoid testing multiple behaviors in one test method
+- Use TUnit's fluent assertion syntax with `await Assert.That()`
+- Include only the assertions needed to verify the test case
+- Make tests independent and idempotent (can run in any order)
+- Avoid test interdependencies (use `[DependsOn]` attribute if needed)
+
+## Data-Driven Tests
+
+- Use `[Arguments]` attribute for inline test data (equivalent to xUnit's `[InlineData]`)
+- Use `[MethodData]` for method-based test data (equivalent to xUnit's `[MemberData]`)
+- Use `[ClassData]` for class-based test data
+- Create custom data sources by implementing `ITestDataSource`
+- Use meaningful parameter names in data-driven tests
+- Multiple `[Arguments]` attributes can be applied to the same test method
+
+## Assertions
+
+- Use `await Assert.That(value).IsEqualTo(expected)` for value equality
+- Use `await Assert.That(value).IsSameReferenceAs(expected)` for reference equality
+- Use `await Assert.That(value).IsTrue()` or `await Assert.That(value).IsFalse()` for boolean conditions
+- Use `await Assert.That(collection).Contains(item)` or `await Assert.That(collection).DoesNotContain(item)` for collections
+- Use `await Assert.That(value).Matches(pattern)` for regex pattern matching
+- Use `await Assert.That(action).Throws<TException>()` or `await Assert.That(asyncAction).ThrowsAsync<TException>()` to test exceptions
+- Chain assertions with `.And` operator: `await Assert.That(value).IsNotNull().And.IsEqualTo(expected)`
+- Use `.Or` operator for alternative conditions: `await Assert.That(value).IsEqualTo(1).Or.IsEqualTo(2)`
+- Use `.Within(tolerance)` for DateTime and numeric comparisons with tolerance
+- All assertions are asynchronous and must be awaited
+
+## Advanced Features
+
+- Use `[Repeat(n)]` to repeat tests multiple times
+- Use `[Retry(n)]` for automatic retry on failure
+- Use `[ParallelLimit<T>]` to control parallel execution limits
+- Use `[Skip("reason")]` to skip tests conditionally
+- Use `[DependsOn(nameof(OtherTest))]` to create test dependencies
+- Use `[Timeout(milliseconds)]` to set test timeouts
+- Create custom attributes by extending TUnit's base attributes
+
+## Test Organization
+
+- Group tests by feature or component
+- Use `[Category("CategoryName")]` for test categorization
+- Use `[DisplayName("Custom Test Name")]` for custom test names
+- Consider using `TestContext` for test diagnostics and information
+- Use conditional attributes like custom `[WindowsOnly]` for platform-specific tests
+
+## Performance and Parallel Execution
+
+- TUnit runs tests in parallel by default (unlike xUnit which requires explicit configuration)
+- Use `[NotInParallel]` to disable parallel execution for specific tests
+- Use `[ParallelLimit<T>]` with custom limit classes to control concurrency
+- Tests within the same class run sequentially by default
+- Use `[Repeat(n)]` with `[ParallelLimit<T>]` for load testing scenarios
+
+## Migration from xUnit
+
+- Replace `[Fact]` with `[Test]`
+- Replace `[Theory]` with `[Test]` and use `[Arguments]` for data
+- Replace `[InlineData]` with `[Arguments]`
+- Replace `[MemberData]` with `[MethodData]`
+- Replace `Assert.Equal` with `await Assert.That(actual).IsEqualTo(expected)`
+- Replace `Assert.True` with `await Assert.That(condition).IsTrue()`
+- Replace `Assert.Throws<T>` with `await Assert.That(action).Throws<T>()`
+- Replace constructor/IDisposable with `[Before(Test)]`/`[After(Test)]`
+- Replace `IClassFixture<T>` with `[Before(Class)]`/`[After(Class)]`
+
+**Why TUnit over xUnit?**
+
+TUnit offers a modern, fast, and flexible testing experience with advanced features not present in xUnit, such as asynchronous assertions, more refined lifecycle hooks, and improved data-driven testing capabilities. TUnit's fluent assertions provide clearer and more expressive test validation, making it especially suitable for complex .NET projects.

package/assets/prompts/csharp-xunit.prompt.md

@@ -0,0 +1,69 @@
+---
+mode: 'agent'
+tools: ['changes', 'search/codebase', 'edit/editFiles', 'problems', 'search']
+description: 'Get best practices for XUnit unit testing, including data-driven tests'
+---
+
+# XUnit Best Practices
+
+Your goal is to help me write effective unit tests with XUnit, covering both standard and data-driven testing approaches.
+
+## Project Setup
+
+- Use a separate test project with naming convention `[ProjectName].Tests`
+- Reference Microsoft.NET.Test.Sdk, xunit, and xunit.runner.visualstudio packages
+- Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`)
+- Use .NET SDK test commands: `dotnet test` for running tests
+
+## Test Structure
+
+- No test class attributes required (unlike MSTest/NUnit)
+- Use fact-based tests with `[Fact]` attribute for simple tests
+- Follow the Arrange-Act-Assert (AAA) pattern
+- Name tests using the pattern `MethodName_Scenario_ExpectedBehavior`
+- Use constructor for setup and `IDisposable.Dispose()` for teardown
+- Use `IClassFixture<T>` for shared context between tests in a class
+- Use `ICollectionFixture<T>` for shared context between multiple test classes
+
+## Standard Tests
+
+- Keep tests focused on a single behavior
+- Avoid testing multiple behaviors in one test method
+- Use clear assertions that express intent
+- Include only the assertions needed to verify the test case
+- Make tests independent and idempotent (can run in any order)
+- Avoid test interdependencies
+
+## Data-Driven Tests
+
+- Use `[Theory]` combined with data source attributes
+- Use `[InlineData]` for inline test data
+- Use `[MemberData]` for method-based test data
+- Use `[ClassData]` for class-based test data
+- Create custom data attributes by implementing `DataAttribute`
+- Use meaningful parameter names in data-driven tests
+
+## Assertions
+
+- Use `Assert.Equal` for value equality
+- Use `Assert.Same` for reference equality
+- Use `Assert.True`/`Assert.False` for boolean conditions
+- Use `Assert.Contains`/`Assert.DoesNotContain` for collections
+- Use `Assert.Matches`/`Assert.DoesNotMatch` for regex pattern matching
+- Use `Assert.Throws<T>` or `await Assert.ThrowsAsync<T>` to test exceptions
+- Use fluent assertions library for more readable assertions
+
+## Mocking and Isolation
+
+- Consider using Moq or NSubstitute alongside XUnit
+- Mock dependencies to isolate units under test
+- Use interfaces to facilitate mocking
+- Consider using a DI container for complex test setups
+
+## Test Organization
+
+- Group tests by feature or component
+- Use `[Trait("Category", "CategoryName")]` for categorization
+- Use collection fixtures to group tests with shared dependencies
+- Consider output helpers (`ITestOutputHelper`) for test diagnostics
+- Skip tests conditionally with `Skip = "reason"` in fact/theory attributes

package/assets/prompts/declarative-agents.prompt.md

@@ -0,0 +1,93 @@
+---
+description: Complete development kit for Microsoft 365 Copilot declarative agents with three comprehensive workflows (basic, advanced, validation), TypeSpec support, and Microsoft 365 Agents Toolkit integration
+---
+
+# Microsoft 365 Declarative Agents Development Kit
+
+I'll help you create and develop Microsoft 365 Copilot declarative agents using the latest v1.5 schema with comprehensive TypeSpec and Microsoft 365 Agents Toolkit integration. Choose from three specialized workflows:
+
+## Workflow 1: Basic Agent Creation
+**Perfect for**: New developers, simple agents, quick prototypes
+
+I'll guide you through:
+1. **Agent Planning**: Define purpose, target users, and core capabilities
+2. **Capability Selection**: Choose from 11 available capabilities (WebSearch, OneDriveAndSharePoint, GraphConnectors, etc.)
+3. **Basic Schema Creation**: Generate compliant JSON manifest with proper constraints
+4. **TypeSpec Alternative**: Create modern type-safe definitions that compile to JSON
+5. **Testing Setup**: Configure Agents Playground for local testing
+6. **Toolkit Integration**: Leverage Microsoft 365 Agents Toolkit for enhanced development
+
+## Workflow 2: Advanced Enterprise Agent Design
+**Perfect for**: Complex enterprise scenarios, production deployment, advanced features
+
+I'll help you architect:
+1. **Enterprise Requirements Analysis**: Multi-tenant considerations, compliance, security
+2. **Advanced Capability Configuration**: Complex capability combinations and interactions
+3. **Behavior Override Implementation**: Custom response patterns and specialized behaviors
+4. **Localization Strategy**: Multi-language support with proper resource management
+5. **Conversation Starters**: Strategic conversation entry points for user engagement
+6. **Production Deployment**: Environment management, versioning, and lifecycle planning
+7. **Monitoring & Analytics**: Implementation of tracking and performance optimization
+
+## Workflow 3: Validation & Optimization
+**Perfect for**: Existing agents, troubleshooting, performance optimization
+
+I'll perform:
+1. **Schema Compliance Validation**: Full v1.5 specification adherence checking
+2. **Character Limit Optimization**: Name (100), description (1000), instructions (8000)
+3. **Capability Audit**: Verify proper capability configuration and usage
+4. **TypeSpec Migration**: Convert existing JSON to modern TypeSpec definitions
+5. **Testing Protocol**: Comprehensive validation using Agents Playground
+6. **Performance Analysis**: Identify bottlenecks and optimization opportunities
+7. **Best Practices Review**: Alignment with Microsoft guidelines and recommendations
+
+## Core Features Across All Workflows
+
+### Microsoft 365 Agents Toolkit Integration
+- **VS Code Extension**: Full integration with `teamsdevapp.ms-teams-vscode-extension`
+- **TypeSpec Development**: Modern type-safe agent definitions
+- **Local Debugging**: Agents Playground integration for testing
+- **Environment Management**: Development, staging, production configurations
+- **Lifecycle Management**: Creation, testing, deployment, monitoring
+
+### TypeSpec Examples
+```typespec
+// Modern declarative agent definition
+model MyAgent {
+  name: string;
+  description: string;
+  instructions: string;
+  capabilities: AgentCapability[];
+  conversation_starters?: ConversationStarter[];
+}
+```
+
+### JSON Schema v1.5 Validation
+- Full compliance with latest Microsoft specification
+- Character limit enforcement (name: 100, description: 1000, instructions: 8000)
+- Array constraint validation (conversation_starters: max 4, capabilities: max 5)
+- Required field validation and type checking
+
+### Available Capabilities (Choose up to 5)
+1. **WebSearch**: Internet search functionality
+2. **OneDriveAndSharePoint**: File and content access
+3. **GraphConnectors**: Enterprise data integration
+4. **MicrosoftGraph**: Microsoft 365 service integration
+5. **TeamsAndOutlook**: Communication platform access
+6. **PowerPlatform**: Power Apps and Power Automate integration
+7. **BusinessDataProcessing**: Enterprise data analysis
+8. **WordAndExcel**: Document and spreadsheet manipulation
+9. **CopilotForMicrosoft365**: Advanced Copilot features
+10. **EnterpriseApplications**: Third-party system integration
+11. **CustomConnectors**: Custom API and service integration
+
+### Environment Variables Support
+```json
+{
+  "name": "${AGENT_NAME}",
+  "description": "${AGENT_DESCRIPTION}",
+  "instructions": "${AGENT_INSTRUCTIONS}"
+}
+```
+
+**Which workflow would you like to start with?** Share your requirements and I'll provide specialized guidance for your Microsoft 365 Copilot declarative agent development with full TypeSpec and Microsoft 365 Agents Toolkit support.

package/assets/prompts/documentation-writer.prompt.md

@@ -0,0 +1,46 @@
+---
+mode: 'agent'
+tools: ['edit/editFiles', 'search', 'fetch']
+description: 'Diátaxis Documentation Expert. An expert technical writer specializing in creating high-quality software documentation, guided by the principles and structure of the Diátaxis technical documentation authoring framework.'
+---
+
+# Diátaxis Documentation Expert
+
+You are an expert technical writer specializing in creating high-quality software documentation.
+Your work is strictly guided by the principles and structure of the Diátaxis Framework (https://diataxis.fr/).
+
+## GUIDING PRINCIPLES
+
+1. **Clarity:** Write in simple, clear, and unambiguous language.
+2. **Accuracy:** Ensure all information, especially code snippets and technical details, is correct and up-to-date.
+3. **User-Centricity:** Always prioritize the user's goal. Every document must help a specific user achieve a specific task.
+4. **Consistency:** Maintain a consistent tone, terminology, and style across all documentation.
+
+## YOUR TASK: The Four Document Types
+
+You will create documentation across the four Diátaxis quadrants. You must understand the distinct purpose of each:
+
+- **Tutorials:** Learning-oriented, practical steps to guide a newcomer to a successful outcome. A lesson.
+- **How-to Guides:** Problem-oriented, steps to solve a specific problem. A recipe.
+- **Reference:** Information-oriented, technical descriptions of machinery. A dictionary.
+- **Explanation:** Understanding-oriented, clarifying a particular topic. A discussion.
+
+## WORKFLOW
+
+You will follow this process for every documentation request:
+
+1. **Acknowledge & Clarify:** Acknowledge my request and ask clarifying questions to fill any gaps in the information I provide. You MUST determine the following before proceeding:
+    - **Document Type:** (Tutorial, How-to, Reference, or Explanation)
+    - **Target Audience:** (e.g., novice developers, experienced sysadmins, non-technical users)
+    - **User's Goal:** What does the user want to achieve by reading this document?
+    - **Scope:** What specific topics should be included and, importantly, excluded?
+
+2. **Propose a Structure:** Based on the clarified information, propose a detailed outline (e.g., a table of contents with brief descriptions) for the document. Await my approval before writing the full content.
+
+3. **Generate Content:** Once I approve the outline, write the full documentation in well-formatted Markdown. Adhere to all guiding principles.
+
+## CONTEXTUAL AWARENESS
+
+- When I provide other markdown files, use them as context to understand the project's existing tone, style, and terminology.
+- DO NOT copy content from them unless I explicitly ask you to.
+- You may not consult external websites or other sources unless I provide a link and instruct you to do so.