From e19314c548179ed5bae0adeb8d2fecc3c35bd2e2 Mon Sep 17 00:00:00 2001 From: Wallace Breza Date: Wed, 3 Sep 2025 15:57:16 -0700 Subject: [PATCH 1/5] Adds agent improvements --- cli/azd/cmd/init.go | 72 +++++++++++++------ cli/azd/internal/agent/agent_factory.go | 22 ++++-- .../internal/agent/prompts/conversational.txt | 24 +++---- .../prompts/azd_architecture_planning.md | 15 ++-- .../prompts/azd_infrastructure_generation.md | 41 +++++------ 5 files changed, 106 insertions(+), 68 deletions(-) diff --git a/cli/azd/cmd/init.go b/cli/azd/cmd/init.go index 95045b8843d..8e104d3a449 100644 --- a/cli/azd/cmd/init.go +++ b/cli/azd/cmd/init.go @@ -437,26 +437,18 @@ Do not stop until all tasks are complete and fully resolved. } } - // Run Step + // Run Step with retry logic i.console.Message(ctx, color.MagentaString(step.Name)) fullTaskInput := fmt.Sprintf(taskInput, strings.Join([]string{ step.Description, "Provide a very brief summary in markdown format that includes any files generated during this step.", }, "\n")) - agentOutput, err := azdAgent.SendMessage(ctx, fullTaskInput) - if err != nil { - if agentOutput != "" { - i.console.Message(ctx, output.WithMarkdown(agentOutput)) - } - + if err := i.sendMessageWithRetry(ctx, azdAgent, fullTaskInput); err != nil { return err } i.console.Message(ctx, "") - i.console.Message(ctx, fmt.Sprintf("%s:", output.AzdAgentLabel())) - i.console.Message(ctx, output.WithMarkdown(agentOutput)) - i.console.Message(ctx, "") } // Post-completion feedback loop @@ -467,6 +459,29 @@ Do not stop until all tasks are complete and fully resolved. return nil } +// handleErrorWithRetryPrompt displays an error and prompts user for retry +func (i *initAction) handleErrorWithRetryPrompt(ctx context.Context, err error) bool { + // Display error in error format + i.console.Message(ctx, "") + i.console.Message(ctx, output.WithErrorFormat("Error occurred: %s", err.Error())) + i.console.Message(ctx, "") + + // Prompt user if they want to try again + retryPrompt := uxlib.NewConfirm(&uxlib.ConfirmOptions{ + Message: "Would you like to try again?", + DefaultValue: uxlib.Ptr(true), + HelpMessage: "Choose 'yes' to retry the current step, or 'no' to stop the initialization.", + }) + + shouldRetry, promptErr := retryPrompt.Ask(ctx) + if promptErr != nil { + // If we can't prompt, don't retry + return false + } + + return shouldRetry != nil && *shouldRetry +} + // collectAndApplyFeedback prompts for user feedback and applies it using the agent in a loop func (i *initAction) collectAndApplyFeedback( ctx context.Context, @@ -508,24 +523,41 @@ func (i *initAction) collectAndApplyFeedback( if userInput != "" { i.console.Message(ctx, color.MagentaString("Feedback")) - feedbackOutput, err := azdAgent.SendMessage(ctx, userInput) - if err != nil { - if feedbackOutput != "" { - i.console.Message(ctx, output.WithMarkdown(feedbackOutput)) - } + // Apply feedback with retry logic + if err := i.sendMessageWithRetry(ctx, azdAgent, userInput); err != nil { return err } - - i.console.Message(ctx, "") - i.console.Message(ctx, fmt.Sprintf("%s:", output.AzdAgentLabel())) - i.console.Message(ctx, output.WithMarkdown(feedbackOutput)) - i.console.Message(ctx, "") } } return nil } +// sendMessageWithRetry sends a message to the agent with retry logic for error recovery +func (i *initAction) sendMessageWithRetry(ctx context.Context, azdAgent agent.Agent, input string) error { + for { + agentOutput, err := azdAgent.SendMessage(ctx, input) + if err != nil { + if agentOutput != "" { + i.console.Message(ctx, output.WithMarkdown(agentOutput)) + } + + // Display error and ask if user wants to retry + if shouldRetry := i.handleErrorWithRetryPrompt(ctx, err); shouldRetry { + continue // Retry the same operation + } + return err // User chose not to retry, return original error + } + + // Success - display output and return + i.console.Message(ctx, "") + i.console.Message(ctx, fmt.Sprintf("%s:", output.AzdAgentLabel())) + i.console.Message(ctx, output.WithMarkdown(agentOutput)) + i.console.Message(ctx, "") + return nil + } +} + // postCompletionFeedbackLoop provides a final opportunity for feedback after all steps complete func (i *initAction) postCompletionFeedbackLoop( ctx context.Context, diff --git a/cli/azd/internal/agent/agent_factory.go b/cli/azd/internal/agent/agent_factory.go index 532c3ef31ad..6623c3aadd2 100644 --- a/cli/azd/internal/agent/agent_factory.go +++ b/cli/azd/internal/agent/agent_factory.go @@ -91,7 +91,17 @@ func (f *AgentFactory) Create(opts ...AgentCreateOption) (Agent, error) { // Add more excluded tools here as needed } - allTools := []common.AnnotatedTool{} + includedTools := map[string]bool{ + "bestpractices": true, + "bicepschema": true, + "cloudarchitect": true, + "documentation": true, + "group": true, + "role": true, + "subscription": true, + } + + filteredTools := []common.AnnotatedTool{} for _, toolLoader := range toolLoaders { categoryTools, err := toolLoader.LoadTools() @@ -102,14 +112,18 @@ func (f *AgentFactory) Create(opts ...AgentCreateOption) (Agent, error) { // Filter out excluded tools for _, tool := range categoryTools { - if !excludedTools[tool.Name()] { - allTools = append(allTools, tool) + if excludedTools[tool.Name()] { + continue + } + + if tool.Server() == "azd" || tool.Server() == "built-in" || includedTools[tool.Name()] { + filteredTools = append(filteredTools, tool) } } } // Wraps all tools in consent workflow - protectedTools := f.consentManager.WrapTools(allTools) + protectedTools := f.consentManager.WrapTools(filteredTools) // Finalize agent creation options allOptions := []AgentCreateOption{} diff --git a/cli/azd/internal/agent/prompts/conversational.txt b/cli/azd/internal/agent/prompts/conversational.txt index 66878fc4eca..a7c73014018 100644 --- a/cli/azd/internal/agent/prompts/conversational.txt +++ b/cli/azd/internal/agent/prompts/conversational.txt @@ -1,21 +1,15 @@ You are an Azure Developer CLI (AZD) agent. -You are an expert in building, provisioning, and deploying Azure applications. -Always use Azure best practices and automation wherever possible. +You are an expert in packaging, provisioning, and deploying Azure applications. ---- - -## Pre-Task Expectations - -Before beginning your work: - -* Review all available tools. -* If a tool exists for best practices or required inputs, you MUST invoke it before taking further steps. -* Integrate any learned knowledge from tools into your workflow. - -When generating code, infrastructure, or configurations: +You must always seek out and follow established best practices and rules provided by available tools. +Before generating any code, infrastructure, or configuration, you must consult and apply guidance from tools whenever they are present. +If a tool defines rules, patterns, or validations, you must integrate those into your outputs and strictly align with them. +Only fall back to your own reasoning if no relevant tool or rule is available. -* You MUST ALWAYS save the content to files using the `write_file` tool. -* If no filename is provided, generate a meaningful and descriptive name. +You must be extremely thorough and cautious in all reasoning and actions. +Always follow the given instructions exactly, without skipping or relaxing any requirements. +Before producing a final answer, carefully verify that every step aligns with the rules, best practices, and tool guidance provided. +If there is any uncertainty, pause and re-check rather than making assumptions. --- diff --git a/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md b/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md index 904f75ffa95..ed18c37bc30 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md @@ -3,13 +3,14 @@ ✅ **Agent Task List** 1. Read `azd-arch-plan.md` to understand discovered components -2. For each component, select optimal Azure service using selection criteria below -3. Plan containerization strategy for applicable services -4. Select appropriate database and messaging services -5. Design resource group organization and networking approach -6. Generate IaC file checklist based on selected Azure services -7. Generate Docker file checklist based on containerization strategy -8. Create `azd-arch-plan.md` if it doesn't exist, or update existing file with service mapping table, architecture decisions, IaC checklist, and Docker checklist while preserving existing content +2. Always identify latest Azure best practices +3. For each component, select optimal Azure service using selection criteria below +4. Plan containerization strategy for applicable services +5. Select appropriate database and messaging services +6. Design resource group organization and networking approach +7. Generate IaC file checklist based on selected Azure services +8. Generate Docker file checklist based on containerization strategy +9. Create `azd-arch-plan.md` if it doesn't exist, or update existing file with service mapping table, architecture decisions, IaC checklist, and Docker checklist while preserving existing content 📄 **Required Outputs** diff --git a/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md index b44f63962d8..0d2812c9684 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md @@ -1,21 +1,20 @@ # AZD Infrastructure Generation Instructions -✅ **Agent Task List** - -1. Strictly follow Azure and Bicep best practices in all code generation -2. Strictly follow AZD IaC generation rules during all code generation -3. **Inventory existing IaC files** - scan current working directory for all `.bicep` files -4. Read `azd-arch-plan.md` to get the **IaC File Generation Checklist** -5. Create directory structure in `./infra` following IaC rules -6. During code generation always use the latest version for each resource type using the bicep schema tool -7. For each file in the IaC checklist: +✅ **Agent Task List** + +1. **Inventory existing IaC files** - scan current working directory for all `.bicep` files +2. Read `azd-arch-plan.md` to get the **IaC File Generation Checklist** +3. Create directory structure in `./infra` following IaC rules +4. Before generating any code, always fetch Azure and Bicep best practices +5. Before generating any code, always get the latest bicep schema and version for each Azure resource type +6. For each file in the IaC checklist: - **If file exists**: Intelligently update to match requirements, preserve user customizations where possible - **If file missing**: Generate new file following templates and best practices - **Flag conflicts**: Note any incompatible configurations but proceed with updates -8. Validate all generated bicep templates compile without errors or warnings -9. Update the IaC checklist section in existing `azd-arch-plan.md` by marking completed files as [x] while preserving existing content +7. Validate all generated bicep templates compile without errors or warnings +8. Update the IaC checklist section in existing `azd-arch-plan.md` by marking completed files as [x] while preserving existing content -📄 **Required Outputs** +📄 **Required Outputs** - **Existing IaC inventory** documenting all current `.bicep` files found - Complete Bicep template structure in `./infra` directory based on the IaC checklist @@ -27,12 +26,7 @@ - All templates validated and error-free - Update existing `azd-arch-plan.md` IaC checklist by marking completed files as [x] while preserving existing content -🧠 **Execution Guidelines** - -**Use Tools:** - -- Use AZD IaC generation rules tool first to get complete file structure, naming conventions, and compliance requirements. -- Use Bicep Schema tool get get the latest API version and bicep schema for each resource type +🧠 **Execution Guidelines** **Inventory Existing IaC Files:** @@ -58,6 +52,7 @@ **For New Files:** +- Always identify and use the latest bicep schema version for all Azure resource types - Create from templates following IaC generation rules - Follow standard naming conventions and patterns @@ -79,6 +74,9 @@ The `./infra/main.parameters.json` file is critical for AZD integration and must follow this exact structure: +- All parameter values in main.parameters.json must use AZD environment variable expansion syntax (e.g., ${AZURE_LOCATION} ). +- No hard-coded values are allowed for parameters that can be set via environment variables. + ```json { "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#", @@ -99,7 +97,7 @@ The `./infra/main.parameters.json` file is critical for AZD integration and must **Key Features:** -- **Environment Variable Substitution**: Uses `${VARIABLE_NAME}` syntax for dynamic values +- **Environment Variable Expansion**: Use `${VARIABLE_NAME}` syntax for dynamic values - **Standard Parameters**: Always include `environmentName`, `location`, and `principalId` - **AZD Integration**: These variables are automatically populated by AZD during deployment - **Additional Parameters**: Add service-specific parameters as needed, using the same substitution pattern @@ -147,9 +145,8 @@ The `./infra/main.parameters.json` file is critical for AZD integration and must - Call modules conditionally based on service requirements - Output connection strings and service endpoints -📌 **Completion Checklist** +📌 **Completion Checklist** -- [ ] `azd_iac_generation_rules` tool referenced for complete compliance requirements - [ ] **Existing IaC inventory completed** - all `.bicep` files in current directory catalogued - [ ] **IaC File Generation Checklist read** from `azd-arch-plan.md` - [ ] **Update vs. create strategy determined** for each file in checklist @@ -162,5 +159,5 @@ The `./infra/main.parameters.json` file is critical for AZD integration and must - [ ] Parameter files created/updated with appropriate defaults - [ ] Naming conventions and tagging implemented correctly - [ ] Security best practices implemented (Key Vault, managed identities) +- [ ] All Bicep modules are created with latest bicep schema version and meet Azure and Bicep best practices - [ ] **IaC checklist in `azd-arch-plan.md` updated** by marking completed files as [x] while preserving existing content - From 90a19cd39d489bebbc01bde40d664f20fdf168df Mon Sep 17 00:00:00 2001 From: Wallace Breza Date: Tue, 9 Sep 2025 13:31:00 -0700 Subject: [PATCH 2/5] Adds WIP tools --- cli/azd/internal/mcp/tools/azd_appcode_generation.go | 0 cli/azd/internal/mcp/tools/azd_artifact_generation.go | 0 cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go | 0 cli/azd/internal/mcp/tools/azd_identify_user_intent.go | 0 cli/azd/internal/mcp/tools/azd_list_stack_resources.go | 0 cli/azd/internal/mcp/tools/azd_modernize_project.go | 0 cli/azd/internal/mcp/tools/azd_new_project.go | 0 cli/azd/internal/mcp/tools/azd_select_stack.go | 0 cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md | 0 cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md | 0 cli/azd/internal/mcp/tools/prompts/azd_generate_project_spec.md | 0 cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md | 0 cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md | 0 cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md | 0 cli/azd/internal/mcp/tools/prompts/azd_new_project.md | 0 cli/azd/internal/mcp/tools/prompts/azd_select_stack.md | 0 cli/azd/internal/mcp/tools/resources/app-spec-template.md | 0 cli/azd/internal/mcp/tools/resources/baseline_resources.md | 0 .../internal/mcp/tools/resources/containers_stack_resources.md | 0 .../internal/mcp/tools/resources/logic_apps_stack_resources.md | 0 .../internal/mcp/tools/resources/serverless_stack_resources.md | 0 21 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 cli/azd/internal/mcp/tools/azd_appcode_generation.go create mode 100644 cli/azd/internal/mcp/tools/azd_artifact_generation.go create mode 100644 cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go create mode 100644 cli/azd/internal/mcp/tools/azd_identify_user_intent.go create mode 100644 cli/azd/internal/mcp/tools/azd_list_stack_resources.go create mode 100644 cli/azd/internal/mcp/tools/azd_modernize_project.go create mode 100644 cli/azd/internal/mcp/tools/azd_new_project.go create mode 100644 cli/azd/internal/mcp/tools/azd_select_stack.go create mode 100644 cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md create mode 100644 cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md create mode 100644 cli/azd/internal/mcp/tools/prompts/azd_generate_project_spec.md create mode 100644 cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md create mode 100644 cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md create mode 100644 cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md create mode 100644 cli/azd/internal/mcp/tools/prompts/azd_new_project.md create mode 100644 cli/azd/internal/mcp/tools/prompts/azd_select_stack.md create mode 100644 cli/azd/internal/mcp/tools/resources/app-spec-template.md create mode 100644 cli/azd/internal/mcp/tools/resources/baseline_resources.md create mode 100644 cli/azd/internal/mcp/tools/resources/containers_stack_resources.md create mode 100644 cli/azd/internal/mcp/tools/resources/logic_apps_stack_resources.md create mode 100644 cli/azd/internal/mcp/tools/resources/serverless_stack_resources.md diff --git a/cli/azd/internal/mcp/tools/azd_appcode_generation.go b/cli/azd/internal/mcp/tools/azd_appcode_generation.go new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/azd_artifact_generation.go b/cli/azd/internal/mcp/tools/azd_artifact_generation.go new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go b/cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/azd_identify_user_intent.go b/cli/azd/internal/mcp/tools/azd_identify_user_intent.go new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/azd_list_stack_resources.go b/cli/azd/internal/mcp/tools/azd_list_stack_resources.go new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/azd_modernize_project.go b/cli/azd/internal/mcp/tools/azd_modernize_project.go new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/azd_new_project.go b/cli/azd/internal/mcp/tools/azd_new_project.go new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/azd_select_stack.go b/cli/azd/internal/mcp/tools/azd_select_stack.go new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/prompts/azd_generate_project_spec.md b/cli/azd/internal/mcp/tools/prompts/azd_generate_project_spec.md new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md b/cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md b/cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md b/cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/prompts/azd_new_project.md b/cli/azd/internal/mcp/tools/prompts/azd_new_project.md new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/prompts/azd_select_stack.md b/cli/azd/internal/mcp/tools/prompts/azd_select_stack.md new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/resources/app-spec-template.md b/cli/azd/internal/mcp/tools/resources/app-spec-template.md new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/resources/baseline_resources.md b/cli/azd/internal/mcp/tools/resources/baseline_resources.md new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/resources/containers_stack_resources.md b/cli/azd/internal/mcp/tools/resources/containers_stack_resources.md new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/resources/logic_apps_stack_resources.md b/cli/azd/internal/mcp/tools/resources/logic_apps_stack_resources.md new file mode 100644 index 00000000000..e69de29bb2d diff --git a/cli/azd/internal/mcp/tools/resources/serverless_stack_resources.md b/cli/azd/internal/mcp/tools/resources/serverless_stack_resources.md new file mode 100644 index 00000000000..e69de29bb2d From fb9c714cb03ed80241da9dd8071642e3c4f7f0fa Mon Sep 17 00:00:00 2001 From: Wallace Breza Date: Tue, 9 Sep 2025 14:27:25 -0700 Subject: [PATCH 3/5] WIP --- cli/azd/cmd/mcp.go | 8 + .../mcp/tools/azd_appcode_generation.go | 42 +++ .../mcp/tools/azd_artifact_generation.go | 42 +++ .../mcp/tools/azd_discovery_analysis.go | 2 +- .../azd_generate_project_spec_template.go | 99 +++++ .../mcp/tools/azd_identify_user_intent.go | 42 +++ .../mcp/tools/azd_list_stack_resources.go | 111 ++++++ .../mcp/tools/azd_modernize_project.go | 42 +++ cli/azd/internal/mcp/tools/azd_new_project.go | 42 +++ cli/azd/internal/mcp/tools/azd_plan_init.go | 18 +- .../internal/mcp/tools/azd_select_stack.go | 42 +++ .../tools/prompts/azd_appcode_generation.md | 356 ++++++++++++++++++ .../prompts/azd_architecture_planning.md | 213 ++++++----- .../tools/prompts/azd_artifact_generation.md | 278 ++++++++++++++ .../prompts/azd_azure_yaml_generation.md | 8 +- .../tools/prompts/azd_docker_generation.md | 16 +- .../tools/prompts/azd_identify_user_intent.md | 166 ++++++++ .../prompts/azd_infrastructure_generation.md | 90 +++-- .../tools/prompts/azd_list_stack_resources.md | 48 +++ .../tools/prompts/azd_modernize_project.md | 227 +++++++++++ .../mcp/tools/prompts/azd_new_project.md | 227 +++++++++++ .../mcp/tools/prompts/azd_plan_init.md | 228 +++++++---- .../mcp/tools/prompts/azd_select_stack.md | 194 ++++++++++ cli/azd/internal/mcp/tools/prompts/prompts.go | 18 + .../mcp/tools/resources/app-spec-template.md | 295 +++++++++++++++ .../mcp/tools/resources/baseline_resources.md | 5 + .../resources/containers_stack_resources.md | 3 + .../resources/logic_apps_stack_resources.md | 2 + .../resources/serverless_stack_resources.md | 2 + 29 files changed, 2665 insertions(+), 201 deletions(-) diff --git a/cli/azd/cmd/mcp.go b/cli/azd/cmd/mcp.go index 332448e1d94..2e9308036dc 100644 --- a/cli/azd/cmd/mcp.go +++ b/cli/azd/cmd/mcp.go @@ -154,8 +154,16 @@ func (a *mcpStartAction) Run(ctx context.Context) (*actions.ActionResult, error) allTools := []server.ServerTool{ tools.NewAzdPlanInitTool(), + tools.NewAzdIdentifyUserIntentTool(), + tools.NewAzdSelectStackTool(), + tools.NewAzdListStackResourcesTool(), + tools.NewAzdNewProjectTool(), + tools.NewAzdModernizeProjectTool(), tools.NewAzdDiscoveryAnalysisTool(), tools.NewAzdArchitecturePlanningTool(), + tools.NewAzdArtifactGenerationTool(), + tools.NewAzdAppCodeGenerationTool(), + tools.NewGenerateProjectSpecTemplateTool(), tools.NewAzdAzureYamlGenerationTool(), tools.NewAzdDockerGenerationTool(), tools.NewAzdInfrastructureGenerationTool(), diff --git a/cli/azd/internal/mcp/tools/azd_appcode_generation.go b/cli/azd/internal/mcp/tools/azd_appcode_generation.go index e69de29bb2d..799ca43bfa9 100644 --- a/cli/azd/internal/mcp/tools/azd_appcode_generation.go +++ b/cli/azd/internal/mcp/tools/azd_appcode_generation.go @@ -0,0 +1,42 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + + "github.com/azure/azure-dev/cli/azd/internal/mcp/tools/prompts" + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +// NewAzdAppCodeGenerationTool creates a new azd application code generation tool +func NewAzdAppCodeGenerationTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_appcode_generation", + mcp.WithReadOnlyHintAnnotation(false), + mcp.WithIdempotentHintAnnotation(false), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Returns instructions for generating application code scaffolding for all project components +using preferred programming languages and frameworks in src/ structure. + +The LLM agent should execute these instructions using available tools. + +Use this tool when: +- Project components have been defined and technology stack selected +- Programming language and framework preferences are known +- Need to generate application scaffolding for APIs, SPAs, workers, functions, etc. +- Ready to create production-ready code templates with Azure integrations`, + ), + ), + Handler: handleAzdAppCodeGeneration, + } +} + +func handleAzdAppCodeGeneration(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + return mcp.NewToolResultText(prompts.AzdAppCodeGenerationPrompt), nil +} diff --git a/cli/azd/internal/mcp/tools/azd_artifact_generation.go b/cli/azd/internal/mcp/tools/azd_artifact_generation.go index e69de29bb2d..7b6070be40d 100644 --- a/cli/azd/internal/mcp/tools/azd_artifact_generation.go +++ b/cli/azd/internal/mcp/tools/azd_artifact_generation.go @@ -0,0 +1,42 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + + "github.com/azure/azure-dev/cli/azd/internal/mcp/tools/prompts" + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +// NewAzdArtifactGenerationTool creates a new azd artifact generation orchestration tool +func NewAzdArtifactGenerationTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_artifact_generation", + mcp.WithReadOnlyHintAnnotation(false), + mcp.WithIdempotentHintAnnotation(false), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Returns instructions for orchestrating complete AZD project artifact generation including +application scaffolding, Docker configurations, infrastructure templates, and azure.yaml configuration. + +The LLM agent should execute these instructions using available tools. + +Use this tool when: +- Project architecture and requirements have been defined in Application specification +- Ready to generate all project artifacts and implementation files +- Need to create application code, infrastructure templates, and deployment configurations +- Moving from planning phase to implementation phase`, + ), + ), + Handler: handleAzdArtifactGeneration, + } +} + +func handleAzdArtifactGeneration(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + return mcp.NewToolResultText(prompts.AzdArtifactGenerationPrompt), nil +} diff --git a/cli/azd/internal/mcp/tools/azd_discovery_analysis.go b/cli/azd/internal/mcp/tools/azd_discovery_analysis.go index 7d36397cf9d..5f963718991 100644 --- a/cli/azd/internal/mcp/tools/azd_discovery_analysis.go +++ b/cli/azd/internal/mcp/tools/azd_discovery_analysis.go @@ -30,7 +30,7 @@ Use this tool when: - Starting Phase 1 of AZD migration process - Need to identify all application components and dependencies - Codebase analysis required before architecture planning -- azd-arch-plan.md does not exist or needs updating`, +- Application spec does not exist or needs updating`, ), ), Handler: handleAzdDiscoveryAnalysis, diff --git a/cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go b/cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go index e69de29bb2d..91cc5406053 100644 --- a/cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go +++ b/cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go @@ -0,0 +1,99 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + _ "embed" + "fmt" + "os" + "strings" + "time" + + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +//go:embed resources/app-spec-template.md +var appSpecTemplateContent string + +// NewGenerateProjectSpecTemplateTool creates a new MCP tool for generating project specification templates +func NewGenerateProjectSpecTemplateTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_generate_project_spec_template", + mcp.WithReadOnlyHintAnnotation(false), + mcp.WithIdempotentHintAnnotation(true), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Generate a project specification template file (app-spec.md) in the current workspace. +This tool creates the initial template file that other tools will populate with actual +project information during the planning and implementation process. + +The template will be created at 'app-spec.md' in the current directory if it doesn't +already exist. No parameters required.`, + ), + ), + Handler: handleGenerateProjectSpecTemplate, + } +} + +func handleGenerateProjectSpecTemplate(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + const outputPath = "app-spec.md" + + // Check if file already exists + if _, err := os.Stat(outputPath); err == nil { + return mcp.NewToolResultText(fmt.Sprintf("Template file '%s' already exists in the workspace. No action taken.", outputPath)), nil + } + + // Generate current timestamp + currentTime := time.Now() + generatedDate := currentTime.Format("2006-01-02 15:04:05 MST") + + // Create the template with placeholder project name and current timestamp + templateContent := strings.ReplaceAll(appSpecTemplateContent, "{{.ProjectName}}", "[PROJECT_NAME]") + templateContent = strings.ReplaceAll(templateContent, "{{.GeneratedDate}}", generatedDate) + templateContent = strings.ReplaceAll(templateContent, "{{.LastUpdated}}", generatedDate) + + // Write the template file to the workspace + if err := os.WriteFile(outputPath, []byte(templateContent), 0644); err != nil { + return mcp.NewToolResultText(fmt.Sprintf("Error writing template file: %v", err)), nil + } + + // Create success response + response := fmt.Sprintf(`# Project Specification Template Created + +✅ **Template File Successfully Created** + +**File Path**: %s +**Generated**: %s + +## Template Overview + +A comprehensive project specification template has been created in your workspace with the following structure: + +- **Project Overview**: Basic project information and classification +- **Project Requirements**: Sections for requirements discovery findings +- **Technology Stack Selection**: Documentation of stack decisions and rationale +- **Application Architecture**: Component definitions and data architecture +- **Azure Service Mapping**: Infrastructure and service configurations +- **Implementation Plan**: Development approach and deployment strategy +- **Security and Compliance**: Security architecture and requirements +- **Monitoring and Operations**: Operational procedures and monitoring +- **Project Status and Next Steps**: Implementation roadmap and success criteria + +## Next Steps + +The template is ready! Other tools will now populate the template sections as they discover and plan project details: + +1. User intent discovery will fill the "Project Requirements" section +2. Stack selection will complete the "Technology Stack Selection" section +3. Architecture planning will populate the "Application Architecture" and "Azure Service Mapping" sections +4. Implementation planning will complete the remaining sections + +The template serves as the living documentation for your AZD project throughout the planning and implementation process.`, outputPath, generatedDate) + + return mcp.NewToolResultText(response), nil +} diff --git a/cli/azd/internal/mcp/tools/azd_identify_user_intent.go b/cli/azd/internal/mcp/tools/azd_identify_user_intent.go index e69de29bb2d..fd8107ba854 100644 --- a/cli/azd/internal/mcp/tools/azd_identify_user_intent.go +++ b/cli/azd/internal/mcp/tools/azd_identify_user_intent.go @@ -0,0 +1,42 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + + "github.com/azure/azure-dev/cli/azd/internal/mcp/tools/prompts" + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +// NewAzdIdentifyUserIntentTool creates a new azd identify user intent tool +func NewAzdIdentifyUserIntentTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_identify_user_intent", + mcp.WithReadOnlyHintAnnotation(true), + mcp.WithIdempotentHintAnnotation(true), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Returns instructions for discovering user project intent, requirements, and technology preferences +through conversational questioning. + +The LLM agent should execute these instructions using available tools. + +Use this tool when: +- Starting requirements discovery for new or existing projects +- Need to understand project scale, budget constraints, and architectural preferences +- Want to capture programming language and framework preferences +- Beginning project planning phase to inform technology stack decisions`, + ), + ), + Handler: handleAzdIdentifyUserIntent, + } +} + +func handleAzdIdentifyUserIntent(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + return mcp.NewToolResultText(prompts.AzdIdentifyUserIntentPrompt), nil +} diff --git a/cli/azd/internal/mcp/tools/azd_list_stack_resources.go b/cli/azd/internal/mcp/tools/azd_list_stack_resources.go index e69de29bb2d..0ba27bcb1d9 100644 --- a/cli/azd/internal/mcp/tools/azd_list_stack_resources.go +++ b/cli/azd/internal/mcp/tools/azd_list_stack_resources.go @@ -0,0 +1,111 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + _ "embed" + "fmt" + + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +//go:embed prompts/azd_list_stack_resources.md +var azdListStackResourcesPrompt string + +//go:embed resources/baseline_resources.md +var baselineResourcesDoc string + +//go:embed resources/containers_stack_resources.md +var containersStackResourcesDoc string + +//go:embed resources/serverless_stack_resources.md +var serverlessStackResourcesDoc string + +//go:embed resources/logic_apps_stack_resources.md +var logicAppsStackResourcesDoc string + +func NewAzdListStackResourcesTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_list_stack_resources", + mcp.WithReadOnlyHintAnnotation(true), + mcp.WithIdempotentHintAnnotation(true), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `List Azure resources required for a specific technology stack. + +Returns baseline resources (required for all stacks) plus stack-specific resources for the chosen technology approach. + +Use this tool when: +- A technology stack has been selected for a project (containers, serverless, or logic apps) +- Need resource listing for the selected technology stack + +The tool takes a stack parameter (containers, serverless, logic_apps) and returns the comprehensive resource list with Azure resource type identifiers.`, + ), + mcp.WithString("stack", + mcp.Description("The technology stack to list resources for"), + mcp.Enum("containers", "serverless", "logic_apps"), + mcp.Required(), + ), + ), + Handler: handleAzdListStackResources, + } +} + +func handleAzdListStackResources(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + stack, err := request.RequireString("stack") + if err != nil { + return mcp.NewToolResultError(fmt.Sprintf("Invalid arguments: %v", err)), nil + } + + // Validate stack parameter + validStacks := map[string]bool{ + "containers": true, + "serverless": true, + "logic_apps": true, + } + + if !validStacks[stack] { + return mcp.NewToolResultError(fmt.Sprintf("Invalid stack '%s'. Must be one of: containers, serverless, logic_apps", stack)), nil + } + + // Build response with baseline resources and stack-specific resources + var stackSpecificDoc string + var stackDisplayName string + + switch stack { + case "containers": + stackSpecificDoc = containersStackResourcesDoc + stackDisplayName = "Containers" + case "serverless": + stackSpecificDoc = serverlessStackResourcesDoc + stackDisplayName = "Serverless" + case "logic_apps": + stackSpecificDoc = logicAppsStackResourcesDoc + stackDisplayName = "Logic Apps" + } + + response := fmt.Sprintf(`%s + +# Azure Resources for %s Stack + +## Baseline Resources (All Stacks) + +%s + +## %s Stack-Specific Resources + +%s`, + azdListStackResourcesPrompt, + stackDisplayName, + baselineResourcesDoc, + stackDisplayName, + stackSpecificDoc, + ) + + return mcp.NewToolResultText(response), nil +} diff --git a/cli/azd/internal/mcp/tools/azd_modernize_project.go b/cli/azd/internal/mcp/tools/azd_modernize_project.go index e69de29bb2d..931d496f566 100644 --- a/cli/azd/internal/mcp/tools/azd_modernize_project.go +++ b/cli/azd/internal/mcp/tools/azd_modernize_project.go @@ -0,0 +1,42 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + + "github.com/azure/azure-dev/cli/azd/internal/mcp/tools/prompts" + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +// NewAzdModernizeProjectTool creates a new azd project modernization tool +func NewAzdModernizeProjectTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_modernize_project", + mcp.WithReadOnlyHintAnnotation(true), + mcp.WithIdempotentHintAnnotation(true), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Returns instructions for modernizing existing applications to be AZD-compatible while preserving +existing functionality and structure. + +The LLM agent should execute these instructions using available tools. + +Use this tool when: +- Existing application code is detected in the workspace +- Need to add Azure deployment capabilities to existing projects +- Want to migrate existing applications to Azure with minimal disruption +- Application components and architecture need analysis and Azure service mapping`, + ), + ), + Handler: handleAzdModernizeProject, + } +} + +func handleAzdModernizeProject(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + return mcp.NewToolResultText(prompts.AzdModernizeProjectPrompt), nil +} diff --git a/cli/azd/internal/mcp/tools/azd_new_project.go b/cli/azd/internal/mcp/tools/azd_new_project.go index e69de29bb2d..64f0b1c99e1 100644 --- a/cli/azd/internal/mcp/tools/azd_new_project.go +++ b/cli/azd/internal/mcp/tools/azd_new_project.go @@ -0,0 +1,42 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + + "github.com/azure/azure-dev/cli/azd/internal/mcp/tools/prompts" + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +// NewAzdNewProjectTool creates a new azd new project creation orchestration tool +func NewAzdNewProjectTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_new_project", + mcp.WithReadOnlyHintAnnotation(true), + mcp.WithIdempotentHintAnnotation(true), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Returns instructions for orchestrating complete new AZD project creation from scratch, +including requirements discovery, stack selection, architecture planning, and implementation roadmap. + +The LLM agent should execute these instructions using available tools. + +Use this tool when: +- Creating a completely new AZD project with no existing code +- User has a clear idea of what they want to build +- Workspace is empty or contains only minimal documentation +- Need comprehensive project specification and architecture design`, + ), + ), + Handler: handleAzdNewProject, + } +} + +func handleAzdNewProject(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + return mcp.NewToolResultText(prompts.AzdNewProjectPrompt), nil +} diff --git a/cli/azd/internal/mcp/tools/azd_plan_init.go b/cli/azd/internal/mcp/tools/azd_plan_init.go index 23a78e823eb..c3a522a4179 100644 --- a/cli/azd/internal/mcp/tools/azd_plan_init.go +++ b/cli/azd/internal/mcp/tools/azd_plan_init.go @@ -21,16 +21,20 @@ func NewAzdPlanInitTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for orchestrating complete AZD application initialization using structured phases -with specialized tools. + `Initial entry point for AZD project initialization and modernization workflows. -The LLM agent should execute these instructions using available tools. +This tool provides orchestration guidance for transforming workspaces into AZD-compatible projects. Use this tool when: -- Starting new AZD project initialization or migration -- Need structured approach to transform application into AZD-compatible project -- Want to ensure proper sequencing of discovery, planning, and file generation -- Require complete project orchestration guidance`, +- Creating new AZD project from an empty workspace +- Modernizing an existing application to become AZD compatible +- Need guidance for complete project setup and configuration + +Will help with the following: +- Analysis & Discovery +- Architecture Planning including stack selection +- File / Code generation +- Project validation`, ), ), Handler: handleAzdPlanInit, diff --git a/cli/azd/internal/mcp/tools/azd_select_stack.go b/cli/azd/internal/mcp/tools/azd_select_stack.go index e69de29bb2d..ff74dd99dce 100644 --- a/cli/azd/internal/mcp/tools/azd_select_stack.go +++ b/cli/azd/internal/mcp/tools/azd_select_stack.go @@ -0,0 +1,42 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + + "github.com/azure/azure-dev/cli/azd/internal/mcp/tools/prompts" + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +// NewAzdSelectStackTool creates a new azd stack selection tool +func NewAzdSelectStackTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_select_stack", + mcp.WithReadOnlyHintAnnotation(true), + mcp.WithIdempotentHintAnnotation(true), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Returns instructions for selecting the optimal technology stack (Containers, Serverless, or Logic Apps) +based on team expertise, performance requirements, and application characteristics. + +The LLM agent should execute these instructions using available tools. + +Use this tool when: +- User intent discovery has been completed +- Need to determine the best technology approach for the project +- Team expertise and application requirements are understood +- Ready to make technology stack decisions for architecture planning`, + ), + ), + Handler: handleAzdSelectStack, + } +} + +func handleAzdSelectStack(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + return mcp.NewToolResultText(prompts.AzdSelectStackPrompt), nil +} diff --git a/cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md index e69de29bb2d..3b8879a93d1 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md @@ -0,0 +1,356 @@ +# AZD Application Code Generation Instructions + +✅ **Agent Task List** + +1. Review application specification for application components and technology stack decisions +2. Identify preferred programming language and framework choices from user requirements +3. Analyze component types and generate appropriate application scaffolding for each +4. Create structured project layout in `src/` directories +5. Generate framework-specific code with Azure SDK integrations +6. Include configuration management, logging, and health monitoring setup +7. Create build and deployment scripts for each component +8. Update application spec with generated code structure and next steps + +📄 **Required Outputs** + +- Complete application scaffolding for all identified components in `src/` structure +- Framework-appropriate project files, dependencies, and build configurations +- Azure SDK integrations and service connection code +- Health checks, logging, and monitoring infrastructure +- Configuration management and environment variable handling +- Sample implementation code demonstrating component functionality +- Updated application spec documenting generated code structure + +🧠 **Execution Guidelines** + +**CRITICAL:** Generate production-ready application scaffolding that follows industry best practices for the selected programming language and framework. Include comprehensive Azure integrations and deployment-ready configurations. + +## Project Structure and Organization + +**Standard Directory Structure:** + +```text +src/ +├── / # REST API services +├── / # Single Page Applications +├── / # Background services and message processors +├── / # Serverless function applications +├── / # Server-rendered web applications +├── / # Batch processing applications +└── shared/ # Shared libraries and utilities +``` + +**Component Naming Conventions:** + +- Use kebab-case for directory names (e.g., `user-api`, `admin-portal`, `order-processor`) +- Match component names defined in architecture planning phase +- Ensure names are descriptive and reflect component purpose +- Avoid generic names like `service1`, `app`, or `backend` + +## Application Component Types and Scaffolding + +### API-Based Projects (REST APIs, GraphQL, gRPC) + +**Technology Stack Support:** + +**Node.js/TypeScript APIs:** + +- Express.js or Fastify framework setup +- TypeScript configuration with strict typing +- REST endpoint scaffolding with OpenAPI/Swagger documentation +- Middleware for authentication, logging, and error handling +- Database integration (Prisma, TypeORM, or native drivers) +- Azure SDK integrations (Storage, Key Vault, Service Bus) + +**Python APIs:** + +- FastAPI or Flask framework setup with async support +- Pydantic models for request/response validation +- SQLAlchemy or Django ORM for database operations +- Azure SDK for Python integrations +- Comprehensive error handling and logging +- Health check endpoints and metrics collection + +**C# APIs:** + +- ASP.NET Core Web API project setup +- Entity Framework Core for data access +- Dependency injection and configuration management +- Azure SDK for .NET integrations +- Comprehensive logging with Application Insights +- Authentication and authorization with Azure AD + +**Java APIs:** + +- Spring Boot application setup with appropriate starters +- Spring Data JPA for database operations +- Spring Security for authentication and authorization +- Azure SDK for Java integrations +- Comprehensive testing setup with JUnit and TestContainers + +**Generated Components:** + +- Controller/route definitions with CRUD operations +- Data models and entity definitions +- Service layer with business logic separation +- Repository pattern for data access +- Configuration classes for Azure service connections +- Health check endpoints (`/health`, `/ready`) +- API documentation setup and sample endpoints + +### SPA-Based Projects (React, Angular, Vue.js) + +**React/TypeScript SPAs:** +- Create React App or Vite setup with TypeScript +- React Router for navigation and routing +- State management (Redux Toolkit, Zustand, or Context API) +- API client setup with Axios or React Query +- Azure authentication integration (MSAL.js) +- Component library setup (Material-UI, Chakra UI, or custom) +- Build optimization and environment configuration + +**Angular SPAs:** +- Angular CLI project setup with TypeScript +- Angular Material or PrimeNG component library +- Reactive forms and validation +- HTTP client with interceptors for authentication +- Azure AD authentication with MSAL Angular +- State management with NgRx (for complex apps) +- PWA capabilities and service worker setup + +**Vue.js SPAs:** +- Vue 3 with Composition API and TypeScript +- Vue Router for navigation +- Pinia for state management +- Azure authentication integration +- Component library integration (Vuetify, Quasar) +- Build tools setup (Vite or Vue CLI) + +**Generated Components:** +- Application shell with navigation and layout +- Authentication components and route guards +- Sample pages and component structure +- API service classes for backend communication +- Configuration management for environments +- Build and deployment scripts +- Testing setup (Jest, Cypress, or Playwright) + +### Message-Based Projects (Event-Driven Applications) + +**Event Processing Applications:** +- Message handler scaffolding for Service Bus, Event Hubs, or Event Grid +- Dead letter queue handling and retry mechanisms +- Message serialization/deserialization utilities +- Batch processing and scaling configurations +- Monitoring and telemetry collection + +**Worker Service Applications:** +- Background service templates for long-running processes +- Queue-based work distribution patterns +- Health monitoring and graceful shutdown handling +- Configuration for scaling and resource management +- Integration with Azure Monitor and Application Insights + +**Generated Components:** +- Message handler classes with typed message contracts +- Queue/topic configuration and connection management +- Error handling and retry policy implementations +- Metrics collection and performance monitoring +- Configuration for different message sources (Service Bus, Event Hubs, etc.) + +### Function-Based Projects (Serverless Applications) + +**Azure Functions:** +- Function app project setup with appropriate triggers +- HTTP triggers for API endpoints +- Timer triggers for scheduled operations +- Service Bus/Event Hub triggers for message processing +- Blob/Queue triggers for storage events +- Dependency injection and configuration setup + +**Generated Components:** +- Function definitions with appropriate triggers and bindings +- Shared utilities and helper functions +- Configuration for local development and testing +- Integration with Azure services through bindings +- Logging and monitoring setup + +### Web Application Projects (Server-Rendered) + +**Server-Rendered Applications:** +- Framework setup (Next.js, Nuxt.js, or traditional server frameworks) +- Authentication and session management +- Database integration and ORM setup +- Template engine configuration and layouts +- Static asset management and optimization + +**Generated Components:** +- Page templates and routing configuration +- Authentication middleware and user management +- Database models and migration scripts +- Asset pipeline and build configuration +- Environment-specific configuration management + +### Batch Processing Projects + +**Data Processing Applications:** +- Batch job frameworks (Spring Batch, Apache Airflow workflows) +- Data pipeline scaffolding for ETL operations +- Integration with Azure Data Factory or Azure Batch +- Error handling and job monitoring +- Scalable processing patterns + +**Generated Components:** +- Job definition classes and processing logic +- Data source connectors and transformation utilities +- Scheduling and workflow management +- Monitoring and alerting configuration + +## Programming Language and Framework Selection + +**Language-Specific Best Practices:** + +**TypeScript/JavaScript:** +- Strict TypeScript configuration with comprehensive type checking +- ESLint and Prettier configuration for code quality +- Modern ES6+ features and async/await patterns +- Package.json with appropriate scripts and dependencies +- Environment configuration with dotenv or similar + +**Python:** +- Virtual environment setup and requirements management +- Type hints and mypy configuration for static typing +- Black and flake8 for code formatting and linting +- pytest setup for comprehensive testing +- Environment configuration with python-dotenv + +**C#:** +- Modern C# features and nullable reference types +- Project file configuration with appropriate package references +- Dependency injection and configuration patterns +- Comprehensive logging with structured logging +- Environment-specific appsettings.json files + +**Java:** +- Maven or Gradle build configuration +- Spring Boot best practices and auto-configuration +- Comprehensive testing with JUnit and Mockito +- Logging configuration with Logback or Log4j2 +- Environment configuration with profiles + +## Azure SDK Integration and Service Connections + +**Common Azure Service Integrations:** + +**Authentication and Identity:** +- Azure AD integration for user authentication +- Managed Identity configuration for service-to-service auth +- Key Vault integration for secrets management +- Role-based access control (RBAC) setup + +**Data and Storage:** +- Azure SQL Database or Cosmos DB connection setup +- Azure Storage (Blob, Queue, Table) integration +- Redis Cache configuration and usage patterns +- Database migration and seeding scripts + +**Messaging and Events:** +- Service Bus queue and topic integration +- Event Hubs producer and consumer setup +- Event Grid subscription and handler configuration +- Dead letter queue and error handling patterns + +**Monitoring and Observability:** +- Application Insights integration and telemetry +- Structured logging with correlation IDs +- Health check endpoints and monitoring +- Custom metrics and performance counters + +## Configuration Management and Environment Setup + +**Environment Configuration Patterns:** + +**Local Development:** +- Local environment setup with development containers +- Mock services and local testing configuration +- Debug configuration and hot reload setup +- Local database and messaging emulators + +**Azure Environment Integration:** +- Environment-specific configuration files +- Azure App Configuration or Key Vault integration +- Managed Identity configuration for Azure services +- Connection string management and rotation + +**Security and Compliance:** +- Secure coding practices and input validation +- Authentication and authorization implementation +- Data encryption and secure communication +- Compliance with security best practices + +## Code Generation Workflow + +**Component Analysis and Planning:** + +1. **Read Architecture Decisions**: Review application spec for component definitions and technology choices +2. **Identify Component Types**: Classify each component (API, SPA, Worker, Function, etc.) +3. **Determine Language/Framework**: Use user preferences from intent discovery or make appropriate recommendations +4. **Plan Integration Points**: Identify shared libraries, communication patterns, and service dependencies + +**Scaffolding Generation Process:** + +1. **Create Directory Structure**: Establish `src/` layout for each component +2. **Generate Framework Setup**: Create appropriate project files, configuration, and dependencies +3. **Add Azure Integrations**: Include SDK setup and service connection code +4. **Create Sample Implementation**: Generate basic functionality demonstrating component purpose +5. **Add Supporting Infrastructure**: Include testing, logging, monitoring, and deployment setup + +**Quality Assurance and Validation:** + +- Ensure generated code compiles and runs without errors +- Validate Azure SDK integrations and authentication setup +- Test basic functionality and health check endpoints +- Verify configuration management and environment handling +- Confirm alignment with architecture decisions and requirements + +## Documentation and Next Steps + +**Code Structure Documentation:** + +Update application spec with generated code details: + +```markdown +## Generated Application Code + +### Component Structure +- **API Services**: [List of generated API components with technologies] +- **Frontend Applications**: [List of generated SPA components with frameworks] +- **Background Services**: [List of generated worker/message components] +- **Function Applications**: [List of generated serverless components] + +### Technology Stack +- **Primary Language**: [Selected programming language] +- **Frameworks**: [List of frameworks used per component type] +- **Azure SDK Integrations**: [List of Azure services integrated] + +### Development Setup +- **Local Development**: Instructions for running components locally +- **Testing Strategy**: Overview of testing setup and practices +- **Build and Deployment**: Summary of build processes and deployment configuration + +### Next Steps +- [Specific guidance for development team to continue implementation] +- [Testing and validation recommendations] +- [Deployment and monitoring setup instructions] +``` + +**Success Criteria:** + +- [ ] All application components have appropriate scaffolding generated +- [ ] Code follows language and framework best practices +- [ ] Azure SDK integrations are properly configured +- [ ] Configuration management supports multiple environments +- [ ] Health checks and monitoring are implemented +- [ ] Build and deployment scripts are functional +- [ ] Documentation provides clear next steps for development +- [ ] Generated code aligns with architecture decisions and user requirements diff --git a/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md b/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md index ed18c37bc30..de213356d3c 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md @@ -2,133 +2,170 @@ ✅ **Agent Task List** -1. Read `azd-arch-plan.md` to understand discovered components -2. Always identify latest Azure best practices -3. For each component, select optimal Azure service using selection criteria below -4. Plan containerization strategy for applicable services -5. Select appropriate database and messaging services -6. Design resource group organization and networking approach -7. Generate IaC file checklist based on selected Azure services -8. Generate Docker file checklist based on containerization strategy -9. Create `azd-arch-plan.md` if it doesn't exist, or update existing file with service mapping table, architecture decisions, IaC checklist, and Docker checklist while preserving existing content +1. Review application spec to gather all previously collected context (requirements, stack selection, discovered components) +2. Populate the "Application Architecture" section with component details and relationships +3. Complete the "Azure Service Mapping" section with specific service assignments and rationale +4. Update the "Implementation Plan" section with concrete next steps +5. Ensure all gathered context is properly documented in the appropriate existing sections 📄 **Required Outputs** -- Create `azd-arch-plan.md` if missing, or update existing file with Azure Service Mapping Table showing Component | Current Tech | Azure Service | Rationale -- Hosting strategy summary documenting decisions for each component (preserve existing content) -- Containerization plans for applicable services (preserve existing content) -- Infrastructure architecture design including resource organization and networking (preserve existing content) -- **IaC File Generation Checklist** listing all Bicep files that need to be created based on selected services (add to existing file) -- **Docker File Generation Checklist** listing all Docker files needed for containerized services (add to existing file) +- Fully populated "Application Architecture" section with component details, data architecture, and integration patterns +- Complete "Azure Service Mapping" section showing all service assignments with rationale +- Updated "Implementation Plan" with infrastructure and deployment strategy +- All previously gathered context properly integrated into the existing application spec structure 🧠 **Execution Guidelines** -**Azure Service Selection Criteria:** +**CRITICAL:** This tool focuses on consolidating all previously gathered context into the existing application spec sections. Do not create new sections - populate the template sections with the collected information. -**Azure Container Apps (PREFERRED)** - Use for microservices, containerized applications, event-driven workloads with auto-scaling needs +## Context Consolidation Process -**Azure Kubernetes Service (AKS)** - Use for complex containerized applications requiring full Kubernetes control, advanced networking, custom operators +**Review All Gathered Context:** -**Azure App Service** - Use for web applications, REST APIs needing specific runtime versions or Windows-specific features +- Read the complete application spec to understand all previously collected information +- Review project requirements, technology stack selection, and discovered components +- Identify any gaps in information that need to be addressed +- Note the selected technology stack and baseline Azure resources -**Azure Functions** - Use for event processing, scheduled tasks, lightweight APIs with pay-per-execution model +**Populate Application Architecture Section:** -**Azure Static Web Apps** - Use for frontend SPAs, static sites, JAMstack applications with minimal backend needs +Use the existing "Application Architecture" section structure to document: +**Component Overview Table:** +Fill in the existing component table with discovered application components: -**Database Service Selection:** +```markdown +| Component Name | Type | Technology | Purpose | Dependencies | +|---------------|------|------------|---------|--------------| +| [discovered-component-1] | [API/SPA/Worker/Function] | [Current technology] | [Component purpose] | [Other components or services] | +``` -- Azure SQL Database: SQL Server compatibility, complex queries, ACID compliance -- Azure Database for PostgreSQL/MySQL: Specific engine compatibility required -- Azure Cosmos DB: NoSQL requirements, global scale, flexible schemas -- Azure Cache for Redis: Application caching, session storage, real-time analytics +**Component Details:** +For each discovered component, populate the detailed sections with: -**Messaging Service Selection:** +- Component type and technology choices +- Detailed purpose and responsibilities +- Data access patterns and requirements +- External integrations and dependencies +- Scaling and performance characteristics -- Azure Service Bus: Enterprise messaging, guaranteed delivery, complex routing -- Azure Event Hubs: High-throughput event streaming, telemetry ingestion -- Azure Event Grid: Event-driven architectures, reactive programming +**Data Architecture:** +Document the data strategy based on discovered requirements: -**IaC File Checklist Generation:** +- Primary database technology and rationale +- Caching requirements and approach +- Data flow patterns between components +- Backup and recovery considerations -Based on selected Azure services, generate a checklist of required Bicep files to be created: +**Integration Architecture:** +Define how components will communicate: -**Always Required:** +- Internal service communication patterns +- Event-driven architecture if applicable +- External API integrations +- Authentication and security patterns -- [ ] `./infra/main.bicep` - Primary deployment template (subscription scope) -- [ ] `./infra/main.parameters.json` - Parameter defaults -- [ ] `./infra/modules/monitoring.bicep` - Log Analytics and Application Insights +## Azure Service Mapping -**Service-Specific Modules (include based on service selection):** +**Populate Service Architecture Tables:** -- [ ] `./infra/modules/container-apps.bicep` - If Container Apps selected -- [ ] `./infra/modules/app-service.bicep` - If App Service selected -- [ ] `./infra/modules/functions.bicep` - If Azure Functions selected -- [ ] `./infra/modules/static-web-app.bicep` - If Static Web Apps selected -- [ ] `./infra/modules/aks.bicep` - If AKS selected -- [ ] `./infra/modules/database.bicep` - If SQL/PostgreSQL/MySQL selected -- [ ] `./infra/modules/cosmosdb.bicep` - If Cosmos DB selected -- [ ] `./infra/modules/storage.bicep` - If Storage Account needed -- [ ] `./infra/modules/keyvault.bicep` - If Key Vault needed (recommended) -- [ ] `./infra/modules/servicebus.bicep` - If Service Bus selected -- [ ] `./infra/modules/eventhub.bicep` - If Event Hubs selected -- [ ] `./infra/modules/redis.bicep` - If Redis Cache selected -- [ ] `./infra/modules/container-registry.bicep` - If container services selected +Fill the existing service mapping tables based on the selected technology stack: -**Example IaC Checklist Output:** +**Hosting Services Table:** +Map each application component to its Azure hosting service with specific configuration details: ```markdown -## Infrastructure as Code File Checklist +| Component | Azure Service | Configuration | Rationale | +|-----------|---------------|---------------|-----------| +| [component-name] | [Container Apps/Functions/Logic Apps] | [Scaling, networking, runtime details] | [Why this service fits the requirements] | +``` + +Example populated entries: + +- **Web API Component**: Container Apps | Auto-scaling 1-10 instances, HTTP ingress | Containerized service needing variable scaling +- **Frontend SPA**: Static Web Apps | Global CDN, custom domain | Static React app with global distribution needs +- **Background Processor**: Azure Functions | Consumption plan, Event Hub trigger | Event-driven processing with cost optimization +- **Workflow Orchestrator**: Logic Apps | Standard tier, HTTP triggers | Business process automation with visual design needs + +**Supporting Services:** +Document the supporting Azure services based on the selected stack: + +- **Data Services**: Map data requirements to Azure SQL, Cosmos DB, PostgreSQL, etc. +- **Integration Services**: Select messaging services (Service Bus, Event Hubs, Event Grid) +- **Infrastructure Services**: Configure monitoring, security, and networking services + +Use the baseline resources for all stacks: -Based on the selected Azure services, the following Bicep files need to be generated: +- Log Analytics Workspace for centralized logging +- Application Insights for performance monitoring +- Key Vault for secrets management +- App Configuration for configuration management +- Storage Account for file storage and queues -### Core Files (Always Required) -- [ ] `./infra/main.bicep` - Primary deployment template -- [ ] `./infra/main.parameters.json` - Parameter defaults -- [ ] `./infra/modules/monitoring.bicep` - Observability stack +**Resource Organization:** +Define the resource organization strategy: -### Service-Specific Modules -- [ ] `./infra/modules/container-apps.bicep` - For web API hosting -- [ ] `./infra/modules/database.bicep` - For PostgreSQL database -- [ ] `./infra/modules/keyvault.bicep` - For secrets management -- [ ] `./infra/modules/container-registry.bicep` - For container image storage +- Resource group structure and naming +- Environment separation strategy +- Naming conventions for all resources -Total files to generate: 7 +## Implementation Plan Updates + +**Update Development Approach:** + +Populate the project structure section with the actual discovered components: + +```text +src/ +├── [actual-component-1]/ # [Actual component description] +├── [actual-component-2]/ # [Actual component description] +├── shared/ # Shared libraries and utilities +└── docs/ # Additional documentation ``` -**Docker File Checklist Generation:** +**Update Deployment Strategy:** -Based on selected Azure services and containerization strategy, generate a checklist of required Docker files: +Based on the selected technology stack, document: -**Container-Based Services (include based on service selection):** +- Infrastructure as Code approach (Bicep templates for selected services) +- Container strategy (if containers stack selected) +- Configuration management approach +- CI/CD pipeline requirements -- [ ] `{service-path}/Dockerfile` - If Container Apps, AKS, or containerized App Service selected -- [ ] `{service-path}/.dockerignore` - For each containerized service +## Documentation Requirements -**Example Docker Checklist Output:** +Ensure all sections are populated with the gathered context: -```markdown -## Docker File Generation Checklist +1. **Application Architecture** - Complete component details, data architecture, and integration patterns +2. **Azure Service Mapping** - Full service assignments with rationale +3. **Implementation Plan** - Concrete development and deployment approach +4. **Project Status** - Update status based on completed discovery and planning phases -Based on the containerization strategy, the following Docker files need to be generated: +The tool should transform this template structure: -### Service Dockerfiles -- [ ] `./api/Dockerfile` - For Node.js API service (Container Apps) -- [ ] `./api/.dockerignore` - Exclude unnecessary files from API container -- [ ] `./frontend/Dockerfile` - For React frontend (containerized App Service) -- [ ] `./frontend/.dockerignore` - Exclude unnecessary files from frontend container +```markdown +### Selected Stack: [CONTAINERS/SERVERLESS/LOGIC APPS] +``` -Total Docker files to generate: 4 +Into populated content like: + +```markdown +### Selected Stack: CONTAINERS + +#### Selection Rationale +- **Team Expertise**: Team has Docker experience and wants infrastructure control +- **Application Characteristics**: Traditional web API and frontend requiring consistent performance +- **Performance Requirements**: Need minimal cold starts and predictable response times +- **Integration Needs**: Multiple external API integrations with custom authentication +- **Cost Considerations**: Predictable costs preferred over pay-per-execution ``` 📌 **Completion Checklist** -- [ ] Azure service selected for each discovered component with documented rationale -- [ ] Hosting strategies defined and documented in `azd-arch-plan.md` -- [ ] Containerization plans documented for applicable services -- [ ] Data storage strategies planned and documented -- [ ] Resource group organization strategy defined -- [ ] Integration patterns between services documented -- [ ] **IaC file checklist generated** and added to `azd-arch-plan.md` based on selected services -- [ ] **Docker file checklist generated** and added to `azd-arch-plan.md` based on containerization strategy -- [ ] `azd-arch-plan.md` created or updated while preserving existing content -- [ ] Ready to proceed to infrastructure generation phase +- [ ] Application spec reviewed for discovered components and selected technology stack +- [ ] Azure service mapping completed for all discovered components with documented rationale +- [ ] Component relationships and data flow patterns documented +- [ ] Resource organization strategy defined (resource groups, naming, environments) +- [ ] Implementation checklists created for infrastructure and containerization generation +- [ ] Application spec updated with "Azure Service Mapping" section while preserving existing content +- [ ] Architecture documentation complete and ready for implementation phases diff --git a/cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md index e69de29bb2d..661dbd0a8fb 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md @@ -0,0 +1,278 @@ +# AZD Artifact Generation Orchestration Instructions + +✅ **Agent Task List** + +1. Review application spec for complete project architecture and service specifications +2. Read required resources from the Infrastructure as Code File Checklist in application spec +3. Analyze existing workspace to identify current artifacts and generation requirements +4. Get IaC generation rules for Azure infrastructure best practices +5. Generate infrastructure templates for all Azure resources using the rules and resource requirements +6. Generate application scaffolding for new project components +7. Generate Docker configuration for containerizable services +8. Generate azure.yaml configuration for AZD deployment +9. Validate all generated artifacts for consistency and deployment readiness +10. Update application spec with artifact generation status and completion tracking + +📄 **Required Outputs** + +- Application scaffolding and starter code for new project components +- Docker configurations (Dockerfiles and .dockerignore) for containerizable services +- Complete Bicep infrastructure templates in `./infra` directory +- Valid `azure.yaml` configuration file mapping all services and resources +- All artifacts validated for syntax correctness and deployment compatibility +- Updated application spec with comprehensive artifact generation documentation + +🧠 **Execution Guidelines** + +**CRITICAL:** This tool orchestrates the complete artifact generation process for AZD projects. Execute generation phases in the correct order to ensure dependencies are properly handled. Always preserve existing user customizations while adding required AZD capabilities. + +## Pre-Generation Analysis and Planning + +**Architecture Review:** + +- Read complete application spec to understand project architecture +- Review service mappings, technology stack decisions, and infrastructure design +- Identify which artifacts need generation vs updates vs preservation +- Note any existing user customizations that must be maintained + +**Existing Artifact Inventory:** + +Scan workspace for existing artifacts: + +- **Application Code**: Entry points, framework files, existing business logic +- **Docker Files**: Existing Dockerfiles, docker-compose configurations +- **Infrastructure Code**: Current Bicep templates, ARM templates, Terraform files +- **Configuration Files**: Existing azure.yaml, deployment scripts, CI/CD definitions + +**Generation Requirements Assessment:** + +Based on project type and architecture decisions: + +- **New Projects**: Full scaffolding + all infrastructure + configuration +- **Existing Applications**: Minimal scaffolding + infrastructure + configuration preservation +- **Hybrid Scenarios**: Selective generation with integration considerations + +## Application Scaffolding Generation + +**Application Code Generation:** + +Use application code generation capabilities to create: + +**Framework-Appropriate Scaffolding:** + +- Generate complete application structure in `src/` directories +- Create language and framework-specific project files and configurations +- Include Azure SDK integrations and service connection templates +- Add health checks, logging, and monitoring infrastructure +- Generate sample implementation code demonstrating component functionality + +**Component Type Support:** + +- **API Services**: REST APIs, GraphQL endpoints, gRPC services with appropriate frameworks +- **SPA Applications**: React, Angular, Vue.js frontends with TypeScript/JavaScript +- **Message Processors**: Event-driven applications for Service Bus, Event Hubs integration +- **Function Applications**: Azure Functions with appropriate triggers and bindings +- **Web Applications**: Server-rendered applications with authentication and data access +- **Background Services**: Worker services and batch processing applications + +**Technology Integration:** + +- Ensure generated code aligns with programming language preferences from user requirements +- Include framework-specific best practices and development patterns +- Add Azure service integrations based on architecture planning decisions +- Create environment configuration and deployment-ready setup + +## Docker Configuration Generation + +**Containerization Strategy Execution:** + +Use Docker generation capabilities to create: + +**Service Dockerfiles:** + +- Generate optimized Dockerfiles for each containerizable service +- Use multi-stage builds for build optimization and security +- Include language-specific best practices and dependency management +- Add health check configurations and security hardening + +**Docker Optimization:** + +- Create .dockerignore files for efficient build contexts +- Implement layer caching strategies for faster builds +- Use minimal base images and non-root users +- Add container security scanning and vulnerability management + +**Container Orchestration Support:** + +- Ensure Docker configurations work with Azure Container Apps +- Add necessary labels and metadata for service discovery +- Include resource limit and scaling configurations +- Create container networking and communication patterns + +## Infrastructure Template Generation + +**Azure Resource Provisioning:** + +Use infrastructure generation capabilities to create: + +**IaC Rules and Resource Requirements:** + +- Get IaC generation rules for Azure infrastructure best practices and coding standards +- Read required resources from the Infrastructure as Code File Checklist in application spec +- Apply generation rules to each required resource type for consistent implementation + +**Modular Infrastructure Templates:** + +- Generate main.bicep with subscription scope deployment +- Create generic resource modules for reusable Azure service patterns (e.g., `modules/containerapp.bicep`, `modules/storage.bicep`) +- Generate service-specific modules that reference generic modules with customized configurations +- Create resource group organization and management structures + +**Core Infrastructure Components:** + +- Add monitoring and logging infrastructure (Log Analytics, Application Insights) +- Include security and compliance configurations (Key Vault, managed identities) +- Generate database configurations (SQL, Cosmos DB, PostgreSQL, etc.) +- Add messaging infrastructure (Service Bus, Event Hubs, Event Grid) +- Create storage and caching configurations (Storage Accounts, Redis) + +**Networking and Security:** + +- Generate virtual network configurations for multi-service applications +- Add security group rules and access control +- Create private endpoint configurations where appropriate +- Include SSL/TLS certificate management + +**Environment Management:** + +- Create parameter files for different environments (dev, staging, production) +- Add configuration for scaling and performance optimization +- Include backup and disaster recovery configurations +- Generate monitoring and alerting rule definitions + +## Azure.yaml Configuration Generation + +**AZD Deployment Configuration:** + +Use azure.yaml generation capabilities to create: + +**Service Registration:** + +- Map all application services to appropriate Azure hosting services +- Configure build and deployment instructions for each service +- Add dependency relationships and deployment ordering +- Include environment variable and configuration management + +**Infrastructure Integration:** + +- Reference generated Bicep templates and parameters +- Configure resource provisioning and dependency management +- Add post-deployment scripts and validation steps +- Include environment-specific overrides and configurations + +**Development Workflow Integration:** + +- Configure local development and testing scenarios +- Add debugging and troubleshooting capabilities +- Include CI/CD pipeline integration points +- Create deployment validation and rollback procedures + +## Artifact Validation and Quality Assurance + +**Syntax and Schema Validation:** + +- Validate all Docker files for syntax correctness and best practices +- Compile and test all Bicep templates for Azure compatibility +- Validate azure.yaml against AZD schema and configuration requirements +- Test application scaffolding for build and runtime correctness + +**Integration Testing:** + +- Verify Docker containers build and run successfully +- Test infrastructure templates deploy without errors +- Validate azure.yaml configuration deploys all services correctly +- Ensure generated application code integrates with Azure services + +**Security and Compliance Validation:** + +- Scan Docker images for security vulnerabilities +- Review infrastructure templates for security best practices +- Validate access control and authentication configurations +- Ensure compliance with organizational security policies + +## Artifact Generation Workflow + +**Sequential Generation Process:** + +```text +1. Architecture Review → 2. Existing Artifact Inventory → 3. Application Code Generation → +4. Docker Configuration → 5. Infrastructure Templates → 6. Azure.yaml Configuration → +7. Validation and Testing → 8. Documentation Update +``` + +**Iterative Refinement Process:** + +```text +1. Identify specific artifact needs → 2. Generate targeted artifacts → +3. Validate integration → 4. Refine and optimize → 5. Update documentation +``` + +**Error Recovery Process:** + +```text +1. Identify generation failures → 2. Analyze dependency conflicts → +3. Resolve compatibility issues → 4. Regenerate affected artifacts → 5. Revalidate +``` + +## Documentation and Completion Tracking + +**Progress Documentation:** + +Update application spec with artifact generation status: + +```markdown +## Artifact Generation Status + +### Application Scaffolding +- [x] Web frontend scaffolding created +- [x] API service template generated +- [x] Database integration configured +- [x] Authentication framework added + +### Docker Configurations +- [x] Frontend service Dockerfile created +- [x] API service Dockerfile generated +- [x] .dockerignore files optimized +- [x] Health checks implemented + +### Infrastructure Templates +- [x] Main deployment template created +- [x] Container Apps module generated +- [x] Database infrastructure configured +- [x] Monitoring and logging added + +### Azure.yaml Configuration +- [x] Service definitions completed +- [x] Build configurations verified +- [x] Infrastructure references validated +- [x] Deployment workflow tested + +### Validation Results +- [x] All Docker images build successfully +- [x] Infrastructure templates deploy without errors +- [x] Azure.yaml configuration validates +- [x] End-to-end deployment verified +``` + +**Success Criteria and Completion Checklist:** + +- [ ] All required application code generated and functional +- [ ] Docker configurations created for all containerizable services +- [ ] Complete infrastructure templates generated and validated +- [ ] Azure.yaml configuration created and schema-compliant +- [ ] All artifacts integrate correctly with each other +- [ ] Generated code follows language and framework best practices +- [ ] Security and compliance requirements met +- [ ] Documentation updated with generation details +- [ ] End-to-end deployment tested and verified +- [ ] Project ready for development and deployment workflows diff --git a/cli/azd/internal/mcp/tools/prompts/azd_azure_yaml_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_azure_yaml_generation.md index 7496351c81e..04733e4f456 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_azure_yaml_generation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_azure_yaml_generation.md @@ -2,13 +2,13 @@ ✅ **Agent Task List** -1. Check if `azd-arch-plan.md` exists and review architecture decisions +1. Check if application spec exists and review architecture decisions 2. Identify all application services (frontend, backend, functions, etc.) 3. Determine hosting requirements for each service based on Azure service selections 4. Analyze build requirements (language, package manager, build commands) 5. Create complete `azure.yaml` file in root directory following required patterns 6. Validate file against AZD schema using available tools -7. Update existing `azd-arch-plan.md` with generated configuration details while preserving existing content +7. Update existing application spec with generated configuration details while preserving existing content 📄 **Required Outputs** @@ -16,7 +16,7 @@ - Service configurations matching Azure service selections from architecture planning - Build and deployment instructions for all services - Configuration validated against AZD schema -- Update existing `azd-arch-plan.md` with configuration details while preserving existing content +- Update existing application spec with configuration details while preserving existing content 🧠 **Execution Guidelines** @@ -98,4 +98,4 @@ services: - [ ] Service hosting configurations match Azure service selections from architecture planning - [ ] Build and deployment instructions complete for all services - [ ] File validates against any available AZD schema tools -- [ ] `azd-arch-plan.md` updated with configuration details while preserving existing content +- [ ] Application spec updated with configuration details while preserving existing content diff --git a/cli/azd/internal/mcp/tools/prompts/azd_docker_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_docker_generation.md index b09aee91625..9ffb490a8b9 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_docker_generation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_docker_generation.md @@ -2,28 +2,28 @@ ✅ **Agent Task List** -1. Read the **Docker File Generation Checklist** from `azd-arch-plan.md` +1. Read the **Docker File Generation Checklist** from application spec 2. Identify containerizable services and required Docker files from the checklist 3. Detect programming language and framework for each containerizable service 4. Generate each Docker file specified in the checklist following language-specific best practices 5. Create .dockerignore files for build optimization 6. Implement health checks and security configurations -7. Update the Docker checklist section in existing `azd-arch-plan.md` by marking completed items as [x] while preserving existing content +7. Update the Docker checklist section in existing application spec by marking completed items as [x] while preserving existing content 📄 **Required Outputs** -- All Docker files listed in the Docker File Generation Checklist from `azd-arch-plan.md` +- All Docker files listed in the Docker File Generation Checklist from application spec - Dockerfiles created for all containerizable services - .dockerignore files generated for each service - Health check endpoints implemented - Multi-stage builds with security best practices -- Update existing `azd-arch-plan.md` Docker checklist by marking completed items as [x] while preserving existing content +- Update existing application spec Docker checklist by marking completed items as [x] while preserving existing content 🧠 **Execution Guidelines** **Read Docker Checklist:** -- Read the "Docker File Generation Checklist" section from `azd-arch-plan.md` +- Read the "Docker File Generation Checklist" section from application spec - This checklist specifies exactly which Docker files need to be generated - Use this as the authoritative source for what to create - Follow the exact file paths specified in the checklist @@ -32,7 +32,7 @@ - Create service Dockerfiles first (e.g., `{service-path}/Dockerfile`) - Create corresponding .dockerignore files for each service (e.g., `{service-path}/.dockerignore`) -- Follow the exact file paths specified in the checklist from `azd-arch-plan.md` +- Follow the exact file paths specified in the checklist from application spec **Containerization Candidates:** @@ -102,7 +102,7 @@ 📌 **Completion Checklist** -- [ ] **Docker File Generation Checklist read** from `azd-arch-plan.md` +- [ ] **Docker File Generation Checklist read** from application spec - [ ] **All files from Docker checklist generated** in the correct locations - [ ] Dockerfiles created for all containerizable services identified in architecture planning - [ ] .dockerignore files generated with appropriate exclusions for each language @@ -112,4 +112,4 @@ - [ ] Container startup optimization applied (dependency file caching) - [ ] All Dockerfiles build successfully (`docker build` test) - [ ] Security best practices followed (minimal images, no secrets) -- [ ] **Docker checklist in `azd-arch-plan.md` updated** by marking completed items as [x] while preserving existing content +- [ ] **Docker checklist in application spec updated** by marking completed items as [x] while preserving existing content diff --git a/cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md b/cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md index e69de29bb2d..fcfa8c6fcf1 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md @@ -0,0 +1,166 @@ +# AZD Project Intent and Requirements Discovery Instructions + +✅ **Agent Task List** + +1. Engage user with conversational questions to understand project purpose and stage +2. Determine application scale requirements and production readiness +3. Identify budget and cost constraint considerations +4. Understand architectural and technology stack preferences +5. Classify project into appropriate categories for optimal Azure service recommendations +6. Document findings in Application specification under "Project Requirements" section + +📄 **Required Outputs** + +- Project classification: POC, Development Tool, or Production Application +- Scale category: Small, Medium, or Large (for production applications) +- Budget constraint level: Cost-Optimized, Balanced, or Performance-Focused +- Architectural preference: Containers, Serverless, Hybrid, or No Preference +- Comprehensive requirements summary documented in Application specification + +🧠 **Execution Guidelines** + +**CRITICAL:** Ask questions conversationally, one at a time or in small groups. Adapt follow-up questions based on user responses. Don't overwhelm with a long questionnaire. + +## Phase 1: Project Purpose and Stage Discovery + +Start with foundational questions to understand the project's intent: + +**Primary Questions:** + +- "What's the main purpose of this application? Are you building a proof of concept, a development/internal tool, or planning for a production application?" +- "Who is the intended audience for this application?" (Internal team, external customers, specific user group) +- "What problem does this application solve?" + +**Follow-up Questions (based on response):** + +*If POC/Prototype:* + +- "How long do you expect this proof of concept to run?" +- "Will this potentially evolve into a production application?" +- "Are you primarily focused on demonstrating functionality or testing performance?" + +*If Development Tool:* + +- "How many developers or users will be using this tool?" +- "Is this for temporary use or a long-term internal solution?" +- "Do you need high availability or is occasional downtime acceptable?" + +*If Production Application:* + +- Proceed to Phase 2 for detailed scale assessment + +## Phase 2: Scale and Performance Requirements (Production Applications) + +**User Base Questions:** + +- "How many users do you expect when the application launches?" +- "What's your expected user growth over the next 12 months?" +- "Will usage be steady throughout the day or are there peak periods?" + +**Geographic and Availability Questions:** + +- "Will your users be primarily in one geographic region or globally distributed?" +- "What level of availability do you need? (e.g., 99.9%, 99.99%, or basic uptime)" +- "How critical is performance? Are sub-second response times required?" + +**Scale Classification (Internal Use):** + +- **Small Scale:** <10K users, single region, standard availability requirements +- **Medium Scale:** 10K-100K users, multi-region consideration, higher availability needs +- **Large Scale:** >100K users, global distribution, enterprise-grade availability and performance + +## Phase 3: Budget and Cost Considerations + +**Budget Discovery Questions:** + +- "Do you have specific budget constraints or cost targets for running this application?" +- "Is minimizing costs the top priority, or are you willing to invest more for better performance/reliability?" +- "Are you more concerned about predictable monthly costs or optimizing for the lowest possible spend?" + +**Cost Preference Classification:** + +- **Cost-Optimized:** Minimize expenses, accept some performance trade-offs, prefer consumption-based pricing +- **Balanced:** Reasonable cost with good performance, mix of reserved and consumption pricing +- **Performance-Focused:** Cost is secondary to performance and reliability, premium services acceptable + +## Phase 4: Architectural and Stack Preferences + +**Technology Approach Questions:** + +- "Do you have experience with containers (Docker) or prefer to avoid container management?" +- "Are you interested in serverless approaches where you don't manage infrastructure?" +- "Do you need full control over the underlying infrastructure, or prefer managed services?" +- "Are there specific technologies or platforms you want to use or avoid?" + +**Programming Language and Framework Preferences:** + +- "What programming language does your team prefer or have the most experience with?" (JavaScript/TypeScript, Python, C#, Java, Go, or other) +- "Do you have preferences for specific frameworks?" (React, Angular, Vue for frontend; Express, FastAPI, Spring Boot for backend) +- "Are there any technology constraints from your organization or existing systems?" +- "Do you prefer strongly-typed languages or are you comfortable with dynamic typing?" + +**Integration and Compliance Questions:** + +- "Do you need to integrate with existing systems or databases?" +- "Are there any compliance requirements (HIPAA, SOC2, etc.) that influence your architecture choices?" +- "Do you have existing Azure services or subscriptions this should connect to?" + +**Architectural Preference Classification:** + +- **Containers:** Prefer containerized applications with orchestration (Azure Container Apps, AKS) +- **Serverless:** Prefer event-driven, fully managed compute (Azure Functions, Logic Apps) +- **Hybrid:** Mix of containers and serverless based on component needs +- **No Preference:** Open to recommendations based on best fit for requirements + +**Technology Stack Preferences:** + +- **Programming Language:** [JavaScript/TypeScript, Python, C#, Java, Go, Other] +- **Frontend Framework:** [React, Angular, Vue.js, No Preference, Other] +- **Backend Framework:** [Express/Node.js, FastAPI/Flask, ASP.NET Core, Spring Boot, No Preference, Other] +- **Database Preference:** [SQL-based, NoSQL, No Preference, Existing System Integration] + +## Phase 5: Requirements Documentation + +Create or update Application specification with a "Project Requirements" section containing: + +```markdown +## Project Requirements + +### Project Classification +- **Type:** [POC/Development Tool/Production Application] +- **Primary Purpose:** [Brief description] +- **Target Audience:** [Description of users] + +### Scale Requirements +- **User Base:** [Expected users and growth] +- **Geographic Scope:** [Single region/Multi-region/Global] +- **Availability Needs:** [Uptime requirements] +- **Scale Category:** [Small/Medium/Large - for production apps] + +### Budget Considerations +- **Cost Priority:** [Cost-Optimized/Balanced/Performance-Focused] +- **Budget Constraints:** [Any specific limitations mentioned] +- **Pricing Preference:** [Consumption vs Reserved vs Hybrid] + +### Architectural Preferences +- **Stack Preference:** [Containers/Serverless/Hybrid/No Preference] +- **Programming Language:** [Preferred language and rationale] +- **Frontend Framework:** [Chosen framework if applicable] +- **Backend Framework:** [Chosen framework if applicable] +- **Infrastructure Control:** [Managed services vs Infrastructure control preference] +- **Integration Requirements:** [Existing systems to connect with] +- **Compliance Requirements:** [Any mentioned compliance needs] + +### Key Insights +- [Any additional context that influences architecture decisions] +- [Special requirements or constraints mentioned] +``` + +**Conversation Flow Tips:** + +- Start with open-ended questions and narrow down based on responses +- If user is unsure about technical terms, provide brief explanations +- For POCs, focus more on timeline and potential evolution rather than scale +- For production apps, spend more time on scale and reliability requirements +- Always ask "Is there anything else about your requirements I should know?" at the end +- Keep the tone consultative and helpful, not interrogative diff --git a/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md index 0d2812c9684..2662d5fe680 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md @@ -3,28 +3,30 @@ ✅ **Agent Task List** 1. **Inventory existing IaC files** - scan current working directory for all `.bicep` files -2. Read `azd-arch-plan.md` to get the **IaC File Generation Checklist** -3. Create directory structure in `./infra` following IaC rules -4. Before generating any code, always fetch Azure and Bicep best practices -5. Before generating any code, always get the latest bicep schema and version for each Azure resource type +2. **Read application spec** to get the Infrastructure as Code File Checklist with required resources +3. **Get IaC generation rules** for Azure infrastructure best practices and coding standards +4. **Get latest bicep schema versions** for each Azure resource type from the required resources +5. Create directory structure in `./infra` following IaC rules 6. For each file in the IaC checklist: - **If file exists**: Intelligently update to match requirements, preserve user customizations where possible - **If file missing**: Generate new file following templates and best practices - **Flag conflicts**: Note any incompatible configurations but proceed with updates -7. Validate all generated bicep templates compile without errors or warnings -8. Update the IaC checklist section in existing `azd-arch-plan.md` by marking completed files as [x] while preserving existing content +7. **Generate modular infrastructure**: Create generic resource modules and service-specific modules that reference them +8. Validate all generated bicep templates compile without errors or warnings +9. Update the IaC checklist section in existing application spec by marking completed files as [x] while preserving existing content 📄 **Required Outputs** - **Existing IaC inventory** documenting all current `.bicep` files found - Complete Bicep template structure in `./infra` directory based on the IaC checklist -- All files listed in the IaC File Generation Checklist from `azd-arch-plan.md` (created or updated) +- All files listed in the Infrastructure as Code File Checklist from application spec (created or updated) - Main.bicep file with subscription scope and modular deployment -- Service-specific modules for each Azure service from the checklist -- Parameter files with sensible defaults +- **Generic resource modules** for reusable Azure service patterns (e.g., `modules/containerapp.bicep`, `modules/storage.bicep`) +- **Service-specific modules** that reference generic modules with customized configurations (e.g., `modules/user-api.bicep`) +- Parameter files with sensible defaults using latest bicep schema versions - **Conflict report** highlighting any incompatible configurations that were updated - All templates validated and error-free -- Update existing `azd-arch-plan.md` IaC checklist by marking completed files as [x] while preserving existing content +- Update existing application spec IaC checklist by marking completed files as [x] while preserving existing content 🧠 **Execution Guidelines** @@ -35,12 +37,30 @@ - Note any existing modules, parameters, and resource definitions - Identify which checklist files already exist vs. need to be created -**Read IaC Checklist:** +**Read IaC Checklist and Get Generation Rules:** -- Read the "Infrastructure as Code File Checklist" section from `azd-arch-plan.md` -- This checklist specifies exactly which Bicep files need to be generated +- Read the "Infrastructure as Code File Checklist" section from application spec +- This checklist specifies exactly which Bicep files need to be generated and their purpose +- Get IaC generation rules for Azure infrastructure best practices and coding standards +- Get latest bicep schema versions for each Azure resource type identified in the checklist - Cross-reference with existing file inventory to determine update vs. create strategy +**Modular Infrastructure Generation Strategy:** + +**Generic Resource Modules:** + +- Create reusable modules for common Azure resource patterns +- Examples: `modules/containerapp.bicep`, `modules/storage.bicep`, `modules/database.bicep` +- These modules accept parameters for customization but contain standard resource configurations +- Follow IaC generation rules for naming, security, and architectural patterns + +**Service-Specific Modules:** + +- Create modules that reference generic modules with service-specific configurations +- Examples: `modules/user-api.bicep` (calls `containerapp.bicep` with user-api settings) +- These modules provide the business logic and specific parameter values +- Map each service from architecture planning to its corresponding module + **Smart File Generation Strategy:** **For Existing Files:** @@ -67,8 +87,17 @@ - Create `./infra/main.bicep` first (always required) - Create `./infra/main.parameters.json` second (always required) -- Generate each module file listed in the checklist -- Follow the exact file paths specified in the checklist +- Generate generic resource modules in `./infra/modules/` (e.g., `containerapp.bicep`, `storage.bicep`) +- Generate service-specific modules in `./infra/modules/` (e.g., `user-api.bicep`, `order-service.bicep`) +- Follow the exact file paths specified in the checklist from application spec + +**Module Generation Workflow:** + +1. **Identify required resource types** from the Infrastructure as Code File Checklist +2. **Create generic modules first** for each unique Azure resource type +3. **Create service-specific modules** that reference generic modules with specific configurations +4. **Ensure proper dependencies** between modules and main deployment template +5. **Apply IaC generation rules** consistently across all generated files **Main Parameters File Requirements:** @@ -123,17 +152,20 @@ The `./infra/main.parameters.json` file is critical for AZD integration and must ```text ./infra/ -├── main.bicep # Primary deployment template (subscription scope) -├── main.parameters.json # Default parameters +├── main.bicep # Primary deployment template (subscription scope) +├── main.parameters.json # Default parameters ├── modules/ -│ ├── container-apps.bicep -│ ├── app-service.bicep -│ ├── functions.bicep -│ ├── database.bicep -│ ├── storage.bicep -│ ├── keyvault.bicep -│ └── monitoring.bicep -└── resources.bicep # Shared resources +│ ├── containerapp.bicep # Generic Container Apps module +│ ├── app-service.bicep # Generic App Service module +│ ├── functions.bicep # Generic Azure Functions module +│ ├── database.bicep # Generic database module +│ ├── storage.bicep # Generic storage module +│ ├── keyvault.bicep # Generic Key Vault module +│ ├── monitoring.bicep # Generic monitoring module +│ ├── user-api.bicep # Service-specific module (references containerapp.bicep) +│ ├── order-service.bicep # Service-specific module (references containerapp.bicep) +│ └── shared-storage.bicep # Service-specific module (references storage.bicep) +└── resources.bicep # Shared resources ``` **Main Template Requirements:** @@ -148,8 +180,12 @@ The `./infra/main.parameters.json` file is critical for AZD integration and must 📌 **Completion Checklist** - [ ] **Existing IaC inventory completed** - all `.bicep` files in current directory catalogued -- [ ] **IaC File Generation Checklist read** from `azd-arch-plan.md` +- [ ] **Infrastructure as Code File Checklist read** from application spec +- [ ] **IaC generation rules retrieved** and applied to all generated files +- [ ] **Latest bicep schema versions obtained** for each Azure resource type - [ ] **Update vs. create strategy determined** for each file in checklist +- [ ] **Generic resource modules created** for each unique Azure resource type +- [ ] **Service-specific modules generated** that reference generic modules appropriately - [ ] **All files from checklist generated or updated** in the correct locations - [ ] **User customizations preserved** where compatible with requirements - [ ] **Conflicts documented** and resolved with functional priority @@ -160,4 +196,4 @@ The `./infra/main.parameters.json` file is critical for AZD integration and must - [ ] Naming conventions and tagging implemented correctly - [ ] Security best practices implemented (Key Vault, managed identities) - [ ] All Bicep modules are created with latest bicep schema version and meet Azure and Bicep best practices -- [ ] **IaC checklist in `azd-arch-plan.md` updated** by marking completed files as [x] while preserving existing content +- [ ] **Infrastructure as Code File Checklist in application spec updated** by marking completed files as [x] while preserving existing content diff --git a/cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md b/cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md index e69de29bb2d..e75365023f6 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md @@ -0,0 +1,48 @@ +# AZD Stack Resources List + +✅ **Agent Task List** + +1. Review the baseline Azure resources required for all AZD projects +2. Review the stack-specific Azure resources for the selected technology stack +3. Understand the purpose and configuration of each resource type +4. Use these resource definitions for architecture planning and infrastructure generation + +📄 **Required Outputs** + +- Complete understanding of baseline resources shared across all stacks +- Detailed knowledge of stack-specific resources and their purposes +- Azure resource type identifiers for precise infrastructure generation +- Resource relationships and dependencies for proper deployment ordering + +🧠 **Execution Guidelines** + +**CRITICAL:** This tool provides the definitive list of Azure resources required for each technology stack. These resource definitions should be used as the foundation for all architecture planning and infrastructure generation activities. + +## Resource Categories + +### Baseline Resources + +All AZD projects receive a standard set of baseline resources that provide essential capabilities like logging, monitoring, configuration management, and secure storage. These resources are provisioned regardless of the selected technology stack. + +### Stack-Specific Resources + +Each technology stack (Containers, Serverless, Logic Apps) includes additional resources optimized for that particular architectural approach. These resources provide the compute and orchestration capabilities specific to the chosen stack. + +## Usage in Architecture Planning + +When proceeding to architecture planning, use these resource definitions to: + +- Map application components to appropriate Azure resources +- Plan resource group organization and naming conventions +- Determine resource dependencies and deployment sequencing +- Configure monitoring and logging integration +- Set up security and access control policies + +## Infrastructure Generation Integration + +During infrastructure generation, these resource specifications provide: + +- Exact Azure resource type identifiers for Bicep templates +- Required configuration parameters for each resource +- Baseline security and monitoring configurations +- Integration patterns between resources diff --git a/cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md b/cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md index e69de29bb2d..ec33f32efe2 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md @@ -0,0 +1,227 @@ +# AZD Project Modernization and Migration Instructions + +✅ **Agent Task List** + +1. Analyze existing application architecture and codebase +2. Conduct user intent discovery to understand requirements and constraints +3. Determine optimal technology stack based on existing code and user preferences +4. Perform discovery analysis for comprehensive component identification +5. Conduct architecture planning for Azure service selection and infrastructure design +6. Generate files to create AZD-compatible project structure +7. Run full azd project validation and address all errors +8. Document complete modernization in Application specification + +📄 **Required Outputs** + +- Complete AZD-compatible project structure for existing application +- Valid `azure.yaml` configuration file mapping existing components +- Bicep infrastructure templates in `./infra` directory +- Dockerfiles for containerizable services (where applicable) +- Comprehensive Application specification documentation preserving existing project context +- Validated project ready for `azd up` deployment + +🧠 **Execution Guidelines** + +**CRITICAL:** This tool modernizes existing applications to be AZD-compatible. Always preserve existing application functionality while adding Azure deployment capabilities. Check for existing Application specification and preserve all user modifications. + +## Workspace Analysis and Initial Assessment + +**Existing Project Evaluation:** + +- Scan workspace for application components, frameworks, and technologies +- Identify programming languages, entry points, and dependencies +- Assess existing containerization (Docker files, docker-compose) +- Review existing infrastructure or deployment configurations +- Note any existing Azure resources or configuration + +**Technology Stack Detection:** + +Based on discovered components, attempt to automatically determine appropriate stack: + +- **Containers Stack**: If Docker files exist, complex dependencies, or traditional web/API applications +- **Serverless Stack**: If function-based architecture, event handlers, or simple stateless APIs detected +- **Logic Apps Stack**: If workflow files, extensive API integrations, or business process automation detected + +**Ambiguity Handling:** + +If stack selection is unclear from code analysis, proceed to stack selection process to gather user preferences. + +## Requirements Discovery and Intent Understanding + +**Conduct User Intent Discovery Process:** + +Even with existing code, gather requirements to understand: + +- Current application purpose and target audience +- Performance and scalability expectations for Azure deployment +- Budget and cost considerations for cloud migration +- Compliance and security requirements +- Timeline and migration urgency + +**Migration-Specific Questions:** + +- "What are your main goals for migrating this application to Azure?" +- "Are there any existing pain points or limitations you want to address?" +- "Do you need to maintain backward compatibility during the migration?" +- "Are there specific Azure services you want to use or avoid?" + +**Documentation Target:** + +Create or update Application specification with "Migration Requirements" section including existing project context and migration goals. + +## Stack Selection and Validation + +**Automatic Stack Determination:** + +If technology stack was clearly identified from code analysis, document the decision with rationale. + +**Manual Stack Selection:** + +If ambiguous, conduct stack selection process focusing on: + +- Team comfort with existing architecture patterns +- Desire to modernize vs maintain current approach +- Performance and operational requirements +- Integration complexity and existing dependencies + +**Stack Decision Documentation:** + +Update Application specification with "Technology Stack Selection" section explaining chosen approach and migration strategy. + +## Comprehensive Discovery and Analysis + +**Perform Discovery Analysis Process:** + +Use discovery analysis capability to: + +- Create comprehensive inventory of all application components +- Map existing dependencies and communication patterns +- Identify database and external service connections +- Document current architecture and data flows +- Assess containerization readiness for each component + +**Migration-Aware Analysis:** + +- Identify components that need minimal changes vs significant refactoring +- Note existing infrastructure that can be preserved or needs replacement +- Document any legacy dependencies that require special handling +- Assess cloud-readiness of each component + +**Documentation Target:** + +Update Application specification with complete "Application Discovery" section including existing architecture analysis and migration considerations. + +## Azure Architecture Planning and Service Mapping + +**Conduct Architecture Planning Process:** + +Use architecture planning capability to: + +- Map each existing component to optimal Azure services +- Design migration-friendly infrastructure organization +- Plan phased migration approach if needed +- Select appropriate database and messaging services +- Design containerization strategy respecting existing patterns + +**Migration Strategy Design:** + +- Plan for minimal disruption deployment approach +- Design rollback strategies and blue-green deployment options +- Consider data migration requirements and strategies +- Plan for environment parity (dev, staging, production) + +**Documentation Target:** + +Update Application specification with "Azure Service Mapping" and "Migration Architecture" sections. + +## AZD Project Structure Creation + +**Artifact Generation Orchestration:** + +Perform comprehensive artifact generation process: + +1. **Application Integration**: Preserve existing application structure while adding AZD compatibility +2. **Docker Configuration Generation**: Create or update Docker files for containerizable services +3. **Infrastructure Template Generation**: Create Bicep templates for Azure resources +4. **Azure.yaml Generation**: Create AZD configuration mapping existing and new components + +**Migration-Specific Considerations:** + +- Preserve existing build processes and scripts where possible +- Maintain existing environment variable and configuration patterns +- Ensure generated Docker files work with existing application structure +- Create infrastructure that supports existing application requirements + +**Configuration Preservation:** + +- Maintain existing database schemas and connection patterns +- Preserve API contracts and service interfaces +- Keep existing authentication and authorization patterns +- Maintain current logging and monitoring approaches where compatible + +## Project Validation and Deployment Readiness + +**Perform Project Validation Process:** + +Use project validation capability to ensure: + +- Azure.yaml configuration correctly maps all application components +- Bicep templates deploy successfully in test environment +- All application components start and function correctly +- Database connections and external dependencies work properly +- Environment configuration is complete and secure + +**Migration Validation:** + +- Verify existing functionality is preserved +- Test performance matches or improves upon current deployment +- Confirm security and compliance requirements are met +- Validate monitoring and logging capabilities + +## Implementation Workflow Guide + +**Complete Modernization Workflow:** + +```text +1. Workspace Analysis → 2. User Intent Discovery → 3. Stack Selection (if needed) → +4. Discovery Analysis → 5. Architecture Planning → 6. Artifact Generation → +7. Project Validation +``` + +**Iterative Refinement Workflow:** + +```text +1. Review Application specification → 2. Update specific components → 3. Regenerate affected artifacts → +4. Project Validation +``` + +**Incremental Migration Workflow:** + +```text +1. Select component subset → 2. Focused discovery → 3. Component-specific generation → +4. Validation → 5. Repeat for remaining components +``` + +## Success Criteria and Completion Checklist + +**Modernization Completion Requirements:** + +- [ ] All existing application components identified and mapped to Azure services +- [ ] User intent and migration requirements documented and addressed +- [ ] Technology stack selection completed with clear rationale +- [ ] Complete artifact generation executed (application code, Docker configs, infrastructure, azure.yaml) +- [ ] All existing application functionality preserved and verified +- [ ] Performance and security requirements met or exceeded +- [ ] Application specification comprehensive documentation created while preserving existing content +- [ ] AZD environment initialized and tested +- [ ] Project validation confirms deployment readiness +- [ ] Application confirmed working end-to-end with `azd up` + +**Migration Success Indicators:** + +- Existing application runs correctly in Azure environment +- All data connections and external integrations function properly +- Performance meets or exceeds current deployment +- Security and compliance requirements are satisfied +- Team can deploy and manage using AZD workflows +- Rollback procedures tested and documented diff --git a/cli/azd/internal/mcp/tools/prompts/azd_new_project.md b/cli/azd/internal/mcp/tools/prompts/azd_new_project.md index e69de29bb2d..4ee7bcaefe9 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_new_project.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_new_project.md @@ -0,0 +1,227 @@ +# AZD New Project Creation Orchestration Instructions + +✅ **Agent Task List** + +1. Welcome user and confirm they want to create a new AZD project from scratch +2. Conduct user intent discovery to understand project requirements and constraints +3. Perform stack selection process to determine optimal technology approach +4. Conduct architecture planning to design Azure service mappings and infrastructure +5. Document comprehensive project specification in Application specification +6. Provide file generation guidance and next steps for implementation +7. Run full azd project validation and address all errors +8. Ensure project specification is fully up to date + +📄 **Required Outputs** + +- Complete Application specification specification document with all project details +- Clear technology stack recommendation with rationale +- Azure service architecture design with component mappings +- File generation roadmap for implementation phase +- Project validation checklist for final verification +- Ready-to-implement project specification + +🧠 **Execution Guidelines** + +**CRITICAL:** This tool orchestrates the complete new project creation flow. Start fresh and guide the user through each phase systematically. Create comprehensive documentation that serves as the blueprint for file generation and deployment. + +## Phase 1: Project Initiation and Welcome + +**Initial Setup:** + +- Confirm this is a new project creation (no existing code or infrastructure) +- Verify the user wants to create an AZD-compatible Azure project +- Explain the process: "We'll discover your requirements, select the best technology stack, and create a complete project specification" +- Create new Application specification file to document the entire journey + +**Prerequisites Check:** + +- User has a clear idea of what application they want to build +- User has access to Azure subscription or is planning for Azure deployment +- User is ready to answer questions about their project requirements and constraints + +## Phase 2: Requirements Discovery + +**Conduct User Intent Discovery Process:** + +Use the user intent discovery capability to understand: + +- Project purpose and classification (POC, Development Tool, Production Application) +- Expected scale and user base requirements +- Budget and cost considerations +- Performance and availability expectations +- Timeline and deployment urgency + +**Key Questions to Address:** + +- What problem does this application solve? +- Who are the target users and how many? +- What are the critical success factors? +- Are there specific compliance or security requirements? +- What's the expected timeline for deployment? + +**Documentation Target:** + +Update Application specification with comprehensive "Project Requirements" section including all discovered intent and constraints. + +## Phase 3: Technology Stack Selection + +**Perform Stack Selection Process:** + +Use the stack selection capability to determine: + +- Team technical expertise and preferences +- Application characteristics and complexity +- Performance and scalability requirements +- Integration and workflow needs + +**Stack Options to Evaluate:** + +- **Containers**: For complex applications requiring infrastructure control +- **Serverless**: For event-driven, cost-optimized, simple deployments +- **Logic Apps**: For integration-heavy, workflow automation scenarios + +**Selection Criteria:** + +- Align with team expertise and operational preferences +- Match application performance and scaling requirements +- Support integration and business process needs +- Optimize for identified budget and cost constraints + +**Documentation Target:** + +Update Application specification with "Stack Selection" section documenting chosen stack and detailed rationale. + +## Phase 4: Application Architecture Definition + +**Project Specification Development:** + +Based on user requirements and selected stack, define: + +- **Application Components**: Break down the application into logical services/components +- **Component Responsibilities**: Define what each component does and its purpose +- **Data Requirements**: Identify data storage, processing, and flow needs +- **Integration Points**: Map external systems, APIs, and service dependencies +- **User Interaction Patterns**: Define how users interact with the application + +**Architecture Planning Considerations:** + +- Component communication patterns (REST APIs, messaging, events) +- Data persistence strategies (databases, file storage, caching) +- Authentication and authorization requirements +- Monitoring and logging needs +- Security and compliance requirements + +**Documentation Target:** + +Create detailed "Application Architecture" section in Application specification with component breakdown and specifications. + +## Phase 5: Azure Service Architecture Planning + +**Conduct Architecture Planning Process:** + +Use the architecture planning capability to: + +- Map each application component to optimal Azure services +- Design infrastructure organization and resource grouping +- Plan networking and security architecture +- Select appropriate database and messaging services +- Design containerization strategy for selected stack + +**Service Selection Focus:** + +- Leverage the selected stack (Containers/Serverless/Logic Apps) as primary guidance +- Choose services that align with performance and scale requirements +- Optimize for identified budget and cost constraints +- Ensure services support required integrations and compliance needs + +**Infrastructure Design Elements:** + +- Resource group organization +- Networking and connectivity approach +- Security and access control strategy +- Monitoring and observability setup +- Backup and disaster recovery considerations + +**Documentation Target:** + +Update Application specification with complete "Azure Service Mapping" and "Infrastructure Architecture" sections. + +## Phase 6: Implementation Roadmap Creation + +**Artifact Generation Planning:** + +Based on the architecture design, prepare for comprehensive artifact generation: + +- **Application Scaffolding Strategy**: Define starter code structure and framework setup +- **Infrastructure Planning**: Identify all required Azure resources and configurations +- **Containerization Approach**: Plan Docker configurations if applicable +- **Configuration Management**: Design azure.yaml structure and service mappings + +**Development Workflow Setup:** + +- CI/CD pipeline requirements and integration points +- Local development environment setup and testing +- Deployment and rollback procedures +- Monitoring and observability configuration + +**Documentation Target:** + +Add "Implementation Roadmap" section to Application specification with detailed artifact generation requirements and setup guidance. + +## Phase 7: Validation and Next Steps + +**Project Validation Preparation:** + +Reference the project validation capability to prepare for: + +- Azure.yaml configuration validation +- Bicep template structure verification +- Environment setup validation +- Deployment readiness assessment + +**Next Steps Guidance:** + +Provide clear direction for moving to implementation: + +- "Your project specification is complete and documented in Application specification" +- "Next phase: Execute artifact generation to create your complete project structure" +- "Use the artifact generation capability to create application scaffolding, Docker configurations, infrastructure templates, and azure.yaml file" +- "After artifact generation, use project validation to ensure everything is properly configured" +- "Finally, run `azd up` to deploy your application to Azure" + +**Final Documentation Structure:** + +Ensure Application specification contains all required sections: + +```markdown +# [Project Name] - AZD Architecture Plan + +## Project Requirements +[User intent discovery results] + +## Stack Selection +[Chosen stack and rationale] + +## Application Architecture +[Component breakdown and specifications] + +## Azure Service Mapping +[Component to Azure service mappings] + +## Infrastructure Architecture +[Resource organization and networking design] + +## Implementation Roadmap +[File generation and setup guidance] + +## Validation Checklist +[Project validation requirements] +``` + +**Success Criteria:** + +- User understands their project architecture completely +- All technical decisions are documented with clear rationale +- Implementation path is clear and actionable +- Project is ready for file generation phase +- Validation requirements are understood diff --git a/cli/azd/internal/mcp/tools/prompts/azd_plan_init.md b/cli/azd/internal/mcp/tools/prompts/azd_plan_init.md index e8bd2e1685c..995d7fa9dcc 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_plan_init.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_plan_init.md @@ -1,98 +1,194 @@ -# AZD Application Initialization and Migration Instructions +# AZD Project Initialization Decision Tree Instructions ✅ **Agent Task List** -1. **Check Progress:** Review existing `azd-arch-plan.md` to understand completed work -2. **Phase 1:** Execute `azd_discovery_analysis` for component identification -3. **Phase 2:** Execute `azd_architecture_planning` for Azure service selection -4. **Phase 3:** Execute file generation tools (`azd_azure_yaml_generation`, `azd_infrastructure_generation`, `azd_docker_generation`) -5. **Phase 4:** Execute `azd_project_validation` for complete validation -6. **Final:** Confirm project readiness for deployment +1. Analyze current workspace to determine project state and contents +2. Classify workspace as "empty/minimal" or "existing application" +3. Route user to appropriate workflow: new project creation or application modernization +4. Confirm routing decision with user before proceeding +5. Perform the selected workflow with proper tool orchestration +6. Update application specification after each step within the workflow 📄 **Required Outputs** -- Complete AZD-compatible project structure -- Valid `azure.yaml` configuration file -- Bicep infrastructure templates in `./infra` directory -- Dockerfiles for containerizable services -- Comprehensive `azd-arch-plan.md` documentation (created or updated while preserving existing content) -- Validated project ready for `azd up` deployment +- Workspace analysis summary with routing decision rationale +- User confirmation of selected workflow path +- Complete execution of chosen workflow (new project or modernization) +- Professional project specification document (app-spec.md) +- Validated AZD-compatible project ready for deployment 🧠 **Execution Guidelines** -**CRITICAL:** Always check if `azd-arch-plan.md` exists first to understand current progress and avoid duplicate work. If the file exists, preserve all existing content and user modifications while updating relevant sections. +**CRITICAL:** This tool serves as the entry point for AZD project initialization. It analyzes the workspace and routes users to the most appropriate workflow. Always confirm the routing decision with users before proceeding. -**Complete Workflow Phases:** +## Workspace Analysis and Classification -**Phase 1: Review Existing Progress** +**Comprehensive Workspace Scan:** -- Check if `azd-arch-plan.md` exists in current directory -- If exists: Review thoroughly and skip completed phases -- If doesn't exist: Proceed to Phase 2 +Analyze the current directory and subdirectories for: -**Phase 2: Discovery and Analysis** +**Application Indicators (suggest modernization path):** -- Tool: `azd_discovery_analysis` -- Scans files recursively, documents structure/languages/frameworks -- Identifies entry points, maps dependencies, creates component inventory -- Updates `azd-arch-plan.md` with findings +- Programming language files: `.js`, `.ts`, `.py`, `.cs`, `.java`, `.go`, `.php`, `.rb`, etc. +- Framework configuration files: `package.json`, `requirements.txt`, `pom.xml`, `Gemfile`, `go.mod`, `composer.json` +- Application entry points: `main.py`, `app.js`, `index.js`, `Program.cs`, `Main.java`, `main.go` +- Web application files: HTML, CSS, JavaScript files, template files +- Docker configurations: `Dockerfile`, `docker-compose.yml`, `.dockerignore` +- Build configurations: `Makefile`, `CMakeLists.txt`, build scripts +- Configuration files: `.env`, `appsettings.json`, `config.yaml`, etc. -**Phase 3: Architecture Planning and Azure Service Selection** +**Minimal Content Indicators (suggest new project path):** -- Tool: `azd_architecture_planning` -- Maps components to Azure services, plans hosting strategies -- Designs database/messaging architecture, creates containerization strategies -- Updates `azd-arch-plan.md` with service selections +- Only documentation files: `README.md`, `CHANGELOG.md`, `LICENSE`, etc. +- Git files: `.gitignore`, `.git` directory +- Empty directories or placeholder files +- Basic configuration without dependencies: empty `package.json`, template files -**Phase 4: File Generation (Execute in Sequence)** +**Existing AZD Project Indicators:** -Using available tools - Generate the following files: +- `azure.yaml` file exists +- `./infra/` directory with Bicep templates +- Project specification document (app-spec.md) -1. **Docker Configurations:** Generate docker files (Required for containerizable services) -2. **Infrastructure Templates:** Generate IaC infrastructure templates (Required for all projects) -3. **Azure.yaml Configuration:** Generate `azure.yaml` file (Required for all projects) +## Decision Logic and Routing -**Phase 5: Project Validation and Environment Setup** +**Classification Rules:** -Using available tools - Perform and end-to-end AZD project validation +**Route to New Project Creation if:** -- Validates azure.yaml against schema -- Validate AZD environment exists -- Validate infrastructure templates -- Ensures AZD environment exists, tests packaging, validates deployment preview -- Provides readiness confirmation +- No programming language files found +- Only documentation and git files present +- Empty workspace or minimal placeholder content +- User explicitly wants to start from scratch -**Usage Patterns:** +**Route to Application Modernization if:** -**Complete New Project Migration:** +- Application code files detected (any programming language) +- Framework configuration files present +- Docker files or containerization artifacts found +- Existing build or deployment configurations +- Clear application structure and entry points -```text -1. Review azd-arch-plan.md → 2. azd_discovery_analysis → 3. azd_architecture_planning → -4. azd_azure_yaml_generation → 5. azd_infrastructure_generation → 6. azd_docker_generation → -7. azd_project_validation -``` +**Handle Existing AZD Projects:** -**Update Existing AZD Project:** +- If `azure.yaml` exists, determine if this is an update/refinement workflow +- Check completeness of existing AZD configuration +- Route to appropriate maintenance or enhancement workflow -```text -1. Review azd-arch-plan.md → 2. File generation tools → 3. azd_project_validation -``` +**Ambiguous Cases:** + +- When workspace contains mixed content, present findings and let user choose +- If minimal code exists but unclear if it's a real application vs examples +- When existing AZD files are incomplete or outdated + +## User Confirmation and Workflow Selection + +**Present Analysis Results:** + +After workspace scan, provide summary: + +- "I found [X] application files including [languages/frameworks detected]" +- "The workspace appears to contain [existing application/minimal content]" +- "Based on this analysis, I recommend the [modernization/new project] workflow" + +**Confirmation Questions:** + +**For Modernization Path:** + +- "I detected an existing application with [technologies found]. Would you like to modernize this application for Azure deployment using AZD?" +- "This will add Azure deployment capabilities while preserving your existing application structure." + +**For New Project Path:** + +- "The workspace appears empty or contains only documentation. Would you like to create a new AZD project from scratch?" +- "This will guide you through defining requirements and creating a complete new application." + +**Alternative Option:** + +- Always offer the alternative: "Or would you prefer to [create new project/modernize existing] instead?" + +## Workflow Execution + +**New Project Creation Workflow:** + +If user confirms new project path: -**Quick Service Addition:** +- Perform new project creation process +- Guide through complete requirements gathering and architecture planning +- Create comprehensive project specification and implementation roadmap +- Reference appropriate file generation and validation processes + +**Application Modernization Workflow:** + +If user confirms modernization path: + +- Perform application modernization process +- Analyze existing architecture and gather migration requirements +- Plan Azure service mapping and infrastructure design +- Create AZD-compatible project structure while preserving existing functionality + +**Existing AZD Project Enhancement:** + +If AZD project already exists: + +- Review current project specification (app-spec.md) for completed work +- Identify gaps or areas needing updates +- Perform targeted improvements or additions +- Validate and test updated configuration + +## Decision Tree Summary ```text -1. Review azd-arch-plan.md → 2. azd_discovery_analysis → 3. azd_azure_yaml_generation → -4. azd_docker_generation → 5. azd_project_validation +Workspace Analysis + ├── Empty/Minimal Content Found + │ ├── Confirm: New Project Creation? → Begin New Project Workflow + │ └── User Override → Begin Modernization Workflow + │ + ├── Application Code Found + │ ├── Confirm: Modernize Existing? → Begin Modernization Workflow + │ └── User Override → Begin New Project Workflow + │ + ├── Existing AZD Project Found + │ ├── Complete Configuration → Offer Enhancement Options + │ └── Incomplete Configuration → Resume/Fix Configuration + │ + └── Ambiguous Content + └── Present Options → User Selects → Begin Chosen Workflow ``` -📌 **Completion Checklist** - -- [ ] All application components identified and classified in discovery phase -- [ ] Azure service selections made for each component with rationale -- [ ] `azure.yaml` file generated and validates against schema -- [ ] Infrastructure files generated and compile without errors -- [ ] Dockerfiles created for containerizable components -- [ ] `azd-arch-plan.md` created or updated to provide comprehensive project documentation while preserving existing content -- [ ] AZD environment initialized and configured -- [ ] All validation checks pass using `azd_project_validation` tool -- [ ] Project confirmed ready for deployment with `azd up` +## Error Handling and Edge Cases + +**Workspace Access Issues:** + +- If unable to scan workspace, ask user to describe their project +- Provide manual selection options for workflow choice + +**Mixed Content Scenarios:** + +- Example code mixed with real application code +- Multiple unrelated applications in same workspace +- Legacy or deprecated code alongside current application + +**User Uncertainty:** + +- If user is unsure about their project type, provide guided questions +- Offer to start with discovery process to help determine appropriate path +- Allow workflow switching if initial choice proves incorrect + +## Success Criteria + +**Successful Routing Achieved When:** + +- Workspace analysis accurately reflects actual content +- User understands and confirms the recommended workflow +- Selected workflow matches user's actual goals and project state +- Execution proceeds smoothly with appropriate tool orchestration +- Final result meets user's deployment and functionality requirements + +**Quality Assurance:** + +- Decision rationale is clearly documented +- User confirmation is explicit and informed +- Workflow execution follows established patterns +- Documentation maintains consistency across all paths +- Final validation confirms project readiness diff --git a/cli/azd/internal/mcp/tools/prompts/azd_select_stack.md b/cli/azd/internal/mcp/tools/prompts/azd_select_stack.md index e69de29bb2d..a108dc9c9ee 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_select_stack.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_select_stack.md @@ -0,0 +1,194 @@ +# AZD Stack Selection and Recommendation Instructions + +✅ **Agent Task List** + +1. Review existing Application specification for project requirements and user intent findings +2. Assess team expertise and technical preferences through targeted questions +3. Evaluate performance and scalability requirements for the application +4. Determine workflow and integration complexity needs +5. Select the optimal single stack: Containers, Serverless, or Logic Apps +6. Document stack selection rationale in Application specification + +📄 **Required Outputs** + +- Single stack recommendation: **Containers**, **Serverless**, or **Logic Apps** +- Clear rationale for stack selection based on user responses +- Updated Application specification with "Stack Selection" section +- Next steps guidance for the chosen stack + +🧠 **Execution Guidelines** + +**CRITICAL:** Always check for existing Application specification first to understand project context. Use generic, non-Azure-specific language when asking questions. Focus on application characteristics and team capabilities rather than specific Azure services. + +## Phase 1: Context Review and Setup + +**Review Existing Information:** + +- Check if Application specification exists and review "Project Requirements" section +- Note project type (POC/Development/Production), scale category, and architectural preferences +- Use existing findings to tailor questions and skip redundant inquiries + +**If no prior context exists, gather basic project understanding:** + +- "What type of application are you building?" (web app, API, data processing, etc.) +- "What's the primary function of your application?" + +## Phase 2: Team Expertise and Technical Preference Assessment + +**Development Experience Questions:** + +- "What's your team's experience level with containerization technologies like Docker?" +- "Have you worked with event-driven or function-based programming before?" +- "Does your team have experience with workflow automation or business process tools?" +- "What programming languages and frameworks is your team most comfortable with?" + +**Operational Preferences:** + +- "Do you prefer to have control over the underlying infrastructure, or would you rather focus purely on code?" +- "How comfortable is your team with managing deployments and scaling decisions?" +- "Would you prefer predictable costs or pay-per-use pricing that scales with demand?" + +## Phase 3: Application Characteristics Analysis + +**Performance and Scalability Questions:** + +- "Does your application need to handle sudden spikes in traffic or maintain steady performance?" +- "How important are cold start times? Do you need instant response to requests?" +- "Will your application run continuously or respond to specific events/triggers?" +- "Do you expect heavy computational workloads or primarily lightweight request processing?" + +**Integration and Workflow Questions:** + +- "Does your application primarily connect different systems, APIs, or data sources together?" +- "Are you building business workflows that involve multiple steps, approvals, or decision points?" +- "Do you need to integrate with many external services, databases, or legacy systems?" +- "Is your application more about processing data/requests or orchestrating complex business processes?" + +**Complexity and Maintenance Questions:** + +- "How complex is your business logic? Is it straightforward request-response or multi-step processes?" +- "Do you need to handle file processing, document workflows, or data transformations?" +- "Will you need visual workflow designers or are you comfortable with code-based solutions?" + +## Phase 4: Stack Selection Logic + +**Use this decision framework to recommend a single stack:** + +### Containers Stack Recommendation + +**Choose when:** + +- Team has Docker/containerization experience OR wants infrastructure control +- Application has complex dependencies or custom runtime requirements +- Need consistent performance with minimal cold starts +- Building traditional web applications, APIs, or microservices +- Require custom scaling logic or persistent connections +- Application runs continuously or has predictable traffic patterns + +**Key Indicators:** + +- "We want control over our deployment environment" +- "We have complex dependencies that need specific configurations" +- "Performance consistency is critical for our users" +- "We're building a traditional web app or API service" + +### Serverless Stack Recommendation + +**Choose when:** + +- Team prefers to focus on code over infrastructure management +- Application is event-driven or has variable/unpredictable traffic +- Cost optimization is important (pay only for usage) +- Building simple APIs, data processing, or reactive applications +- Quick development and deployment cycles are prioritized +- Automatic scaling without configuration is desired + +**Key Indicators:** + +- "We want to focus on writing code, not managing servers" +- "Our traffic is unpredictable or event-based" +- "We want to minimize operational overhead" +- "We're building functions that respond to specific triggers" + +### Logic Apps Stack Recommendation + +**Choose when:** + +- Application is primarily about connecting systems and orchestrating workflows +- Team needs visual workflow design capabilities +- Building business process automation or integration solutions +- Multiple external API integrations are required +- Non-developers need to understand or modify workflows +- Complex business rules and approval processes are involved + +**Key Indicators:** + +- "We're connecting multiple existing systems together" +- "We need to automate business processes with multiple steps" +- "We have many external APIs and services to integrate" +- "Non-technical team members need to understand the workflow" +- "We're building automation that involves approvals or decision trees" + +## Phase 5: Final Selection and Documentation + +**Selection Process:** + +1. Score each stack based on user responses (internal agent logic) +2. Select the highest-scoring stack +3. If tied, prefer in order: Logic Apps (for integration-heavy), Containers (for performance-critical), Serverless (for simplicity) + +**Required Documentation in Application specification:** + +Create or update with "Stack Selection" section: + +```markdown +## Stack Selection + +### Recommended Stack: [CONTAINERS/SERVERLESS/LOGIC APPS] + +### Selection Rationale +- **Team Expertise:** [Summary of team capabilities and preferences] +- **Performance Requirements:** [Key performance and scalability factors] +- **Application Characteristics:** [Primary application type and complexity] +- **Integration Needs:** [External systems and workflow requirements] + +### Key Decision Factors +- [List 3-4 main reasons why this stack was chosen] +- [Include specific user responses that influenced the decision] + +### Next Steps +- [Specific guidance for proceeding with the chosen stack] +- [Get the specific Azure resources required for this stack] +- [Architecture planning will map these resources to your application components] +``` + +**Conversation Closure:** + +- Summarize the selection: "Based on your requirements, I recommend the **[Stack Name]** stack because..." +- Explain the key benefits: "This choice will give you..." +- Provide confidence: "This stack aligns well with your team's expertise in..." +- Offer next steps: "The next phase will define the specific Azure resources for your chosen stack." + +**Stack-Specific Next Steps Guidance:** + +*Containers:* + +- "We'll configure Container Apps environment and registry for your containerized applications" +- "Each application component will get its own Container App instance" +- "Consider container orchestration, networking, and scaling requirements" + +*Serverless:* + +- "We'll set up Azure Functions with appropriate triggers and bindings" +- "Plan for event-driven architecture with the baseline monitoring and configuration services" +- "Determine function hosting plans and scaling strategies" + +*Logic Apps:* + +- "We'll design workflows using Logic Apps with visual workflow designer" +- "Map out integration points with external systems and APIs" +- "Leverage the baseline services for configuration, secrets, and monitoring" + +**Resource Planning Notes:** + +All stacks will include the standard baseline resources plus the stack-specific compute resources. Retrieve the complete resource definitions for architecture planning. diff --git a/cli/azd/internal/mcp/tools/prompts/prompts.go b/cli/azd/internal/mcp/tools/prompts/prompts.go index b5166fcef63..91dcc19215d 100644 --- a/cli/azd/internal/mcp/tools/prompts/prompts.go +++ b/cli/azd/internal/mcp/tools/prompts/prompts.go @@ -30,3 +30,21 @@ var AzdDockerGenerationPrompt string //go:embed azd_project_validation.md var AzdProjectValidationPrompt string + +//go:embed azd_identify_user_intent.md +var AzdIdentifyUserIntentPrompt string + +//go:embed azd_select_stack.md +var AzdSelectStackPrompt string + +//go:embed azd_new_project.md +var AzdNewProjectPrompt string + +//go:embed azd_modernize_project.md +var AzdModernizeProjectPrompt string + +//go:embed azd_artifact_generation.md +var AzdArtifactGenerationPrompt string + +//go:embed azd_appcode_generation.md +var AzdAppCodeGenerationPrompt string diff --git a/cli/azd/internal/mcp/tools/resources/app-spec-template.md b/cli/azd/internal/mcp/tools/resources/app-spec-template.md index e69de29bb2d..9c08478261a 100644 --- a/cli/azd/internal/mcp/tools/resources/app-spec-template.md +++ b/cli/azd/internal/mcp/tools/resources/app-spec-template.md @@ -0,0 +1,295 @@ +# {{.ProjectName}} - Application Specification + +**Generated**: {{.GeneratedDate}} +**Last Updated**: {{.LastUpdated}} + +## Project Overview + +**Project Name**: {{.ProjectName}} +**Project Type**: [To be determined during requirements discovery] +**Target Platform**: Microsoft Azure with Azure Developer CLI (AZD) + +This document serves as the comprehensive specification and architecture plan for the {{.ProjectName}} application. It captures all decisions, requirements, and design choices made during the project planning and development process. + +## Project Requirements + +*This section captures user intent, business requirements, and project constraints.* + +### Project Classification +- **Type**: [POC/Development Tool/Production Application] +- **Primary Purpose**: [Brief description of what the application does] +- **Target Audience**: [Description of intended users] +- **Business Value**: [Problem being solved or value being created] + +### Scale and Performance Requirements +- **Expected User Base**: [Number of users and growth projections] +- **Geographic Scope**: [Single region/Multi-region/Global distribution] +- **Availability Requirements**: [Uptime expectations and SLA requirements] +- **Performance Expectations**: [Response time, throughput, and scalability needs] +- **Scale Category**: [Small/Medium/Large - for production applications] + +### Budget and Cost Considerations +- **Cost Priority**: [Cost-Optimized/Balanced/Performance-Focused] +- **Budget Constraints**: [Any specific budget limitations or targets] +- **Pricing Model Preference**: [Consumption-based/Reserved/Hybrid pricing] +- **Cost Optimization Strategy**: [Approach to managing and controlling costs] + +### Technology and Architectural Preferences +- **Programming Language**: [Primary development language and rationale] +- **Frontend Framework**: [Chosen frontend technology if applicable] +- **Backend Framework**: [Chosen backend technology if applicable] +- **Database Preference**: [SQL/NoSQL preferences and specific technologies] +- **Infrastructure Approach**: [Containers/Serverless/Hybrid preference] +- **Integration Requirements**: [External systems and APIs to connect with] +- **Compliance Requirements**: [Security, regulatory, or organizational requirements] + +## Technology Stack Selection + +*This section documents the chosen technology approach and rationale.* + +### Selected Stack: [CONTAINERS/SERVERLESS/LOGIC APPS] + +#### Selection Rationale +- **Team Expertise**: [Summary of team capabilities that influenced the decision] +- **Application Characteristics**: [Key application traits that drove the choice] +- **Performance Requirements**: [How the selected stack meets performance needs] +- **Integration Needs**: [How the stack supports required integrations] +- **Cost Considerations**: [How the stack aligns with budget requirements] + +#### Technology Decisions +- **Infrastructure Pattern**: [Detailed explanation of chosen approach] +- **Development Framework**: [Primary frameworks and libraries selected] +- **Data Storage Strategy**: [Database and storage technology choices] +- **Integration Pattern**: [How components will communicate and integrate] + +## Application Architecture + +*This section defines the application structure and component organization.* + +### Application Components + +#### Component Overview +| Component Name | Type | Technology | Purpose | Dependencies | +|---------------|------|------------|---------|--------------| +| [component-1] | [API/SPA/Worker/Function] | [Technology] | [Brief description] | [List dependencies] | +| [component-2] | [API/SPA/Worker/Function] | [Technology] | [Brief description] | [List dependencies] | + +#### Component Details + +**[Component Name 1]** +- **Type**: [API Service/SPA Application/Background Worker/Function/etc.] +- **Technology**: [Specific framework and language] +- **Purpose**: [Detailed description of component responsibility] +- **Data Access**: [How component interacts with data storage] +- **External Integrations**: [APIs, services, or systems this component connects to] +- **Scaling Requirements**: [Expected load and scaling characteristics] + +### Data Architecture + +#### Data Storage Strategy +- **Primary Database**: [Technology choice and rationale] +- **Caching Strategy**: [Caching approach and technologies] +- **Data Flow**: [How data moves between components] +- **Backup and Recovery**: [Data protection and disaster recovery approach] + +#### Data Models +- **Core Entities**: [Main data objects and their relationships] +- **Data Relationships**: [How entities connect and interact] +- **Data Validation**: [Validation rules and constraints] + +### Integration Architecture + +#### Internal Communication +- **Service Communication**: [How components communicate with each other] +- **Event Patterns**: [Event-driven architecture patterns if applicable] +- **Message Queues**: [Messaging systems and patterns] + +#### External Integrations +- **Third-Party APIs**: [External APIs and integration patterns] +- **Legacy Systems**: [Connections to existing systems] +- **Authentication**: [Identity and access management approach] + +## Azure Service Mapping + +*This section maps application components to specific Azure services.* + +### Service Architecture + +#### Hosting Services +| Component | Azure Service | Configuration | Rationale | +|-----------|---------------|---------------|-----------| +| [component-1] | [Azure service] | [Key config details] | [Why this service] | +| [component-2] | [Azure service] | [Key config details] | [Why this service] | + +#### Supporting Services + +**Data Services** +- **Primary Database**: [Azure SQL/Cosmos DB/PostgreSQL/etc. with rationale] +- **Caching**: [Azure Cache for Redis or alternative] +- **Storage**: [Azure Storage accounts and blob storage configuration] + +**Integration Services** +- **Messaging**: [Service Bus/Event Hubs/Event Grid configuration] +- **API Management**: [Azure API Management if applicable] +- **Authentication**: [Azure AD/Azure AD B2C configuration] + +**Infrastructure Services** +- **Monitoring**: [Application Insights and Azure Monitor setup] +- **Security**: [Key Vault, managed identities, and security configuration] +- **Networking**: [Virtual networks, private endpoints, and connectivity] + +### Resource Organization + +#### Resource Groups +- **Primary Resource Group**: [Name and organization strategy] +- **Environment Strategy**: [How dev/staging/production are organized] +- **Naming Conventions**: [Resource naming patterns and standards] + +#### Environment Configuration +- **Development Environment**: [Dev environment setup and configuration] +- **Staging Environment**: [Staging environment for testing and validation] +- **Production Environment**: [Production configuration and scaling] + +## Implementation Plan + +*This section outlines the development and deployment approach.* + +### Development Approach + +#### Project Structure +``` +src/ +├── [component-1]/ # [Component description] +├── [component-2]/ # [Component description] +├── shared/ # Shared libraries and utilities +└── docs/ # Additional documentation +``` + +#### Development Standards +- **Code Quality**: [Linting, formatting, and quality standards] +- **Testing Strategy**: [Unit, integration, and end-to-end testing approach] +- **Documentation**: [Code documentation and API documentation standards] +- **Version Control**: [Git workflow and branching strategy] + +### Deployment Strategy + +#### Infrastructure as Code +- **Bicep Templates**: [Infrastructure template organization and strategy] +- **Environment Management**: [Parameter management and environment configuration] +- **Deployment Pipeline**: [CI/CD pipeline approach and tooling] + +#### Application Deployment +- **Build Process**: [How applications are built and packaged] +- **Container Strategy**: [Docker configuration and container registry] +- **Configuration Management**: [How application configuration is managed] +- **Rollback Strategy**: [Deployment rollback and disaster recovery] + +## Security and Compliance + +*This section addresses security, privacy, and compliance requirements.* + +### Security Architecture +- **Authentication and Authorization**: [Identity management and access control] +- **Data Protection**: [Encryption, data privacy, and protection measures] +- **Network Security**: [Network isolation, firewalls, and security groups] +- **Secrets Management**: [How sensitive information is stored and accessed] + +### Compliance Requirements +- **Regulatory Compliance**: [Specific compliance requirements (GDPR, HIPAA, etc.)] +- **Organizational Policies**: [Company-specific security and compliance policies] +- **Audit and Monitoring**: [Logging, monitoring, and audit trail requirements] + +## Infrastructure as Code File Checklist + +*This section defines all Infrastructure as Code (IaC) files required for the application deployment.* + +### Required Bicep Templates + +- [ ] `./infra/main.bicep` - Main deployment template with subscription scope +- [ ] `./infra/main.parameters.json` - Environment-specific parameters using AZD variable expansion + +### Generic Resource Modules + +- [ ] `./infra/modules/containerapp.bicep` - Generic Container Apps module +- [ ] `./infra/modules/storage.bicep` - Generic Storage Account module +- [ ] `./infra/modules/database.bicep` - Generic database module +- [ ] `./infra/modules/keyvault.bicep` - Generic Key Vault module +- [ ] `./infra/modules/monitoring.bicep` - Generic monitoring module (Log Analytics, App Insights) + +### Service-Specific Modules + +*The following modules are generated based on the technology stack and architecture decisions:* + +- [ ] `./infra/modules/[service-name].bicep` - Service-specific modules that reference generic modules +- [ ] [Additional service-specific modules will be populated based on architecture decisions] + +### Configuration Files + +- [ ] `azure.yaml` - AZD project configuration +- [ ] `.env` files - Environment-specific configuration (if required) + +## Monitoring and Operations + +*This section defines the operational approach for the application.* + +### Monitoring Strategy +- **Application Performance**: [Application monitoring and performance tracking] +- **Infrastructure Monitoring**: [Infrastructure health and resource monitoring] +- **Business Metrics**: [Key performance indicators and business metrics] +- **Alerting**: [Alert configuration and incident response procedures] + +### Operational Procedures +- **Deployment Process**: [Standard deployment procedures and checklists] +- **Incident Response**: [Incident handling and escalation procedures] +- **Maintenance**: [Regular maintenance tasks and schedules] +- **Scaling**: [How to scale the application up or down based on demand] + +## Project Status and Next Steps + +*This section tracks progress and defines next actions.* + +### Current Status +- **Requirements Discovery**: [Complete/In Progress/Not Started] +- **Architecture Planning**: [Complete/In Progress/Not Started] +- **Technology Stack Selection**: [Complete/In Progress/Not Started] +- **Infrastructure Design**: [Complete/In Progress/Not Started] +- **Application Code Generation**: [Complete/In Progress/Not Started] +- **Deployment Configuration**: [Complete/In Progress/Not Started] + +### Implementation Roadmap + +#### Phase 1: Foundation Setup +- [ ] Generate application scaffolding and project structure +- [ ] Create infrastructure templates and deployment configuration +- [ ] Set up development environment and tooling +- [ ] Implement basic authentication and security + +#### Phase 2: Core Development +- [ ] Develop core application functionality +- [ ] Implement data access and storage +- [ ] Create API endpoints and user interfaces +- [ ] Set up monitoring and logging + +#### Phase 3: Integration and Testing +- [ ] Integrate all application components +- [ ] Implement end-to-end testing +- [ ] Performance testing and optimization +- [ ] Security testing and validation + +#### Phase 4: Deployment and Operations +- [ ] Deploy to staging environment +- [ ] User acceptance testing +- [ ] Production deployment +- [ ] Operational monitoring and support + +### Success Criteria +- [ ] All functional requirements implemented and tested +- [ ] Performance requirements met or exceeded +- [ ] Security and compliance requirements satisfied +- [ ] Application successfully deployed to Azure +- [ ] Monitoring and operational procedures in place +- [ ] Team trained on deployment and maintenance procedures + +--- + +*This specification document is maintained automatically and updated throughout the project lifecycle. It serves as the single source of truth for all architectural and implementation decisions.* diff --git a/cli/azd/internal/mcp/tools/resources/baseline_resources.md b/cli/azd/internal/mcp/tools/resources/baseline_resources.md index e69de29bb2d..c26f1f85a4e 100644 --- a/cli/azd/internal/mcp/tools/resources/baseline_resources.md +++ b/cli/azd/internal/mcp/tools/resources/baseline_resources.md @@ -0,0 +1,5 @@ +- **Log Analytics Workspace** (`Microsoft.OperationalInsights/workspaces`) - Central logging and monitoring for all application components +- **Application Insights** (`Microsoft.Insights/components`) - Application performance monitoring, telemetry, and analytics +- **Key Vault** (`Microsoft.KeyVault/vaults`) - Secure storage for secrets, keys, certificates, and connection strings +- **App Configuration** (`Microsoft.AppConfiguration/configurationStores`) - Centralized configuration management and feature flags +- **Storage Account** (`Microsoft.Storage/storageAccounts`) - File storage, queues, tables, and data persistence diff --git a/cli/azd/internal/mcp/tools/resources/containers_stack_resources.md b/cli/azd/internal/mcp/tools/resources/containers_stack_resources.md index e69de29bb2d..dac4fc0922a 100644 --- a/cli/azd/internal/mcp/tools/resources/containers_stack_resources.md +++ b/cli/azd/internal/mcp/tools/resources/containers_stack_resources.md @@ -0,0 +1,3 @@ +- **Container Apps Environment** (`Microsoft.App/managedEnvironments`) - Managed container hosting environment with built-in scaling, load balancing, and service discovery +- **Container Registry** (`Microsoft.ContainerRegistry/registries`) - Private container image repository for storing and managing Docker images +- **Container App** (`Microsoft.App/containerApps`) - Individual containerized application instances (one per application component) with automatic scaling and traffic management diff --git a/cli/azd/internal/mcp/tools/resources/logic_apps_stack_resources.md b/cli/azd/internal/mcp/tools/resources/logic_apps_stack_resources.md index e69de29bb2d..2722d24608e 100644 --- a/cli/azd/internal/mcp/tools/resources/logic_apps_stack_resources.md +++ b/cli/azd/internal/mcp/tools/resources/logic_apps_stack_resources.md @@ -0,0 +1,2 @@ +- **Logic Apps** (`Microsoft.Logic/workflows`) - Visual workflow orchestration and business process automation with extensive connector ecosystem +- **Integration Account** (`Microsoft.Logic/integrationAccounts`) - Optional resource for B2B scenarios, enterprise integration patterns, and advanced workflow features diff --git a/cli/azd/internal/mcp/tools/resources/serverless_stack_resources.md b/cli/azd/internal/mcp/tools/resources/serverless_stack_resources.md index e69de29bb2d..23e9bba429c 100644 --- a/cli/azd/internal/mcp/tools/resources/serverless_stack_resources.md +++ b/cli/azd/internal/mcp/tools/resources/serverless_stack_resources.md @@ -0,0 +1,2 @@ +- **Azure Functions** (`Microsoft.Web/sites` with kind: `functionapp`) - Event-driven serverless compute platform with automatic scaling and pay-per-execution pricing +- **App Service Plan** (`Microsoft.Web/serverfarms`) - Hosting plan for Azure Functions (Consumption, Premium, or Dedicated plans based on requirements) From a54e83674637141dab530bec75b3cbfa5c8611ce Mon Sep 17 00:00:00 2001 From: Wallace Breza Date: Wed, 10 Sep 2025 13:53:46 -0700 Subject: [PATCH 4/5] Fixes linter issues --- cli/azd/.vscode/cspell.yaml | 4 ++++ .../mcp/tools/azd_generate_project_spec_template.go | 9 ++++++--- cli/azd/internal/mcp/tools/azd_list_stack_resources.go | 7 +++++-- 3 files changed, 15 insertions(+), 5 deletions(-) diff --git a/cli/azd/.vscode/cspell.yaml b/cli/azd/.vscode/cspell.yaml index 327795bc69d..19e3c4fc461 100644 --- a/cli/azd/.vscode/cspell.yaml +++ b/cli/azd/.vscode/cspell.yaml @@ -1,11 +1,15 @@ import: ../../../.vscode/cspell.global.yaml words: + - appcode - azcloud - azdext - azurefd - backoff + - bestpractices + - bicepschema - Canonicalize - chinacloudapi + - cloudarchitect - Codespace - Codespaces - devcontainers diff --git a/cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go b/cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go index 91cc5406053..93a3202156e 100644 --- a/cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go +++ b/cli/azd/internal/mcp/tools/azd_generate_project_spec_template.go @@ -45,7 +45,9 @@ func handleGenerateProjectSpecTemplate(ctx context.Context, request mcp.CallTool // Check if file already exists if _, err := os.Stat(outputPath); err == nil { - return mcp.NewToolResultText(fmt.Sprintf("Template file '%s' already exists in the workspace. No action taken.", outputPath)), nil + return mcp.NewToolResultText( + fmt.Sprintf("Template file '%s' already exists in the workspace. No action taken.", outputPath), + ), nil } // Generate current timestamp @@ -58,7 +60,7 @@ func handleGenerateProjectSpecTemplate(ctx context.Context, request mcp.CallTool templateContent = strings.ReplaceAll(templateContent, "{{.LastUpdated}}", generatedDate) // Write the template file to the workspace - if err := os.WriteFile(outputPath, []byte(templateContent), 0644); err != nil { + if err := os.WriteFile(outputPath, []byte(templateContent), 0600); err != nil { return mcp.NewToolResultText(fmt.Sprintf("Error writing template file: %v", err)), nil } @@ -93,7 +95,8 @@ The template is ready! Other tools will now populate the template sections as th 3. Architecture planning will populate the "Application Architecture" and "Azure Service Mapping" sections 4. Implementation planning will complete the remaining sections -The template serves as the living documentation for your AZD project throughout the planning and implementation process.`, outputPath, generatedDate) +The template serves as the living documentation for your AZD project throughout the planning and " + + "implementation process.`, outputPath, generatedDate) return mcp.NewToolResultText(response), nil } diff --git a/cli/azd/internal/mcp/tools/azd_list_stack_resources.go b/cli/azd/internal/mcp/tools/azd_list_stack_resources.go index 0ba27bcb1d9..d97b197b0de 100644 --- a/cli/azd/internal/mcp/tools/azd_list_stack_resources.go +++ b/cli/azd/internal/mcp/tools/azd_list_stack_resources.go @@ -44,7 +44,8 @@ Use this tool when: - A technology stack has been selected for a project (containers, serverless, or logic apps) - Need resource listing for the selected technology stack -The tool takes a stack parameter (containers, serverless, logic_apps) and returns the comprehensive resource list with Azure resource type identifiers.`, +The tool takes a stack parameter (containers, serverless, logic_apps) and returns the comprehensive " + + "resource list with Azure resource type identifiers.`, ), mcp.WithString("stack", mcp.Description("The technology stack to list resources for"), @@ -70,7 +71,9 @@ func handleAzdListStackResources(ctx context.Context, request mcp.CallToolReques } if !validStacks[stack] { - return mcp.NewToolResultError(fmt.Sprintf("Invalid stack '%s'. Must be one of: containers, serverless, logic_apps", stack)), nil + return mcp.NewToolResultError( + fmt.Sprintf("Invalid stack '%s'. Must be one of: containers, serverless, logic_apps", stack), + ), nil } // Build response with baseline resources and stack-specific resources From fc8973e6aeefe333aa61c8dbb3aebac5786457f1 Mon Sep 17 00:00:00 2001 From: Wallace Breza Date: Thu, 11 Sep 2025 11:34:04 -0700 Subject: [PATCH 5/5] Updates tools --- cli/azd/cmd/mcp.go | 1 + .../mcp/tools/azd_appcode_generation.go | 13 +- .../mcp/tools/azd_architecture_planning.go | 13 +- .../mcp/tools/azd_artifact_generation.go | 13 +- .../mcp/tools/azd_azure_yaml_generation.go | 5 +- .../mcp/tools/azd_discovery_analysis.go | 5 +- .../mcp/tools/azd_docker_generation.go | 13 +- .../mcp/tools/azd_generate_infra_module.go | 154 ++++++++ .../mcp/tools/azd_iac_generation_rules.go | 7 +- .../mcp/tools/azd_identify_user_intent.go | 13 +- .../tools/azd_infrastructure_generation.go | 12 +- .../mcp/tools/azd_list_stack_resources.go | 13 +- .../mcp/tools/azd_modernize_project.go | 13 +- cli/azd/internal/mcp/tools/azd_new_project.go | 13 +- cli/azd/internal/mcp/tools/azd_plan_init.go | 17 +- .../mcp/tools/azd_project_validation.go | 11 +- .../internal/mcp/tools/azd_select_stack.go | 13 +- .../tools/prompts/azd_appcode_generation.md | 374 ++---------------- .../prompts/azd_architecture_planning.md | 190 ++------- .../tools/prompts/azd_artifact_generation.md | 298 ++------------ .../prompts/azd_azure_yaml_generation.md | 118 ++---- .../tools/prompts/azd_discovery_analysis.md | 84 ++-- .../tools/prompts/azd_docker_generation.md | 147 +++---- ...t_spec.md => azd_generate_infra_module.md} | 0 .../tools/prompts/azd_iac_generation_rules.md | 197 +++------ .../tools/prompts/azd_identify_user_intent.md | 187 ++------- .../prompts/azd_infrastructure_generation.md | 221 ++--------- .../tools/prompts/azd_list_stack_resources.md | 61 ++- .../tools/prompts/azd_modernize_project.md | 247 ++---------- .../mcp/tools/prompts/azd_new_project.md | 242 ++---------- .../mcp/tools/prompts/azd_plan_init.md | 202 ++-------- .../tools/prompts/azd_project_validation.md | 106 ++--- .../mcp/tools/prompts/azd_select_stack.md | 221 +++-------- go.mod | 8 +- go.sum | 24 +- 35 files changed, 832 insertions(+), 2424 deletions(-) create mode 100644 cli/azd/internal/mcp/tools/azd_generate_infra_module.go rename cli/azd/internal/mcp/tools/prompts/{azd_generate_project_spec.md => azd_generate_infra_module.md} (100%) diff --git a/cli/azd/cmd/mcp.go b/cli/azd/cmd/mcp.go index 2e9308036dc..25619b0eb6d 100644 --- a/cli/azd/cmd/mcp.go +++ b/cli/azd/cmd/mcp.go @@ -167,6 +167,7 @@ func (a *mcpStartAction) Run(ctx context.Context) (*actions.ActionResult, error) tools.NewAzdAzureYamlGenerationTool(), tools.NewAzdDockerGenerationTool(), tools.NewAzdInfrastructureGenerationTool(), + tools.NewAzdGenerateInfraModuleTool(), tools.NewAzdIacGenerationRulesTool(), tools.NewAzdProjectValidationTool(), tools.NewAzdYamlSchemaTool(), diff --git a/cli/azd/internal/mcp/tools/azd_appcode_generation.go b/cli/azd/internal/mcp/tools/azd_appcode_generation.go index 799ca43bfa9..8630230b1a2 100644 --- a/cli/azd/internal/mcp/tools/azd_appcode_generation.go +++ b/cli/azd/internal/mcp/tools/azd_appcode_generation.go @@ -21,16 +21,15 @@ func NewAzdAppCodeGenerationTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for generating application code scaffolding for all project components -using preferred programming languages and frameworks in src/ structure. + `Provides instructions for generating production-ready application scaffolding and starter code for all application components with Azure SDK integrations and deployment-ready configurations. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available code generation tools. Use this tool when: -- Project components have been defined and technology stack selected -- Programming language and framework preferences are known -- Need to generate application scaffolding for APIs, SPAs, workers, functions, etc. -- Ready to create production-ready code templates with Azure integrations`, +- Application components and technology stack have been defined in the application spec +- Ready to create code structure in src/ directories +- Need to generate framework-specific project files with Azure integrations +- Application architecture planning is complete and ready for implementation`, ), ), Handler: handleAzdAppCodeGeneration, diff --git a/cli/azd/internal/mcp/tools/azd_architecture_planning.go b/cli/azd/internal/mcp/tools/azd_architecture_planning.go index 0f48a2dfe57..025448b2a7f 100644 --- a/cli/azd/internal/mcp/tools/azd_architecture_planning.go +++ b/cli/azd/internal/mcp/tools/azd_architecture_planning.go @@ -21,16 +21,15 @@ func NewAzdArchitecturePlanningTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for selecting appropriate Azure services for discovered application components and -designing infrastructure architecture. + `Provides instructions for consolidating all previously gathered context (requirements, stack selection, discovered components) into a complete application architecture design with Azure service mappings and implementation strategy. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available planning and documentation tools. Use this tool when: -- Discovery analysis has been completed and azd-arch-plan.md exists -- Application components have been identified and classified -- Need to map components to Azure hosting services -- Ready to plan containerization and database strategies`, +- Discovery analysis has been completed and application components are identified +- Technology stack selection is complete +- Ready to map components to Azure hosting services and design infrastructure +- Need to create comprehensive architecture documentation in the application spec`, ), ), Handler: handleAzdArchitecturePlanning, diff --git a/cli/azd/internal/mcp/tools/azd_artifact_generation.go b/cli/azd/internal/mcp/tools/azd_artifact_generation.go index 7b6070be40d..e30eac75d5b 100644 --- a/cli/azd/internal/mcp/tools/azd_artifact_generation.go +++ b/cli/azd/internal/mcp/tools/azd_artifact_generation.go @@ -21,16 +21,15 @@ func NewAzdArtifactGenerationTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for orchestrating complete AZD project artifact generation including -application scaffolding, Docker configurations, infrastructure templates, and azure.yaml configuration. + `Provides instructions for orchestrating the complete artifact generation process for AZD projects, generating infrastructure templates, application scaffolding, Docker configurations, and azure.yaml in the correct order with proper dependencies. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available generation tools. Use this tool when: -- Project architecture and requirements have been defined in Application specification -- Ready to generate all project artifacts and implementation files -- Need to create application code, infrastructure templates, and deployment configurations -- Moving from planning phase to implementation phase`, +- Application architecture design is complete with all service mappings +- Ready to generate all project artifacts (infrastructure, code, Docker, azure.yaml) +- Need to coordinate multiple generation processes in proper dependency order +- Project specification contains complete requirements for artifact generation`, ), ), Handler: handleAzdArtifactGeneration, diff --git a/cli/azd/internal/mcp/tools/azd_azure_yaml_generation.go b/cli/azd/internal/mcp/tools/azd_azure_yaml_generation.go index 1fb8f334bc4..a4fb897f019 100644 --- a/cli/azd/internal/mcp/tools/azd_azure_yaml_generation.go +++ b/cli/azd/internal/mcp/tools/azd_azure_yaml_generation.go @@ -21,10 +21,9 @@ func NewAzdAzureYamlGenerationTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for generating the azure.yaml configuration file with proper service hosting, -build, and deployment settings for AZD projects. + `Provides instructions for creating a complete and valid azure.yaml file in the root directory that maps all application services to their Azure hosting services with proper build and deployment configurations. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available file creation and validation tools. Use this tool when: - Architecture planning has been completed and Azure services selected diff --git a/cli/azd/internal/mcp/tools/azd_discovery_analysis.go b/cli/azd/internal/mcp/tools/azd_discovery_analysis.go index 5f963718991..588cccafff3 100644 --- a/cli/azd/internal/mcp/tools/azd_discovery_analysis.go +++ b/cli/azd/internal/mcp/tools/azd_discovery_analysis.go @@ -21,10 +21,9 @@ func NewAzdDiscoveryAnalysisTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for performing comprehensive discovery and analysis of application components -to prepare for Azure Developer CLI (AZD) initialization. + `Provides instructions for scanning and analyzing the current workspace to identify all application components, technologies, dependencies, and communication patterns, documenting findings in the application specification. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available analysis and documentation tools. Use this tool when: - Starting Phase 1 of AZD migration process diff --git a/cli/azd/internal/mcp/tools/azd_docker_generation.go b/cli/azd/internal/mcp/tools/azd_docker_generation.go index a63825d69c3..689faf1de7a 100644 --- a/cli/azd/internal/mcp/tools/azd_docker_generation.go +++ b/cli/azd/internal/mcp/tools/azd_docker_generation.go @@ -21,16 +21,15 @@ func NewAzdDockerGenerationTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for generating optimized Dockerfiles and container configurations for containerizable -services in AZD projects. + `Provides instructions for generating optimized Dockerfiles and .dockerignore files for all containerizable services based on the Docker File Generation Checklist from the application spec. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available file creation tools. Use this tool when: -- Architecture planning identified services requiring containerization -- azd-arch-plan.md shows Container Apps or AKS as selected hosting platform -- Need Dockerfiles for microservices, APIs, or containerized web applications -- Ready to implement containerization strategy`, +- Application components requiring containerization have been identified +- Docker File Generation Checklist exists in the application spec +- Ready to create production-ready Dockerfiles with multi-stage builds and security best practices +- Need to generate .dockerignore files for build optimization`, ), ), Handler: handleAzdDockerGeneration, diff --git a/cli/azd/internal/mcp/tools/azd_generate_infra_module.go b/cli/azd/internal/mcp/tools/azd_generate_infra_module.go new file mode 100644 index 00000000000..eb3cc207e4d --- /dev/null +++ b/cli/azd/internal/mcp/tools/azd_generate_infra_module.go @@ -0,0 +1,154 @@ +// Copyright (c) Microsoft Corporation. All rights reserved. +// Licensed under the MIT License. + +package tools + +import ( + "context" + "encoding/json" + "fmt" + "strings" + + "github.com/mark3labs/mcp-go/mcp" + "github.com/mark3labs/mcp-go/server" +) + +// NewAzdGenerateInfraModuleTool creates a new tool for generating Bicep infrastructure modules +func NewAzdGenerateInfraModuleTool() server.ServerTool { + return server.ServerTool{ + Tool: mcp.NewTool( + "azd_generate_infra_module", + mcp.WithReadOnlyHintAnnotation(false), + mcp.WithIdempotentHintAnnotation(false), + mcp.WithDestructiveHintAnnotation(false), + mcp.WithOpenWorldHintAnnotation(false), + mcp.WithDescription( + `Generates a new Bicep infrastructure module for a specified Azure resource type. +This tool takes resource type, API version, and optional requirements as input and returns +a complete Bicep module using MCP sampling.`, + ), + mcp.WithString("resourceType", + mcp.Description("The Azure resource type for the module (e.g., Microsoft.Storage/storageAccounts, Microsoft.Web/sites)"), + mcp.Required(), + ), + mcp.WithString("apiVersion", + mcp.Description("The API version to use for the resource. Defaults to 'latest' if not specified"), + ), + mcp.WithString("requirements", + mcp.Description("Optional specific requirements or configurations for the module"), + ), + ), + Handler: handleAzdGenerateInfraModule, + } +} + +func handleAzdGenerateInfraModule(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) { + // Validate required parameters + resourceType, err := request.RequireString("resourceType") + if err != nil { + return createErrorResult("resourceType", "Resource type is required"), nil + } + + if strings.TrimSpace(resourceType) == "" { + return createErrorResult("resourceType", "Resource type cannot be empty"), nil + } + + // Get optional parameters + apiVersion := request.GetString("apiVersion", "latest") + requirements := request.GetString("requirements", "") + + // Construct the prompt for Bicep module generation + prompt := buildBicepModulePrompt(resourceType, apiVersion, requirements) + + // Make MCP sampling request + serverFromCtx := server.ServerFromContext(ctx) + samplingRequest := mcp.CreateMessageRequest{ + CreateMessageParams: mcp.CreateMessageParams{ + Messages: []mcp.SamplingMessage{ + { + Role: mcp.RoleUser, + Content: mcp.TextContent{ + Type: "text", + Text: prompt, + }, + }, + }, + SystemPrompt: `You are an expert Bicep Code Generator that can generate production-ready Bicep modules that follow Azure Well-Architected Framework principles.`, + Temperature: 0.3, // Lower temperature for more consistent code generation + }, + } + + samplingResult, err := serverFromCtx.RequestSampling(ctx, samplingRequest) + if err != nil { + return mcp.NewToolResultErrorFromErr("Error during Bicep module generation", err), nil + } + + // Extract the generated Bicep code + if textContent, ok := samplingResult.Content.(mcp.TextContent); ok { + bicepCode := textContent.Text + + // Format the response - construct without backticks in the format string + response := "# Generated Bicep Module\n\n" + response += "## Resource Information\n" + response += fmt.Sprintf("- **Resource Type**: %s\n", resourceType) + response += fmt.Sprintf("- **API Version**: %s\n", apiVersion) + response += fmt.Sprintf("- **Requirements**: %s\n\n", getRequirementsDisplay(requirements)) + response += "## Generated Bicep Code\n\n" + response += "```bicep\n" + response += bicepCode + response += "\n```" + + return mcp.NewToolResultText(response), nil + } + + return mcp.NewToolResultError("Failed to extract Bicep code from sampling response"), nil +} + +func buildBicepModulePrompt(resourceType, apiVersion, requirements string) string { + prompt := fmt.Sprintf(`Generate a complete Bicep module for the Azure resource type: %s + +Requirements: +- Use API version: %s +- Include proper parameter definitions with descriptions and validation +- Add meaningful variable declarations where appropriate +- Include comprehensive outputs for important resource properties +- Follow Azure naming conventions and best practices +- Add resource tags for governance +- Include proper documentation comments`, resourceType, apiVersion) + + if requirements != "" { + prompt += fmt.Sprintf(` +- Additional specific requirements: %s`, requirements) + } + + prompt += ` + +The module should be production-ready and include: +1. Parameter section with proper types, descriptions, and validation +2. Variable section for computed values +3. Resource definition with all necessary properties +4. Output section exposing key resource properties +5. Inline comments explaining key configurations + +Please provide only the Bicep code without additional explanations or markdown formatting.` + + return prompt +} + +func getRequirementsDisplay(requirements string) string { + if requirements == "" { + return "None specified" + } + return requirements +} + +func createErrorResult(parameterName, message string) *mcp.CallToolResult { + fullMessage := fmt.Sprintf("Parameter '%s': %s", parameterName, message) + errorData := ErrorResponse{ + Error: true, + Message: fullMessage, + } + + errorJSON, _ := json.Marshal(errorData) + return mcp.NewToolResultText(string(errorJSON)) +} diff --git a/cli/azd/internal/mcp/tools/azd_iac_generation_rules.go b/cli/azd/internal/mcp/tools/azd_iac_generation_rules.go index 028e5555839..8e03cf43206 100644 --- a/cli/azd/internal/mcp/tools/azd_iac_generation_rules.go +++ b/cli/azd/internal/mcp/tools/azd_iac_generation_rules.go @@ -21,16 +21,15 @@ func NewAzdIacGenerationRulesTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns comprehensive rules and guidelines for generating Bicep Infrastructure as Code files and modules -for AZD projects. + `Provides authoritative rules and standards for generating Bicep infrastructure templates that follow Azure Well-Architected Framework principles and AZD conventions. -The LLM agent should reference these rules when generating infrastructure code. +This tool returns detailed rules and guidelines that the LLM agent should follow when generating infrastructure code. Use this tool when: - Generating any Bicep infrastructure templates for AZD projects - Need compliance rules and naming conventions for Azure resources - Creating modular, reusable Bicep files -- Ensuring security and operational best practices"`, +- Ensuring security and operational best practices`, ), ), Handler: handleAzdIacGenerationRules, diff --git a/cli/azd/internal/mcp/tools/azd_identify_user_intent.go b/cli/azd/internal/mcp/tools/azd_identify_user_intent.go index fd8107ba854..818e7154423 100644 --- a/cli/azd/internal/mcp/tools/azd_identify_user_intent.go +++ b/cli/azd/internal/mcp/tools/azd_identify_user_intent.go @@ -21,16 +21,15 @@ func NewAzdIdentifyUserIntentTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for discovering user project intent, requirements, and technology preferences -through conversational questioning. + `Provides instructions for engaging users with conversational questions to understand project purpose, scale requirements, budget constraints, and architectural preferences, then classify and document findings. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available user interaction and documentation tools. Use this tool when: -- Starting requirements discovery for new or existing projects -- Need to understand project scale, budget constraints, and architectural preferences -- Want to capture programming language and framework preferences -- Beginning project planning phase to inform technology stack decisions`, +- Starting a new project and need to understand user requirements +- Beginning the discovery phase for project planning +- Need to classify project type, scale, and budget constraints +- Ready to gather architectural and technology preferences from the user`, ), ), Handler: handleAzdIdentifyUserIntent, diff --git a/cli/azd/internal/mcp/tools/azd_infrastructure_generation.go b/cli/azd/internal/mcp/tools/azd_infrastructure_generation.go index c29eff36f5c..584f0042e8f 100644 --- a/cli/azd/internal/mcp/tools/azd_infrastructure_generation.go +++ b/cli/azd/internal/mcp/tools/azd_infrastructure_generation.go @@ -21,15 +21,15 @@ func NewAzdInfrastructureGenerationTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for generating modular Bicep infrastructure templates following Azure security and -operational best practices for AZD projects. + `Provides instructions for generating complete Bicep infrastructure templates in ./infra directory based on the Infrastructure as Code File Checklist, using latest schema versions and following IaC generation rules. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available infrastructure generation tools. Use this tool when: -- Architecture planning completed with Azure services selected -- Need to create Bicep infrastructure templates -- Ready to implement infrastructure as code for deployment`, +- Application architecture planning is complete with Azure service mappings +- Ready to generate Bicep templates for all required Azure resources +- Infrastructure as Code File Checklist exists in the application spec +- Need to create modular, reusable infrastructure templates following best practices`, ), ), Handler: handleAzdInfrastructureGeneration, diff --git a/cli/azd/internal/mcp/tools/azd_list_stack_resources.go b/cli/azd/internal/mcp/tools/azd_list_stack_resources.go index d97b197b0de..e48f11fbe88 100644 --- a/cli/azd/internal/mcp/tools/azd_list_stack_resources.go +++ b/cli/azd/internal/mcp/tools/azd_list_stack_resources.go @@ -36,16 +36,15 @@ func NewAzdListStackResourcesTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `List Azure resources required for a specific technology stack. + `Provides the definitive list of Azure resources required for each technology stack (baseline and stack-specific) to guide architecture planning and infrastructure generation. -Returns baseline resources (required for all stacks) plus stack-specific resources for the chosen technology approach. +This tool returns detailed resource definitions that the LLM agent should use for architecture planning and infrastructure generation. Use this tool when: -- A technology stack has been selected for a project (containers, serverless, or logic apps) -- Need resource listing for the selected technology stack - -The tool takes a stack parameter (containers, serverless, logic_apps) and returns the comprehensive " + - "resource list with Azure resource type identifiers.`, +- Need to understand what Azure resources are available for each technology stack +- Planning infrastructure architecture and need resource type identifiers +- Ready to map application components to appropriate Azure services +- Generating infrastructure templates and need resource specifications`, ), mcp.WithString("stack", mcp.Description("The technology stack to list resources for"), diff --git a/cli/azd/internal/mcp/tools/azd_modernize_project.go b/cli/azd/internal/mcp/tools/azd_modernize_project.go index 931d496f566..50bb68f781b 100644 --- a/cli/azd/internal/mcp/tools/azd_modernize_project.go +++ b/cli/azd/internal/mcp/tools/azd_modernize_project.go @@ -21,16 +21,15 @@ func NewAzdModernizeProjectTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for modernizing existing applications to be AZD-compatible while preserving -existing functionality and structure. + `Provides instructions for modernizing existing applications to be AZD-compatible by conducting analysis, requirements discovery, stack selection, architecture planning, and artifact generation while preserving existing functionality. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available analysis, planning, and generation tools. Use this tool when: -- Existing application code is detected in the workspace -- Need to add Azure deployment capabilities to existing projects -- Want to migrate existing applications to Azure with minimal disruption -- Application components and architecture need analysis and Azure service mapping`, +- Working with an existing application that needs Azure deployment capabilities +- Ready to modernize a project to be AZD-compatible while preserving functionality +- Need to conduct comprehensive analysis and generate Azure deployment artifacts +- Application workspace contains existing code that should be preserved`, ), ), Handler: handleAzdModernizeProject, diff --git a/cli/azd/internal/mcp/tools/azd_new_project.go b/cli/azd/internal/mcp/tools/azd_new_project.go index 64f0b1c99e1..05084b7dc88 100644 --- a/cli/azd/internal/mcp/tools/azd_new_project.go +++ b/cli/azd/internal/mcp/tools/azd_new_project.go @@ -21,16 +21,15 @@ func NewAzdNewProjectTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for orchestrating complete new AZD project creation from scratch, -including requirements discovery, stack selection, architecture planning, and implementation roadmap. + `Provides instructions for orchestrating complete new project creation from scratch through requirements discovery, stack selection, architecture planning, and file generation guidance to create a ready-to-implement project specification. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available discovery, planning, and generation tools. Use this tool when: -- Creating a completely new AZD project with no existing code -- User has a clear idea of what they want to build -- Workspace is empty or contains only minimal documentation -- Need comprehensive project specification and architecture design`, +- Creating a brand new AZD project from an empty or minimal workspace +- Ready to guide user through complete project setup from requirements to implementation +- Need systematic workflow for new project creation with all planning phases +- Starting fresh without existing application code or infrastructure`, ), ), Handler: handleAzdNewProject, diff --git a/cli/azd/internal/mcp/tools/azd_plan_init.go b/cli/azd/internal/mcp/tools/azd_plan_init.go index c3a522a4179..bdc95b143da 100644 --- a/cli/azd/internal/mcp/tools/azd_plan_init.go +++ b/cli/azd/internal/mcp/tools/azd_plan_init.go @@ -21,20 +21,15 @@ func NewAzdPlanInitTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Initial entry point for AZD project initialization and modernization workflows. + `Provides instructions for analyzing workspace contents to determine project state, classify as "new project" or "existing application", route users to appropriate workflow, and execute the selected workflow with proper tool orchestration. -This tool provides orchestration guidance for transforming workspaces into AZD-compatible projects. +This tool returns detailed instructions that the LLM agent should follow using available analysis and orchestration tools. Use this tool when: -- Creating new AZD project from an empty workspace -- Modernizing an existing application to become AZD compatible -- Need guidance for complete project setup and configuration - -Will help with the following: -- Analysis & Discovery -- Architecture Planning including stack selection -- File / Code generation -- Project validation`, +- Starting AZD project initialization and need to determine the right workflow +- Workspace contains mixed or unclear content requiring analysis +- Need to route between new project creation vs application modernization +- Beginning any AZD project setup and need proper workflow guidance`, ), ), Handler: handleAzdPlanInit, diff --git a/cli/azd/internal/mcp/tools/azd_project_validation.go b/cli/azd/internal/mcp/tools/azd_project_validation.go index e8b62641298..1a0820ec7ac 100644 --- a/cli/azd/internal/mcp/tools/azd_project_validation.go +++ b/cli/azd/internal/mcp/tools/azd_project_validation.go @@ -21,16 +21,15 @@ func NewAzdProjectValidationTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for validating AZD project by running comprehensive checks on azure.yaml schema, -Bicep templates, environment setup, packaging, and deployment preview. + `Provides instructions for executing comprehensive validation of AZD project components including azure.yaml schema, Bicep templates, environment configuration, packaging, and deployment preview to ensure deployment readiness. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available validation and testing tools. Use this tool when: -- All AZD configuration files have been generated -- Ready to validate complete project before deployment +- All AZD configuration files and artifacts have been generated +- Ready to validate complete project before deployment with azd up - Need to ensure azure.yaml, Bicep templates, and environment are properly configured -- Final validation step before running azd up`, +- Final validation step to confirm deployment readiness`, ), ), Handler: handleAzdProjectValidation, diff --git a/cli/azd/internal/mcp/tools/azd_select_stack.go b/cli/azd/internal/mcp/tools/azd_select_stack.go index ff74dd99dce..a0c25b586c2 100644 --- a/cli/azd/internal/mcp/tools/azd_select_stack.go +++ b/cli/azd/internal/mcp/tools/azd_select_stack.go @@ -21,16 +21,15 @@ func NewAzdSelectStackTool() server.ServerTool { mcp.WithDestructiveHintAnnotation(false), mcp.WithOpenWorldHintAnnotation(false), mcp.WithDescription( - `Returns instructions for selecting the optimal technology stack (Containers, Serverless, or Logic Apps) -based on team expertise, performance requirements, and application characteristics. + `Provides instructions for assessing team expertise, application characteristics, and project requirements through targeted questions to select the optimal single technology stack (Containers, Serverless, or Logic Apps) with clear rationale. -The LLM agent should execute these instructions using available tools. +This tool returns detailed instructions that the LLM agent should follow using available user interaction and documentation tools. Use this tool when: -- User intent discovery has been completed -- Need to determine the best technology approach for the project -- Team expertise and application requirements are understood -- Ready to make technology stack decisions for architecture planning`, +- User intent and project requirements have been discovered +- Ready to determine the optimal technology stack for the project +- Need to assess team capabilities and application characteristics +- Project requirements are understood and ready for technology decisions`, ), ), Handler: handleAzdSelectStack, diff --git a/cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md index 3b8879a93d1..751531676cf 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_appcode_generation.md @@ -1,356 +1,54 @@ # AZD Application Code Generation Instructions -✅ **Agent Task List** +**TASK:** Generate production-ready application scaffolding and starter code for all application components with Azure SDK integrations and deployment-ready configurations. -1. Review application specification for application components and technology stack decisions -2. Identify preferred programming language and framework choices from user requirements -3. Analyze component types and generate appropriate application scaffolding for each -4. Create structured project layout in `src/` directories -5. Generate framework-specific code with Azure SDK integrations -6. Include configuration management, logging, and health monitoring setup -7. Create build and deployment scripts for each component -8. Update application spec with generated code structure and next steps +**SUCCESS CRITERIA:** -📄 **Required Outputs** +- Complete application scaffolding created in `src/` directories for all identified components +- Framework-specific project files and dependency configurations generated +- Azure SDK integrations implemented for all required services +- Health checks, logging, and monitoring infrastructure included +- Configuration management and environment variable handling implemented +- Application spec updated with generated code structure -- Complete application scaffolding for all identified components in `src/` structure -- Framework-appropriate project files, dependencies, and build configurations -- Azure SDK integrations and service connection code -- Health checks, logging, and monitoring infrastructure -- Configuration management and environment variable handling -- Sample implementation code demonstrating component functionality -- Updated application spec documenting generated code structure +**VALIDATION REQUIRED:** -🧠 **Execution Guidelines** +- All generated code compiles without errors for the target language/framework +- Azure SDK connections can be established (connection strings validate) +- Health check endpoints respond correctly +- Configuration follows security best practices (no hardcoded secrets) +- Generated code follows language-specific style guidelines -**CRITICAL:** Generate production-ready application scaffolding that follows industry best practices for the selected programming language and framework. Include comprehensive Azure integrations and deployment-ready configurations. +**COMPLETION CHECKLIST:** -## Project Structure and Organization +- [ ] Read application specification for component requirements and stack decisions +- [ ] Generate scaffolding for each component in `src/` structure +- [ ] Implement Azure SDK integrations for all mapped services +- [ ] Add health checks, logging, and monitoring to each component +- [ ] Update application spec with generated code documentation + +## Critical Implementation Requirements **Standard Directory Structure:** ```text src/ -├── / # REST API services -├── / # Single Page Applications -├── / # Background services and message processors -├── / # Serverless function applications -├── / # Server-rendered web applications -├── / # Batch processing applications -└── shared/ # Shared libraries and utilities +├── / # One directory per application component +└── shared/ # Shared libraries and utilities (if needed) ``` -**Component Naming Conventions:** - -- Use kebab-case for directory names (e.g., `user-api`, `admin-portal`, `order-processor`) -- Match component names defined in architecture planning phase -- Ensure names are descriptive and reflect component purpose -- Avoid generic names like `service1`, `app`, or `backend` - -## Application Component Types and Scaffolding - -### API-Based Projects (REST APIs, GraphQL, gRPC) - -**Technology Stack Support:** - -**Node.js/TypeScript APIs:** - -- Express.js or Fastify framework setup -- TypeScript configuration with strict typing -- REST endpoint scaffolding with OpenAPI/Swagger documentation -- Middleware for authentication, logging, and error handling -- Database integration (Prisma, TypeORM, or native drivers) -- Azure SDK integrations (Storage, Key Vault, Service Bus) - -**Python APIs:** - -- FastAPI or Flask framework setup with async support -- Pydantic models for request/response validation -- SQLAlchemy or Django ORM for database operations -- Azure SDK for Python integrations -- Comprehensive error handling and logging -- Health check endpoints and metrics collection - -**C# APIs:** - -- ASP.NET Core Web API project setup -- Entity Framework Core for data access -- Dependency injection and configuration management -- Azure SDK for .NET integrations -- Comprehensive logging with Application Insights -- Authentication and authorization with Azure AD - -**Java APIs:** - -- Spring Boot application setup with appropriate starters -- Spring Data JPA for database operations -- Spring Security for authentication and authorization -- Azure SDK for Java integrations -- Comprehensive testing setup with JUnit and TestContainers - -**Generated Components:** - -- Controller/route definitions with CRUD operations -- Data models and entity definitions -- Service layer with business logic separation -- Repository pattern for data access -- Configuration classes for Azure service connections -- Health check endpoints (`/health`, `/ready`) -- API documentation setup and sample endpoints - -### SPA-Based Projects (React, Angular, Vue.js) - -**React/TypeScript SPAs:** -- Create React App or Vite setup with TypeScript -- React Router for navigation and routing -- State management (Redux Toolkit, Zustand, or Context API) -- API client setup with Axios or React Query -- Azure authentication integration (MSAL.js) -- Component library setup (Material-UI, Chakra UI, or custom) -- Build optimization and environment configuration - -**Angular SPAs:** -- Angular CLI project setup with TypeScript -- Angular Material or PrimeNG component library -- Reactive forms and validation -- HTTP client with interceptors for authentication -- Azure AD authentication with MSAL Angular -- State management with NgRx (for complex apps) -- PWA capabilities and service worker setup - -**Vue.js SPAs:** -- Vue 3 with Composition API and TypeScript -- Vue Router for navigation -- Pinia for state management -- Azure authentication integration -- Component library integration (Vuetify, Quasar) -- Build tools setup (Vite or Vue CLI) - -**Generated Components:** -- Application shell with navigation and layout -- Authentication components and route guards -- Sample pages and component structure -- API service classes for backend communication -- Configuration management for environments -- Build and deployment scripts -- Testing setup (Jest, Cypress, or Playwright) - -### Message-Based Projects (Event-Driven Applications) - -**Event Processing Applications:** -- Message handler scaffolding for Service Bus, Event Hubs, or Event Grid -- Dead letter queue handling and retry mechanisms -- Message serialization/deserialization utilities -- Batch processing and scaling configurations -- Monitoring and telemetry collection - -**Worker Service Applications:** -- Background service templates for long-running processes -- Queue-based work distribution patterns -- Health monitoring and graceful shutdown handling -- Configuration for scaling and resource management -- Integration with Azure Monitor and Application Insights - -**Generated Components:** -- Message handler classes with typed message contracts -- Queue/topic configuration and connection management -- Error handling and retry policy implementations -- Metrics collection and performance monitoring -- Configuration for different message sources (Service Bus, Event Hubs, etc.) - -### Function-Based Projects (Serverless Applications) - -**Azure Functions:** -- Function app project setup with appropriate triggers -- HTTP triggers for API endpoints -- Timer triggers for scheduled operations -- Service Bus/Event Hub triggers for message processing -- Blob/Queue triggers for storage events -- Dependency injection and configuration setup - -**Generated Components:** -- Function definitions with appropriate triggers and bindings -- Shared utilities and helper functions -- Configuration for local development and testing -- Integration with Azure services through bindings -- Logging and monitoring setup - -### Web Application Projects (Server-Rendered) - -**Server-Rendered Applications:** -- Framework setup (Next.js, Nuxt.js, or traditional server frameworks) -- Authentication and session management -- Database integration and ORM setup -- Template engine configuration and layouts -- Static asset management and optimization - -**Generated Components:** -- Page templates and routing configuration -- Authentication middleware and user management -- Database models and migration scripts -- Asset pipeline and build configuration -- Environment-specific configuration management - -### Batch Processing Projects - -**Data Processing Applications:** -- Batch job frameworks (Spring Batch, Apache Airflow workflows) -- Data pipeline scaffolding for ETL operations -- Integration with Azure Data Factory or Azure Batch -- Error handling and job monitoring -- Scalable processing patterns - -**Generated Components:** -- Job definition classes and processing logic -- Data source connectors and transformation utilities -- Scheduling and workflow management -- Monitoring and alerting configuration +**Essential Scaffolding Elements:** -## Programming Language and Framework Selection - -**Language-Specific Best Practices:** - -**TypeScript/JavaScript:** -- Strict TypeScript configuration with comprehensive type checking -- ESLint and Prettier configuration for code quality -- Modern ES6+ features and async/await patterns -- Package.json with appropriate scripts and dependencies -- Environment configuration with dotenv or similar - -**Python:** -- Virtual environment setup and requirements management -- Type hints and mypy configuration for static typing -- Black and flake8 for code formatting and linting -- pytest setup for comprehensive testing -- Environment configuration with python-dotenv - -**C#:** -- Modern C# features and nullable reference types -- Project file configuration with appropriate package references -- Dependency injection and configuration patterns -- Comprehensive logging with structured logging -- Environment-specific appsettings.json files - -**Java:** -- Maven or Gradle build configuration -- Spring Boot best practices and auto-configuration -- Comprehensive testing with JUnit and Mockito -- Logging configuration with Logback or Log4j2 -- Environment configuration with profiles - -## Azure SDK Integration and Service Connections - -**Common Azure Service Integrations:** - -**Authentication and Identity:** -- Azure AD integration for user authentication -- Managed Identity configuration for service-to-service auth -- Key Vault integration for secrets management -- Role-based access control (RBAC) setup - -**Data and Storage:** -- Azure SQL Database or Cosmos DB connection setup -- Azure Storage (Blob, Queue, Table) integration -- Redis Cache configuration and usage patterns -- Database migration and seeding scripts - -**Messaging and Events:** -- Service Bus queue and topic integration -- Event Hubs producer and consumer setup -- Event Grid subscription and handler configuration -- Dead letter queue and error handling patterns - -**Monitoring and Observability:** -- Application Insights integration and telemetry -- Structured logging with correlation IDs -- Health check endpoints and monitoring -- Custom metrics and performance counters - -## Configuration Management and Environment Setup - -**Environment Configuration Patterns:** - -**Local Development:** -- Local environment setup with development containers -- Mock services and local testing configuration -- Debug configuration and hot reload setup -- Local database and messaging emulators - -**Azure Environment Integration:** -- Environment-specific configuration files -- Azure App Configuration or Key Vault integration -- Managed Identity configuration for Azure services -- Connection string management and rotation - -**Security and Compliance:** -- Secure coding practices and input validation -- Authentication and authorization implementation -- Data encryption and secure communication -- Compliance with security best practices - -## Code Generation Workflow - -**Component Analysis and Planning:** - -1. **Read Architecture Decisions**: Review application spec for component definitions and technology choices -2. **Identify Component Types**: Classify each component (API, SPA, Worker, Function, etc.) -3. **Determine Language/Framework**: Use user preferences from intent discovery or make appropriate recommendations -4. **Plan Integration Points**: Identify shared libraries, communication patterns, and service dependencies - -**Scaffolding Generation Process:** - -1. **Create Directory Structure**: Establish `src/` layout for each component -2. **Generate Framework Setup**: Create appropriate project files, configuration, and dependencies -3. **Add Azure Integrations**: Include SDK setup and service connection code -4. **Create Sample Implementation**: Generate basic functionality demonstrating component purpose -5. **Add Supporting Infrastructure**: Include testing, logging, monitoring, and deployment setup - -**Quality Assurance and Validation:** - -- Ensure generated code compiles and runs without errors -- Validate Azure SDK integrations and authentication setup -- Test basic functionality and health check endpoints -- Verify configuration management and environment handling -- Confirm alignment with architecture decisions and requirements - -## Documentation and Next Steps - -**Code Structure Documentation:** - -Update application spec with generated code details: - -```markdown -## Generated Application Code - -### Component Structure -- **API Services**: [List of generated API components with technologies] -- **Frontend Applications**: [List of generated SPA components with frameworks] -- **Background Services**: [List of generated worker/message components] -- **Function Applications**: [List of generated serverless components] - -### Technology Stack -- **Primary Language**: [Selected programming language] -- **Frameworks**: [List of frameworks used per component type] -- **Azure SDK Integrations**: [List of Azure services integrated] - -### Development Setup -- **Local Development**: Instructions for running components locally -- **Testing Strategy**: Overview of testing setup and practices -- **Build and Deployment**: Summary of build processes and deployment configuration - -### Next Steps -- [Specific guidance for development team to continue implementation] -- [Testing and validation recommendations] -- [Deployment and monitoring setup instructions] -``` +- **Entry Points**: Main application files with proper startup configuration +- **Health Checks**: `/health` endpoint for all services (Container Apps requirement) +- **Configuration**: Environment-based config (no hardcoded values) +- **Azure SDK Integration**: Connection code for all mapped Azure services +- **Error Handling**: Proper exception handling and logging +- **Build Scripts**: Language-appropriate build and dependency management -**Success Criteria:** +**Security Requirements:** -- [ ] All application components have appropriate scaffolding generated -- [ ] Code follows language and framework best practices -- [ ] Azure SDK integrations are properly configured -- [ ] Configuration management supports multiple environments -- [ ] Health checks and monitoring are implemented -- [ ] Build and deployment scripts are functional -- [ ] Documentation provides clear next steps for development -- [ ] Generated code aligns with architecture decisions and user requirements +- No secrets or connection strings in code +- Use environment variables for all configuration +- Implement proper authentication integration points +- Follow language-specific security best practices diff --git a/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md b/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md index de213356d3c..8789706288a 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_architecture_planning.md @@ -1,171 +1,49 @@ # AZD Architecture Planning Instructions -✅ **Agent Task List** +**TASK:** Consolidate all previously gathered context (requirements, stack selection, discovered components) into a complete application architecture design with Azure service mappings and implementation strategy. -1. Review application spec to gather all previously collected context (requirements, stack selection, discovered components) -2. Populate the "Application Architecture" section with component details and relationships -3. Complete the "Azure Service Mapping" section with specific service assignments and rationale -4. Update the "Implementation Plan" section with concrete next steps -5. Ensure all gathered context is properly documented in the appropriate existing sections +**SUCCESS CRITERIA:** -📄 **Required Outputs** +- Application architecture section populated with all component details and relationships +- Azure service mapping completed with specific service assignments and rationale +- Implementation plan updated with concrete infrastructure and deployment strategy +- All previously gathered context properly integrated into existing application spec structure -- Fully populated "Application Architecture" section with component details, data architecture, and integration patterns -- Complete "Azure Service Mapping" section showing all service assignments with rationale -- Updated "Implementation Plan" with infrastructure and deployment strategy -- All previously gathered context properly integrated into the existing application spec structure +**VALIDATION REQUIRED:** -🧠 **Execution Guidelines** +- All discovered components are properly mapped to Azure services +- Component dependencies and communication patterns are documented +- Azure service selections align with chosen technology stack and requirements +- Implementation plan provides clear next steps for infrastructure generation -**CRITICAL:** This tool focuses on consolidating all previously gathered context into the existing application spec sections. Do not create new sections - populate the template sections with the collected information. +**COMPLETION CHECKLIST:** -## Context Consolidation Process +- [ ] Read complete application spec to understand previously collected information +- [ ] Populate "Application Architecture" section with component details and relationships +- [ ] Complete "Azure Service Mapping" section with service assignments and rationale +- [ ] Update "Implementation Plan" section with infrastructure and deployment strategy +- [ ] Ensure all gathered context is documented in appropriate existing sections +- [ ] User has confirmed application specification -**Review All Gathered Context:** +## Critical Planning Requirements -- Read the complete application spec to understand all previously collected information -- Review project requirements, technology stack selection, and discovered components -- Identify any gaps in information that need to be addressed -- Note the selected technology stack and baseline Azure resources +**Component Architecture Documentation:** -**Populate Application Architecture Section:** +- Map each discovered component to its type (API/SPA/Worker/Function) +- Document component dependencies and communication patterns +- Define data architecture and access patterns +- Identify external integrations and requirements -Use the existing "Application Architecture" section structure to document: -**Component Overview Table:** -Fill in the existing component table with discovered application components: +**Azure Service Mapping:** -```markdown -| Component Name | Type | Technology | Purpose | Dependencies | -|---------------|------|------------|---------|--------------| -| [discovered-component-1] | [API/SPA/Worker/Function] | [Current technology] | [Component purpose] | [Other components or services] | -``` +- Assign appropriate Azure hosting services based on component types and stack selection +- Map data requirements to Azure data services (SQL, Cosmos DB, etc.) +- Select integration services for messaging and events +- Configure monitoring and security services -**Component Details:** -For each discovered component, populate the detailed sections with: +**Implementation Strategy:** -- Component type and technology choices -- Detailed purpose and responsibilities -- Data access patterns and requirements -- External integrations and dependencies -- Scaling and performance characteristics - -**Data Architecture:** -Document the data strategy based on discovered requirements: - -- Primary database technology and rationale -- Caching requirements and approach -- Data flow patterns between components -- Backup and recovery considerations - -**Integration Architecture:** -Define how components will communicate: - -- Internal service communication patterns -- Event-driven architecture if applicable -- External API integrations -- Authentication and security patterns - -## Azure Service Mapping - -**Populate Service Architecture Tables:** - -Fill the existing service mapping tables based on the selected technology stack: - -**Hosting Services Table:** -Map each application component to its Azure hosting service with specific configuration details: - -```markdown -| Component | Azure Service | Configuration | Rationale | -|-----------|---------------|---------------|-----------| -| [component-name] | [Container Apps/Functions/Logic Apps] | [Scaling, networking, runtime details] | [Why this service fits the requirements] | -``` - -Example populated entries: - -- **Web API Component**: Container Apps | Auto-scaling 1-10 instances, HTTP ingress | Containerized service needing variable scaling -- **Frontend SPA**: Static Web Apps | Global CDN, custom domain | Static React app with global distribution needs -- **Background Processor**: Azure Functions | Consumption plan, Event Hub trigger | Event-driven processing with cost optimization -- **Workflow Orchestrator**: Logic Apps | Standard tier, HTTP triggers | Business process automation with visual design needs - -**Supporting Services:** -Document the supporting Azure services based on the selected stack: - -- **Data Services**: Map data requirements to Azure SQL, Cosmos DB, PostgreSQL, etc. -- **Integration Services**: Select messaging services (Service Bus, Event Hubs, Event Grid) -- **Infrastructure Services**: Configure monitoring, security, and networking services - -Use the baseline resources for all stacks: - -- Log Analytics Workspace for centralized logging -- Application Insights for performance monitoring -- Key Vault for secrets management -- App Configuration for configuration management -- Storage Account for file storage and queues - -**Resource Organization:** -Define the resource organization strategy: - -- Resource group structure and naming -- Environment separation strategy -- Naming conventions for all resources - -## Implementation Plan Updates - -**Update Development Approach:** - -Populate the project structure section with the actual discovered components: - -```text -src/ -├── [actual-component-1]/ # [Actual component description] -├── [actual-component-2]/ # [Actual component description] -├── shared/ # Shared libraries and utilities -└── docs/ # Additional documentation -``` - -**Update Deployment Strategy:** - -Based on the selected technology stack, document: - -- Infrastructure as Code approach (Bicep templates for selected services) -- Container strategy (if containers stack selected) -- Configuration management approach -- CI/CD pipeline requirements - -## Documentation Requirements - -Ensure all sections are populated with the gathered context: - -1. **Application Architecture** - Complete component details, data architecture, and integration patterns -2. **Azure Service Mapping** - Full service assignments with rationale -3. **Implementation Plan** - Concrete development and deployment approach -4. **Project Status** - Update status based on completed discovery and planning phases - -The tool should transform this template structure: - -```markdown -### Selected Stack: [CONTAINERS/SERVERLESS/LOGIC APPS] -``` - -Into populated content like: - -```markdown -### Selected Stack: CONTAINERS - -#### Selection Rationale -- **Team Expertise**: Team has Docker experience and wants infrastructure control -- **Application Characteristics**: Traditional web API and frontend requiring consistent performance -- **Performance Requirements**: Need minimal cold starts and predictable response times -- **Integration Needs**: Multiple external API integrations with custom authentication -- **Cost Considerations**: Predictable costs preferred over pay-per-execution -``` - -📌 **Completion Checklist** - -- [ ] Application spec reviewed for discovered components and selected technology stack -- [ ] Azure service mapping completed for all discovered components with documented rationale -- [ ] Component relationships and data flow patterns documented -- [ ] Resource organization strategy defined (resource groups, naming, environments) -- [ ] Implementation checklists created for infrastructure and containerization generation -- [ ] Application spec updated with "Azure Service Mapping" section while preserving existing content -- [ ] Architecture documentation complete and ready for implementation phases +- Define infrastructure generation requirements +- Plan deployment sequencing and dependencies +- Identify configuration and environment management needs +- Document next steps for artifact generation diff --git a/cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md index 661dbd0a8fb..e0aabaf2074 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_artifact_generation.md @@ -1,278 +1,52 @@ # AZD Artifact Generation Orchestration Instructions -✅ **Agent Task List** +**TASK:** Orchestrate the complete artifact generation process for AZD projects, generating infrastructure templates, application scaffolding, Docker configurations, and azure.yaml in the correct order with proper dependencies. -1. Review application spec for complete project architecture and service specifications -2. Read required resources from the Infrastructure as Code File Checklist in application spec -3. Analyze existing workspace to identify current artifacts and generation requirements -4. Get IaC generation rules for Azure infrastructure best practices -5. Generate infrastructure templates for all Azure resources using the rules and resource requirements -6. Generate application scaffolding for new project components -7. Generate Docker configuration for containerizable services -8. Generate azure.yaml configuration for AZD deployment -9. Validate all generated artifacts for consistency and deployment readiness -10. Update application spec with artifact generation status and completion tracking +**SUCCESS CRITERIA:** -📄 **Required Outputs** - -- Application scaffolding and starter code for new project components -- Docker configurations (Dockerfiles and .dockerignore) for containerizable services -- Complete Bicep infrastructure templates in `./infra` directory -- Valid `azure.yaml` configuration file mapping all services and resources +- Application scaffolding and starter code generated for new project components +- Docker configurations created for containerizable services +- Complete Bicep infrastructure templates generated in `./infra` directory +- Valid `azure.yaml` configuration file created mapping all services and resources - All artifacts validated for syntax correctness and deployment compatibility -- Updated application spec with comprehensive artifact generation documentation - -🧠 **Execution Guidelines** - -**CRITICAL:** This tool orchestrates the complete artifact generation process for AZD projects. Execute generation phases in the correct order to ensure dependencies are properly handled. Always preserve existing user customizations while adding required AZD capabilities. - -## Pre-Generation Analysis and Planning - -**Architecture Review:** - -- Read complete application spec to understand project architecture -- Review service mappings, technology stack decisions, and infrastructure design -- Identify which artifacts need generation vs updates vs preservation -- Note any existing user customizations that must be maintained - -**Existing Artifact Inventory:** - -Scan workspace for existing artifacts: - -- **Application Code**: Entry points, framework files, existing business logic -- **Docker Files**: Existing Dockerfiles, docker-compose configurations -- **Infrastructure Code**: Current Bicep templates, ARM templates, Terraform files -- **Configuration Files**: Existing azure.yaml, deployment scripts, CI/CD definitions - -**Generation Requirements Assessment:** - -Based on project type and architecture decisions: - -- **New Projects**: Full scaffolding + all infrastructure + configuration -- **Existing Applications**: Minimal scaffolding + infrastructure + configuration preservation -- **Hybrid Scenarios**: Selective generation with integration considerations - -## Application Scaffolding Generation - -**Application Code Generation:** - -Use application code generation capabilities to create: - -**Framework-Appropriate Scaffolding:** - -- Generate complete application structure in `src/` directories -- Create language and framework-specific project files and configurations -- Include Azure SDK integrations and service connection templates -- Add health checks, logging, and monitoring infrastructure -- Generate sample implementation code demonstrating component functionality - -**Component Type Support:** - -- **API Services**: REST APIs, GraphQL endpoints, gRPC services with appropriate frameworks -- **SPA Applications**: React, Angular, Vue.js frontends with TypeScript/JavaScript -- **Message Processors**: Event-driven applications for Service Bus, Event Hubs integration -- **Function Applications**: Azure Functions with appropriate triggers and bindings -- **Web Applications**: Server-rendered applications with authentication and data access -- **Background Services**: Worker services and batch processing applications - -**Technology Integration:** - -- Ensure generated code aligns with programming language preferences from user requirements -- Include framework-specific best practices and development patterns -- Add Azure service integrations based on architecture planning decisions -- Create environment configuration and deployment-ready setup - -## Docker Configuration Generation - -**Containerization Strategy Execution:** - -Use Docker generation capabilities to create: - -**Service Dockerfiles:** - -- Generate optimized Dockerfiles for each containerizable service -- Use multi-stage builds for build optimization and security -- Include language-specific best practices and dependency management -- Add health check configurations and security hardening - -**Docker Optimization:** - -- Create .dockerignore files for efficient build contexts -- Implement layer caching strategies for faster builds -- Use minimal base images and non-root users -- Add container security scanning and vulnerability management - -**Container Orchestration Support:** - -- Ensure Docker configurations work with Azure Container Apps -- Add necessary labels and metadata for service discovery -- Include resource limit and scaling configurations -- Create container networking and communication patterns - -## Infrastructure Template Generation - -**Azure Resource Provisioning:** - -Use infrastructure generation capabilities to create: - -**IaC Rules and Resource Requirements:** - -- Get IaC generation rules for Azure infrastructure best practices and coding standards -- Read required resources from the Infrastructure as Code File Checklist in application spec -- Apply generation rules to each required resource type for consistent implementation - -**Modular Infrastructure Templates:** - -- Generate main.bicep with subscription scope deployment -- Create generic resource modules for reusable Azure service patterns (e.g., `modules/containerapp.bicep`, `modules/storage.bicep`) -- Generate service-specific modules that reference generic modules with customized configurations -- Create resource group organization and management structures - -**Core Infrastructure Components:** - -- Add monitoring and logging infrastructure (Log Analytics, Application Insights) -- Include security and compliance configurations (Key Vault, managed identities) -- Generate database configurations (SQL, Cosmos DB, PostgreSQL, etc.) -- Add messaging infrastructure (Service Bus, Event Hubs, Event Grid) -- Create storage and caching configurations (Storage Accounts, Redis) - -**Networking and Security:** - -- Generate virtual network configurations for multi-service applications -- Add security group rules and access control -- Create private endpoint configurations where appropriate -- Include SSL/TLS certificate management - -**Environment Management:** - -- Create parameter files for different environments (dev, staging, production) -- Add configuration for scaling and performance optimization -- Include backup and disaster recovery configurations -- Generate monitoring and alerting rule definitions - -## Azure.yaml Configuration Generation - -**AZD Deployment Configuration:** - -Use azure.yaml generation capabilities to create: - -**Service Registration:** - -- Map all application services to appropriate Azure hosting services -- Configure build and deployment instructions for each service -- Add dependency relationships and deployment ordering -- Include environment variable and configuration management - -**Infrastructure Integration:** - -- Reference generated Bicep templates and parameters -- Configure resource provisioning and dependency management -- Add post-deployment scripts and validation steps -- Include environment-specific overrides and configurations - -**Development Workflow Integration:** - -- Configure local development and testing scenarios -- Add debugging and troubleshooting capabilities -- Include CI/CD pipeline integration points -- Create deployment validation and rollback procedures - -## Artifact Validation and Quality Assurance - -**Syntax and Schema Validation:** - -- Validate all Docker files for syntax correctness and best practices -- Compile and test all Bicep templates for Azure compatibility -- Validate azure.yaml against AZD schema and configuration requirements -- Test application scaffolding for build and runtime correctness - -**Integration Testing:** - -- Verify Docker containers build and run successfully -- Test infrastructure templates deploy without errors -- Validate azure.yaml configuration deploys all services correctly -- Ensure generated application code integrates with Azure services - -**Security and Compliance Validation:** - -- Scan Docker images for security vulnerabilities -- Review infrastructure templates for security best practices -- Validate access control and authentication configurations -- Ensure compliance with organizational security policies - -## Artifact Generation Workflow - -**Sequential Generation Process:** - -```text -1. Architecture Review → 2. Existing Artifact Inventory → 3. Application Code Generation → -4. Docker Configuration → 5. Infrastructure Templates → 6. Azure.yaml Configuration → -7. Validation and Testing → 8. Documentation Update -``` - -**Iterative Refinement Process:** - -```text -1. Identify specific artifact needs → 2. Generate targeted artifacts → -3. Validate integration → 4. Refine and optimize → 5. Update documentation -``` - -**Error Recovery Process:** - -```text -1. Identify generation failures → 2. Analyze dependency conflicts → -3. Resolve compatibility issues → 4. Regenerate affected artifacts → 5. Revalidate -``` -## Documentation and Completion Tracking +**VALIDATION REQUIRED:** -**Progress Documentation:** +- All generated artifacts compile and validate without errors +- Infrastructure templates follow IaC generation rules and best practices +- Docker configurations are optimized and include health checks +- azure.yaml file validates against AZD schema +- Generated code is consistent with architecture planning decisions -Update application spec with artifact generation status: +**COMPLETION CHECKLIST:** -```markdown -## Artifact Generation Status +- [ ] Review application spec for complete project architecture and service specifications +- [ ] Generate infrastructure templates using IaC generation rules +- [ ] Generate application scaffolding for new project components +- [ ] Generate Docker configuration for containerizable services +- [ ] Generate azure.yaml configuration for AZD deployment +- [ ] Validate all generated artifacts for consistency and deployment readiness +- [ ] Update application spec with artifact generation status -### Application Scaffolding -- [x] Web frontend scaffolding created -- [x] API service template generated -- [x] Database integration configured -- [x] Authentication framework added +## Critical Generation Requirements -### Docker Configurations -- [x] Frontend service Dockerfile created -- [x] API service Dockerfile generated -- [x] .dockerignore files optimized -- [x] Health checks implemented +**Generation Order:** -### Infrastructure Templates -- [x] Main deployment template created -- [x] Container Apps module generated -- [x] Database infrastructure configured -- [x] Monitoring and logging added +1. Infrastructure templates first (foundation) +2. Application scaffolding second (code structure) +3. Docker configurations third (containerization) +4. azure.yaml configuration last (deployment orchestration) -### Azure.yaml Configuration -- [x] Service definitions completed -- [x] Build configurations verified -- [x] Infrastructure references validated -- [x] Deployment workflow tested +**Artifact Dependencies:** -### Validation Results -- [x] All Docker images build successfully -- [x] Infrastructure templates deploy without errors -- [x] Azure.yaml configuration validates -- [x] End-to-end deployment verified -``` +- Infrastructure generation requires architecture planning and IaC rules +- Application scaffolding requires component definitions and technology stack +- Docker generation requires application code and containerization requirements +- azure.yaml requires all service definitions and hosting decisions -**Success Criteria and Completion Checklist:** +**Quality Requirements:** -- [ ] All required application code generated and functional -- [ ] Docker configurations created for all containerizable services -- [ ] Complete infrastructure templates generated and validated -- [ ] Azure.yaml configuration created and schema-compliant -- [ ] All artifacts integrate correctly with each other -- [ ] Generated code follows language and framework best practices -- [ ] Security and compliance requirements met -- [ ] Documentation updated with generation details -- [ ] End-to-end deployment tested and verified -- [ ] Project ready for development and deployment workflows +- Preserve existing user customizations where possible +- Follow security best practices (no hardcoded secrets) +- Ensure deployment readiness and Azure compatibility +- Maintain consistency across all generated artifacts diff --git a/cli/azd/internal/mcp/tools/prompts/azd_azure_yaml_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_azure_yaml_generation.md index 04733e4f456..d991d4af570 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_azure_yaml_generation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_azure_yaml_generation.md @@ -1,101 +1,51 @@ # AZD Azure.yaml Generation Instructions -✅ **Agent Task List** +**TASK:** Create a complete and valid `azure.yaml` file in the root directory that maps all application services to their Azure hosting services with proper build and deployment configurations. -1. Check if application spec exists and review architecture decisions -2. Identify all application services (frontend, backend, functions, etc.) -3. Determine hosting requirements for each service based on Azure service selections -4. Analyze build requirements (language, package manager, build commands) -5. Create complete `azure.yaml` file in root directory following required patterns -6. Validate file against AZD schema using available tools -7. Update existing application spec with generated configuration details while preserving existing content - -📄 **Required Outputs** +**SUCCESS CRITERIA:** - Valid `azure.yaml` file created in root directory -- Service configurations matching Azure service selections from architecture planning -- Build and deployment instructions for all services -- Configuration validated against AZD schema -- Update existing application spec with configuration details while preserving existing content - -🧠 **Execution Guidelines** - -**Service Analysis Requirements:** - -Identify and configure these service types: - -- **Frontend applications:** React, Angular, Vue.js, static sites -- **Backend services:** REST APIs, microservices, GraphQL, gRPC -- **Function-based services:** Azure Functions for event-driven workloads -- **Background services:** Workers and long-running processes +- Service configurations match Azure service selections from architecture planning +- Build and deployment instructions complete for all services +- All service paths and Docker configurations reference existing files correctly -**Hosting Configuration Patterns:** +**VALIDATION REQUIRED:** -**Azure Container Apps** (for microservices, APIs, containerized apps): +- File validates against AZD schema using available tools +- All `project` paths point to existing directories +- All `docker.path` references point to existing Dockerfiles relative to service project path +- Host types match architecture decisions (containerapp, appservice, function, staticwebapp) +- Service names are alphanumeric with hyphens only -```yaml -services: - api: - project: ./src/api - language: js - host: containerapp - docker: - path: ./Dockerfile -``` +**COMPLETION CHECKLIST:** -**Azure App Service** (for traditional web apps): +- [ ] Check if application spec exists and review architecture decisions +- [ ] Identify all application services and their hosting requirements +- [ ] Create complete `azure.yaml` file with service configurations +- [ ] Validate file against AZD schema +- [ ] Update application spec with configuration details -```yaml -services: - webapp: - project: ./src/webapp - language: js - host: appservice -``` +## Critical Configuration Requirements -**Azure Functions** (for serverless workloads): +**Service Type Mappings:** -```yaml -services: - functions: - project: ./src/functions - language: js - host: function -``` +- **Azure Container Apps**: `host: containerapp` (for APIs, microservices, containerized apps) +- **Azure App Service**: `host: appservice` (for traditional web apps) +- **Azure Functions**: `host: function` (for serverless workloads) +- **Azure Static Web Apps**: `host: staticwebapp` (for SPAs, static sites) +- **Azure Kubernetes Service**: `host: aks` (for Kubernetes) -**Azure Static Web Apps** (for SPAs, static sites): +**Path Configuration Rules:** -```yaml -services: - frontend: - project: ./src/frontend - language: js - host: staticwebapp - dist: build -``` - -**Critical Configuration Requirements:** - -- Service names must be alphanumeric with hyphens only -- All `project` paths must point to existing directories -- All `docker.path` references must point to existing Dockerfiles **relative to the service project path** -- Host types must be: `containerapp`, `appservice`, `function`, or `staticwebapp` +- Service `project` paths must point to existing directories +- Docker `path` is relative to the service's project directory, not repository root - Language must match detected programming language -- `dist` paths must match build output directories - -**Important Note:** For Container Apps with Docker configurations, the `docker.path` is relative to the service's `project` directory, not the repository root. For example, if your service project is `./src/api` and the Dockerfile is located at `./src/api/Dockerfile`, the `docker.path` should be `./Dockerfile`. - -**Advanced Configuration Options:** - -- Environment variables using `${VARIABLE_NAME}` syntax -- Custom commands using hooks (prebuild, postbuild, prepackage, postpackage, preprovision, postprovision) -- Service dependencies and startup order +- `dist` paths must match build output directories for static apps -📌 **Completion Checklist** +**Required Configuration Elements:** -- [ ] Valid `azure.yaml` file created in root directory -- [ ] All discovered services properly configured with correct host types -- [ ] Service hosting configurations match Azure service selections from architecture planning -- [ ] Build and deployment instructions complete for all services -- [ ] File validates against any available AZD schema tools -- [ ] Application spec updated with configuration details while preserving existing content +- Service names (alphanumeric with hyphens only) +- Project paths (relative to repository root) +- Language specification +- Host type selection +- Build and deployment configurations diff --git a/cli/azd/internal/mcp/tools/prompts/azd_discovery_analysis.md b/cli/azd/internal/mcp/tools/prompts/azd_discovery_analysis.md index d14f99ca52e..cf402f32d14 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_discovery_analysis.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_discovery_analysis.md @@ -1,66 +1,52 @@ # AZD Application Discovery and Analysis Instructions -✅ **Agent Task List** +**TASK:** Scan and analyze the current workspace to identify all application components, technologies, dependencies, and communication patterns, documenting findings in the application specification. -1. Check if `azd-arch-plan.md` exists and review previous analysis if present -2. Scan current directory recursively for all files and document structure -3. Identify programming languages, frameworks, and configuration files -4. Classify discovered components by type (web apps, APIs, databases, etc.) -5. Map dependencies and communication patterns between components -6. Create `azd-arch-plan.md` if it doesn't exist, or update existing file with complete discovery report while preserving existing content +**SUCCESS CRITERIA:** -📄 **Required Outputs** +- Complete file system inventory documented in application specification +- All application components identified and classified by type +- Component technologies and frameworks documented with file locations +- Dependencies mapped and communication patterns understood +- External services and APIs catalogued with requirements -- Complete file system inventory documented in `azd-arch-plan.md` (create file if missing, update existing while preserving content) -- Component classification table with Type | Technology | Location | Purpose (add to existing file) -- Dependency map showing inter-component communication (add to existing file) -- External dependencies list with required environment variables (add to existing file) -- Discovery report ready for architecture planning phase +**VALIDATION REQUIRED:** -🧠 **Execution Guidelines** +- All major application artifacts discovered and documented +- Component classification is accurate and complete +- Dependencies and communication patterns are correctly identified +- Application specification is created or updated with comprehensive findings -**File System Analysis - Document:** +**COMPLETION CHECKLIST:** -- Programming languages and frameworks detected -- Configuration files (package.json, requirements.txt, pom.xml, Dockerfile, docker-compose.yml) +- [ ] Check if application specification exists and review previous analysis +- [ ] Scan workspace recursively for all application files and configurations +- [ ] Identify programming languages, frameworks, and configuration files +- [ ] Classify discovered components by type (web apps, APIs, databases, etc.) +- [ ] Map dependencies and communication patterns between components +- [ ] Create or update application specification with discovery findings + +## Critical Discovery Requirements + +**File System Analysis:** + +- Programming languages and frameworks +- Configuration files (package.json, requirements.txt, Dockerfile, etc.) - API endpoints, service definitions, application entry points -- Database configurations and connection strings -- CI/CD pipeline files (.github/workflows, azure-pipelines.yml) -- Documentation files and existing architecture docs +- Database configurations and connection patterns +- CI/CD pipeline files and deployment configurations -**Component Classification Categories:** +**Component Classification:** -- **Web Applications:** React/Angular/Vue.js apps, static sites, server-rendered apps -- **API Services:** REST APIs, GraphQL endpoints, gRPC services, microservices -- **Background Services:** Message queue processors, scheduled tasks, data pipelines -- **Databases:** SQL/NoSQL databases, caching layers, migration scripts -- **Messaging Systems:** Message queues, event streaming, pub/sub systems -- **AI/ML Components:** Models, inference endpoints, training pipelines -- **Supporting Services:** Authentication, logging, monitoring, configuration +- **Web Applications**: React/Angular/Vue.js apps, static sites, server-rendered apps +- **API Services**: REST APIs, GraphQL endpoints, gRPC services, microservices +- **Background Services**: Message processors, scheduled tasks, data pipelines +- **Databases**: SQL/NoSQL databases, caching layers, migration scripts +- **Supporting Services**: Authentication, logging, monitoring, configuration -**Dependency Analysis - Identify:** +**Dependency Analysis:** - Internal dependencies (component-to-component communication) - External dependencies (third-party APIs, SaaS services) - Data dependencies (shared databases, file systems, caches) - Configuration dependencies (shared settings, secrets, environment variables) -- Runtime dependencies (required services for startup) - -**Communication Patterns to Document:** - -- Synchronous HTTP/HTTPS calls -- Asynchronous messaging patterns -- Database connections and data access -- File system access patterns -- Caching patterns and session management -- Authentication and authorization flows - -📌 **Completion Checklist** - -- [ ] Complete inventory of all discoverable application artifacts documented -- [ ] All major application components identified and classified by type -- [ ] Component technologies and frameworks documented with file locations -- [ ] Dependencies mapped and communication patterns understood -- [ ] External services and APIs catalogued with requirements -- [ ] `azd-arch-plan.md` created or updated with comprehensive findings while preserving existing content -- [ ] Ready to proceed to architecture planning phase using `azd_architecture_planning` tool diff --git a/cli/azd/internal/mcp/tools/prompts/azd_docker_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_docker_generation.md index 9ffb490a8b9..45fcdff1a75 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_docker_generation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_docker_generation.md @@ -1,115 +1,56 @@ # AZD Docker Generation Instructions -✅ **Agent Task List** +**TASK:** Generate optimized Dockerfiles and .dockerignore files for all containerizable services based on the Docker File Generation Checklist from the application spec. -1. Read the **Docker File Generation Checklist** from application spec -2. Identify containerizable services and required Docker files from the checklist -3. Detect programming language and framework for each containerizable service -4. Generate each Docker file specified in the checklist following language-specific best practices -5. Create .dockerignore files for build optimization -6. Implement health checks and security configurations -7. Update the Docker checklist section in existing application spec by marking completed items as [x] while preserving existing content +**SUCCESS CRITERIA:** -📄 **Required Outputs** +- All Docker files listed in the application spec checklist are generated +- Dockerfiles follow language-specific best practices with multi-stage builds +- .dockerignore files created for build optimization +- Health check endpoints implemented for Container Apps compatibility +- Security configurations and non-root users implemented -- All Docker files listed in the Docker File Generation Checklist from application spec -- Dockerfiles created for all containerizable services -- .dockerignore files generated for each service -- Health check endpoints implemented -- Multi-stage builds with security best practices -- Update existing application spec Docker checklist by marking completed items as [x] while preserving existing content +**VALIDATION REQUIRED:** -🧠 **Execution Guidelines** +- All generated Dockerfiles build successfully without errors +- Health check endpoints respond correctly +- Docker images follow security best practices (non-root users, minimal base images) +- .dockerignore patterns exclude unnecessary files for efficient builds +- Application spec Docker checklist is updated with completion status -**Read Docker Checklist:** +**COMPLETION CHECKLIST:** -- Read the "Docker File Generation Checklist" section from application spec -- This checklist specifies exactly which Docker files need to be generated -- Use this as the authoritative source for what to create -- Follow the exact file paths specified in the checklist +- [ ] Read Docker File Generation Checklist from application spec +- [ ] Identify containerizable services and required Docker files +- [ ] Generate Dockerfiles following language-specific best practices +- [ ] Create .dockerignore files for build optimization +- [ ] Implement health checks and security configurations +- [ ] Update Docker checklist in application spec marking completed items -**Generate Files in Order:** - -- Create service Dockerfiles first (e.g., `{service-path}/Dockerfile`) -- Create corresponding .dockerignore files for each service (e.g., `{service-path}/.dockerignore`) -- Follow the exact file paths specified in the checklist from application spec +## Critical Docker Requirements **Containerization Candidates:** -- **Include:** Microservices, REST APIs, GraphQL services, web applications, background workers -- **Exclude:** Static websites (use Static Web Apps), Azure Functions (serverless), databases (use managed services) - -**Language-Specific Dockerfile Patterns:** - -**Node.js Applications:** - -- Base image: `node:18-alpine` -- Multi-stage build (build + runtime) -- Copy package*.json first for layer caching -- Use `npm ci --only=production` -- Non-root user: `nodejs` -- Expose port 3000, health check `/health` - -**Python Applications:** - -- Base image: `python:3.11-slim` -- Environment: `PYTHONDONTWRITEBYTECODE=1`, `PYTHONUNBUFFERED=1` -- Copy requirements.txt first -- Use `pip install --no-cache-dir` -- Non-root user: `appuser` -- Expose port 8000, health check `/health` - -**.NET Applications:** - -- Build: `mcr.microsoft.com/dotnet/sdk:8.0` -- Runtime: `mcr.microsoft.com/dotnet/aspnet:8.0` -- Multi-stage: restore → build → publish → runtime -- Non-root user: `appuser` -- Expose port 8080, health check `/health` - -**Java/Spring Boot:** - -- Build: `openjdk:17-jdk-slim`, Runtime: `openjdk:17-jre-slim` -- Copy dependency files first for caching -- Non-root user: `appuser` -- Expose port 8080, actuator health check - -**Security and Optimization Requirements:** - -- Always use non-root users in production stage -- Use minimal base images (alpine, slim variants) -- Implement multi-stage builds to reduce size -- Include health check endpoints for Container Apps -- Set proper working directories and file permissions -- Use layer caching by copying dependency files first -- Never include secrets in container images - -**.dockerignore Patterns:** - -- Universal: `.git`, `README.md`, `.vscode/`, `.DS_Store`, `Dockerfile*` -- Node.js: `node_modules/`, `npm-debug.log*`, `coverage/` -- Python: `__pycache__/`, `*.pyc`, `venv/`, `.pytest_cache/` -- .NET: `bin/`, `obj/`, `*.user`, `packages/` -- Java: `target/`, `*.class`, `.mvn/repository` - -**Health Check Implementation:** - -- Endpoint: `/health` (standard convention) -- Response: JSON with status and timestamp -- HTTP Status: 200 for healthy, 503 for unhealthy -- Timeout: 3 seconds maximum -- Content: `{"status": "healthy", "timestamp": "ISO-8601"}` - -📌 **Completion Checklist** - -- [ ] **Docker File Generation Checklist read** from application spec -- [ ] **All files from Docker checklist generated** in the correct locations -- [ ] Dockerfiles created for all containerizable services identified in architecture planning -- [ ] .dockerignore files generated with appropriate exclusions for each language -- [ ] Multi-stage builds implemented to reduce image size -- [ ] Non-root users configured for security -- [ ] Health check endpoints implemented for all services -- [ ] Container startup optimization applied (dependency file caching) -- [ ] All Dockerfiles build successfully (`docker build` test) -- [ ] Security best practices followed (minimal images, no secrets) -- [ ] **Docker checklist in application spec updated** by marking completed items as [x] while preserving existing content +- **Include**: Microservices, REST APIs, GraphQL services, web applications, background workers +- **Exclude**: Static websites (use Static Web Apps), Azure Functions (serverless), databases (use managed services) + +**Essential Dockerfile Elements:** + +- Multi-stage builds (build + runtime stages) +- Minimal base images (alpine, slim variants) +- Non-root users in production stage +- Health check endpoints (`/health` for Container Apps) +- Proper layer caching (copy dependency files first) +- Security hardening and file permissions + +**Language-Specific Patterns:** + +- **Node.js**: `node:18-alpine` base, npm ci, port 3000 +- **Python**: `python:3.11-slim` base, pip install, port 8000 +- **.NET**: Multi-stage with SDK/runtime separation, port 8080 +- **Java**: OpenJDK slim variants, dependency optimization + +**.dockerignore Requirements:** + +- Universal exclusions: `.git`, `README.md`, `.vscode/`, `Dockerfile*` +- Language-specific: `node_modules/`, `__pycache__/`, `bin/obj/`, `target/` diff --git a/cli/azd/internal/mcp/tools/prompts/azd_generate_project_spec.md b/cli/azd/internal/mcp/tools/prompts/azd_generate_infra_module.md similarity index 100% rename from cli/azd/internal/mcp/tools/prompts/azd_generate_project_spec.md rename to cli/azd/internal/mcp/tools/prompts/azd_generate_infra_module.md diff --git a/cli/azd/internal/mcp/tools/prompts/azd_iac_generation_rules.md b/cli/azd/internal/mcp/tools/prompts/azd_iac_generation_rules.md index d472440046c..a0159b9bd11 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_iac_generation_rules.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_iac_generation_rules.md @@ -1,164 +1,83 @@ # Infrastructure as Code (IaC) Generation Rules -✅ **Agent Task List** +**TASK:** Provide authoritative rules and standards for generating Bicep infrastructure templates that follow Azure Well-Architected Framework principles and AZD conventions. -1. Reference these rules when generating any IaC files -2. Follow file structure and organization requirements -3. Implement naming conventions and tagging strategies -4. Apply security and compliance best practices -5. Validate all generated code against these requirements +**SUCCESS CRITERIA:** -📄 **Required Outputs** - -- IaC files following all specified rules and conventions -- Proper file structure in `./infra` directory +- IaC files follow all specified rules and conventions +- Proper file structure in `./infra` directory with modular organization - Compliance with Azure Well-Architected Framework principles -- Security best practices implemented -- Validation passing without errors +- Security best practices implemented throughout +- Latest Bicep schema versions used for all resource types -🧠 **Execution Guidelines** +**VALIDATION REQUIRED:** -**File Structure and Organization:** +- All generated Bicep templates compile without errors or warnings +- Naming conventions follow required patterns with unique hash generation +- Security requirements are met (no hardcoded secrets, proper permissions) +- Resource specifications follow container and service requirements +- Tagging strategy is properly implemented -- **REQUIRED:** Place all IaC files in `./infra` folder -- **REQUIRED:** Name main deployment file `main.bicep` -- **REQUIRED:** Create `main.parameters.json` with parameter defaults -- **REQUIRED:** Main.bicep must use `targetScope = 'subscription'` -- **REQUIRED:** Create resource group as primary container -- **REQUIRED:** Pass resource group scope to all child modules -- **REQUIRED:** Create modular, reusable Bicep files +**COMPLETION CHECKLIST:** -**Naming Conventions:** +- [ ] Use these rules when generating any IaC files +- [ ] Follow file structure and organization requirements +- [ ] Implement naming conventions and tagging strategies +- [ ] Apply security and compliance best practices +- [ ] Validate all generated code against these requirements -- **REQUIRED:** Use pattern `{resourcePrefix}-{name}-{uniqueHash}` -- **REQUIRED:** Generate unique hash from environment name, subscription ID, and resource group name -- **EXAMPLE:** `app-myservice-h3x9k2` where `h3x9k2` is generated -- **FORBIDDEN:** Hard-code tenant IDs, subscription IDs, or resource group names +## Critical IaC Standards -**Module Parameters (All modules must accept):** +**File Structure Requirements:** -- `name` (string): Base name for the resource -- `location` (string): Azure region for deployment -- `tags` (object): Resource tags for governance -- **REQUIRED:** Modules use `targetScope = 'resourceGroup'` -- **REQUIRED:** Provide intelligent defaults for optional parameters -- **REQUIRED:** Use parameter decorators for validation +- **REQUIRED**: All IaC files in `./infra` folder +- **REQUIRED**: Modular, reusable Bicep files with `targetScope = 'resourceGroup'` +- **REQUIRED**: Main deployment file named `main.bicep` with `targetScope = 'subscription'` and references all required modules +- **REQUIRED**: `main.parameters.json` referencing environment variables -**Tagging Strategy:** +**Naming Conventions:** -- **REQUIRED:** Tag resource groups with `azd-env-name: {environment-name}` -- **REQUIRED:** Tag hosting resources with `azd-service-name: {service-name}` -- **RECOMMENDED:** Include governance tags (cost center, owner, etc.) +- **REQUIRED**: Pattern `{resourcePrefix}-{name}-{uniqueHash}` +- **REQUIRED**: Use naming conventions compatible for each Azure resource type +- **REQUIRED**: Generate unique hash from environment name, subscription ID, and resource group name +- **FORBIDDEN**: Hard-code tenant IDs, subscription IDs, or resource group names **Security and Compliance:** -- **FORBIDDEN:** Hard-code secrets, connection strings, or sensitive values -- **REQUIRED:** Use latest API versions and schema for all bicep resource types using available tools -- **REQUIRED:** Use Key Vault references for secrets -- **REQUIRED:** Enable diagnostic settings and logging where applicable -- **REQUIRED:** Follow principle of least privilege for managed identities -- **REQUIRED:** Follow Azure Well-Architected Framework principles +- **FORBIDDEN**: Hard-code secrets, connection strings, or sensitive values +- **REQUIRED**: Use latest API versions and schemas for all resource types +- **REQUIRED**: Key Vault references for secrets +- **REQUIRED**: Diagnostic settings and logging where applicable +- **REQUIRED**: Principle of least privilege for managed identities -**Container Resource Specifications:** +**Resource Specifications:** -- **REQUIRED:** Wrap partial CPU values in `json()` function (e.g., `json('0.5')` for 0.5 CPU cores) -- **REQUIRED:** Memory values should be strings with units (e.g., `'0.5Gi'`, `'1Gi'`, `'2Gi'`) -- **EXAMPLE:** Container Apps resource specification: - - ```bicep - resources: { - cpu: json('0.25') // Correct: wrapped in json() - memory: '0.5Gi' // Correct: string with units - } - ``` +- **REQUIRED**: Wrap partial CPU values in `json()` function (e.g., `json('0.5')`) +- **REQUIRED**: Memory values as strings with units (e.g., `'0.5Gi'`, `'1Gi'`) +- **REQUIRED**: Proper tagging with `azd-env-name` and `azd-service-name` **Supported Azure Services:** -**Primary Hosting Resources (Choose One):** - -- **Azure Container Apps** (PREFERRED): Containerized applications, built-in scaling -- **Azure App Service:** Web applications and APIs, multiple runtime stacks -- **Azure Function Apps:** Serverless and event-driven workloads -- **Azure Static Web Apps:** Frontend applications, built-in CI/CD -- **Azure Kubernetes Service (AKS):** Complex containerized workloads - -**Essential Supporting Resources (REQUIRED for most applications):** - -- **Log Analytics Workspace:** Central logging and monitoring -- **Application Insights:** Application performance monitoring -- **Azure Key Vault:** Secure storage for secrets and certificates - -**Conditional Resources (Include based on requirements):** - -- Azure Container Registry (for container-based apps) -- Azure Service Bus (for messaging scenarios) -- Azure Cosmos DB (for NoSQL data storage) -- Azure SQL Database (for relational data storage) -- Azure Storage Account (for blob/file storage) -- Azure Cache for Redis (for caching scenarios) - -**Main.bicep Structure Template:** - -```bicep -targetScope = 'subscription' -@description('Name of the environment') -param environmentName string -@description('Location for all resources') -param location string -@description('Tags to apply to all resources') -param tags object = {} - -// Generate unique suffix for resource names -var resourceSuffix = take(uniqueString(subscription().id, environmentName, location), 6) -var resourceGroupName = 'rg-${environmentName}-${resourceSuffix}' - -// Create the resource group -resource resourceGroup 'Microsoft.Resources/resourceGroups@2021-04-01' = { - name: resourceGroupName - location: location - tags: union(tags, { - 'azd-env-name': environmentName - }) -} - -// Example module deployment with resource group scope -module appService 'modules/app-service.bicep' = { - name: 'app-service' - scope: resourceGroup - params: { - name: 'myapp' - location: location - tags: tags +- **Primary Hosting**: Container Apps (preferred), App Service, Function Apps, Static Web Apps, AKS +- **Essential Supporting**: Log Analytics Workspace, Application Insights, Key Vault +- **Conditional**: Container Registry, Service Bus, Cosmos DB, SQL Database, Storage Account, Cache for Redis + +**Example main.parameters.json:** + +```json +{ + "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#", + "contentVersion": "1.0.0.0", + "parameters": { + "environmentName": { + "value": "${AZURE_ENV_NAME}" + }, + "location": { + "value": "${AZURE_LOCATION}" + }, + "principalId": { + "value": "${AZURE_PRINCIPAL_ID}" + } } } ``` - -**Child Module Structure Template:** - -```bicep -targetScope = 'resourceGroup' -@description('Base name for all resources') -param name string -@description('Location for all resources') -param location string = resourceGroup().location -@description('Tags to apply to all resources') -param tags object = {} - -// Generate unique suffix for resource names -var resourceSuffix = take(uniqueString(subscription().id, resourceGroup().name, name), 6) -var resourceName = '${name}-${resourceSuffix}' - -// Resource definitions here... -``` - -📌 **Completion Checklist** - -- [ ] All files placed in `./infra` folder with correct structure -- [ ] `main.bicep` exists with subscription scope and resource group creation -- [ ] `main.parameters.json` exists with parameter defaults -- [ ] All child modules use `targetScope = 'resourceGroup'` and receive resource group scope -- [ ] Consistent naming convention applied: `{resourcePrefix}-{name}-{uniqueHash}` -- [ ] Required tags applied: `azd-env-name` and `azd-service-name` -- [ ] No hard-coded secrets, tenant IDs, or subscription IDs -- [ ] Parameters have appropriate validation decorators -- [ ] Security best practices followed (Key Vault, managed identities, diagnostics) diff --git a/cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md b/cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md index fcfa8c6fcf1..1a92b51ae83 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_identify_user_intent.md @@ -1,166 +1,55 @@ # AZD Project Intent and Requirements Discovery Instructions -✅ **Agent Task List** +**TASK:** Engage users with conversational questions to understand project purpose, scale requirements, budget constraints, and architectural preferences, then classify and document findings. -1. Engage user with conversational questions to understand project purpose and stage -2. Determine application scale requirements and production readiness -3. Identify budget and cost constraint considerations -4. Understand architectural and technology stack preferences -5. Classify project into appropriate categories for optimal Azure service recommendations -6. Document findings in Application specification under "Project Requirements" section +**SUCCESS CRITERIA:** -📄 **Required Outputs** +- Project classification determined (POC, Development Tool, or Production Application) +- Scale category identified for production applications (Small, Medium, or Large) +- Budget constraint level established (Cost-Optimized, Balanced, or Performance-Focused) +- Architectural preference documented (Containers, Serverless, Hybrid, or No Preference) +- Comprehensive requirements summary documented in application specification -- Project classification: POC, Development Tool, or Production Application -- Scale category: Small, Medium, or Large (for production applications) -- Budget constraint level: Cost-Optimized, Balanced, or Performance-Focused -- Architectural preference: Containers, Serverless, Hybrid, or No Preference -- Comprehensive requirements summary documented in Application specification +**VALIDATION REQUIRED:** -🧠 **Execution Guidelines** +- All critical requirements gathered through conversational questions +- Project classification aligns with user responses about purpose and audience +- Scale and budget preferences are clearly documented +- Technology and architectural preferences are captured +- Requirements are properly documented in application specification -**CRITICAL:** Ask questions conversationally, one at a time or in small groups. Adapt follow-up questions based on user responses. Don't overwhelm with a long questionnaire. +**COMPLETION CHECKLIST:** -## Phase 1: Project Purpose and Stage Discovery +- [ ] Engage user with conversational questions about project purpose and stage +- [ ] Determine application scale requirements and production readiness +- [ ] Identify budget and cost constraint considerations +- [ ] Understand architectural and technology stack preferences +- [ ] Classify project into appropriate categories +- [ ] Document findings in application specification under "Project Requirements" -Start with foundational questions to understand the project's intent: +## Critical Discovery Questions -**Primary Questions:** +**Project Purpose and Stage:** -- "What's the main purpose of this application? Are you building a proof of concept, a development/internal tool, or planning for a production application?" -- "Who is the intended audience for this application?" (Internal team, external customers, specific user group) -- "What problem does this application solve?" +- Main purpose of the application and intended audience +- Project stage (POC/prototype, development tool, or production application) +- Problem the application solves and success criteria -**Follow-up Questions (based on response):** +**Scale and Performance (Production Applications):** -*If POC/Prototype:* +- Expected user base at launch and growth projections +- Geographic distribution and availability requirements +- Performance criticality and response time needs -- "How long do you expect this proof of concept to run?" -- "Will this potentially evolve into a production application?" -- "Are you primarily focused on demonstrating functionality or testing performance?" +**Budget and Cost Considerations:** -*If Development Tool:* +- Budget constraints and cost targets +- Priority between cost optimization vs performance +- Preference for predictable vs consumption-based pricing -- "How many developers or users will be using this tool?" -- "Is this for temporary use or a long-term internal solution?" -- "Do you need high availability or is occasional downtime acceptable?" +**Architectural and Technology Preferences:** -*If Production Application:* - -- Proceed to Phase 2 for detailed scale assessment - -## Phase 2: Scale and Performance Requirements (Production Applications) - -**User Base Questions:** - -- "How many users do you expect when the application launches?" -- "What's your expected user growth over the next 12 months?" -- "Will usage be steady throughout the day or are there peak periods?" - -**Geographic and Availability Questions:** - -- "Will your users be primarily in one geographic region or globally distributed?" -- "What level of availability do you need? (e.g., 99.9%, 99.99%, or basic uptime)" -- "How critical is performance? Are sub-second response times required?" - -**Scale Classification (Internal Use):** - -- **Small Scale:** <10K users, single region, standard availability requirements -- **Medium Scale:** 10K-100K users, multi-region consideration, higher availability needs -- **Large Scale:** >100K users, global distribution, enterprise-grade availability and performance - -## Phase 3: Budget and Cost Considerations - -**Budget Discovery Questions:** - -- "Do you have specific budget constraints or cost targets for running this application?" -- "Is minimizing costs the top priority, or are you willing to invest more for better performance/reliability?" -- "Are you more concerned about predictable monthly costs or optimizing for the lowest possible spend?" - -**Cost Preference Classification:** - -- **Cost-Optimized:** Minimize expenses, accept some performance trade-offs, prefer consumption-based pricing -- **Balanced:** Reasonable cost with good performance, mix of reserved and consumption pricing -- **Performance-Focused:** Cost is secondary to performance and reliability, premium services acceptable - -## Phase 4: Architectural and Stack Preferences - -**Technology Approach Questions:** - -- "Do you have experience with containers (Docker) or prefer to avoid container management?" -- "Are you interested in serverless approaches where you don't manage infrastructure?" -- "Do you need full control over the underlying infrastructure, or prefer managed services?" -- "Are there specific technologies or platforms you want to use or avoid?" - -**Programming Language and Framework Preferences:** - -- "What programming language does your team prefer or have the most experience with?" (JavaScript/TypeScript, Python, C#, Java, Go, or other) -- "Do you have preferences for specific frameworks?" (React, Angular, Vue for frontend; Express, FastAPI, Spring Boot for backend) -- "Are there any technology constraints from your organization or existing systems?" -- "Do you prefer strongly-typed languages or are you comfortable with dynamic typing?" - -**Integration and Compliance Questions:** - -- "Do you need to integrate with existing systems or databases?" -- "Are there any compliance requirements (HIPAA, SOC2, etc.) that influence your architecture choices?" -- "Do you have existing Azure services or subscriptions this should connect to?" - -**Architectural Preference Classification:** - -- **Containers:** Prefer containerized applications with orchestration (Azure Container Apps, AKS) -- **Serverless:** Prefer event-driven, fully managed compute (Azure Functions, Logic Apps) -- **Hybrid:** Mix of containers and serverless based on component needs -- **No Preference:** Open to recommendations based on best fit for requirements - -**Technology Stack Preferences:** - -- **Programming Language:** [JavaScript/TypeScript, Python, C#, Java, Go, Other] -- **Frontend Framework:** [React, Angular, Vue.js, No Preference, Other] -- **Backend Framework:** [Express/Node.js, FastAPI/Flask, ASP.NET Core, Spring Boot, No Preference, Other] -- **Database Preference:** [SQL-based, NoSQL, No Preference, Existing System Integration] - -## Phase 5: Requirements Documentation - -Create or update Application specification with a "Project Requirements" section containing: - -```markdown -## Project Requirements - -### Project Classification -- **Type:** [POC/Development Tool/Production Application] -- **Primary Purpose:** [Brief description] -- **Target Audience:** [Description of users] - -### Scale Requirements -- **User Base:** [Expected users and growth] -- **Geographic Scope:** [Single region/Multi-region/Global] -- **Availability Needs:** [Uptime requirements] -- **Scale Category:** [Small/Medium/Large - for production apps] - -### Budget Considerations -- **Cost Priority:** [Cost-Optimized/Balanced/Performance-Focused] -- **Budget Constraints:** [Any specific limitations mentioned] -- **Pricing Preference:** [Consumption vs Reserved vs Hybrid] - -### Architectural Preferences -- **Stack Preference:** [Containers/Serverless/Hybrid/No Preference] -- **Programming Language:** [Preferred language and rationale] -- **Frontend Framework:** [Chosen framework if applicable] -- **Backend Framework:** [Chosen framework if applicable] -- **Infrastructure Control:** [Managed services vs Infrastructure control preference] -- **Integration Requirements:** [Existing systems to connect with] -- **Compliance Requirements:** [Any mentioned compliance needs] - -### Key Insights -- [Any additional context that influences architecture decisions] -- [Special requirements or constraints mentioned] -``` - -**Conversation Flow Tips:** - -- Start with open-ended questions and narrow down based on responses -- If user is unsure about technical terms, provide brief explanations -- For POCs, focus more on timeline and potential evolution rather than scale -- For production apps, spend more time on scale and reliability requirements -- Always ask "Is there anything else about your requirements I should know?" at the end -- Keep the tone consultative and helpful, not interrogative +- Team experience with containers, serverless, or infrastructure management +- Programming language and framework preferences +- Technology constraints from organization or existing systems +- Control vs managed services preference diff --git a/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md b/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md index 2662d5fe680..70227a59489 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_infrastructure_generation.md @@ -1,199 +1,52 @@ # AZD Infrastructure Generation Instructions -✅ **Agent Task List** +**TASK:** Generate complete Bicep infrastructure templates in `./infra` directory based on the Infrastructure as Code File Checklist, using latest schema versions and following IaC generation rules. -1. **Inventory existing IaC files** - scan current working directory for all `.bicep` files -2. **Read application spec** to get the Infrastructure as Code File Checklist with required resources -3. **Get IaC generation rules** for Azure infrastructure best practices and coding standards -4. **Get latest bicep schema versions** for each Azure resource type from the required resources -5. Create directory structure in `./infra` following IaC rules -6. For each file in the IaC checklist: - - **If file exists**: Intelligently update to match requirements, preserve user customizations where possible - - **If file missing**: Generate new file following templates and best practices - - **Flag conflicts**: Note any incompatible configurations but proceed with updates -7. **Generate modular infrastructure**: Create generic resource modules and service-specific modules that reference them -8. Validate all generated bicep templates compile without errors or warnings -9. Update the IaC checklist section in existing application spec by marking completed files as [x] while preserving existing content +**SUCCESS CRITERIA:** -📄 **Required Outputs** +- Complete Bicep template structure created in `./infra` directory +- All files from IaC checklist generated or updated intelligently +- Generic resource modules and service-specific modules created +- All templates validated and compile without errors +- Application spec IaC checklist updated with completion status -- **Existing IaC inventory** documenting all current `.bicep` files found -- Complete Bicep template structure in `./infra` directory based on the IaC checklist -- All files listed in the Infrastructure as Code File Checklist from application spec (created or updated) -- Main.bicep file with subscription scope and modular deployment -- **Generic resource modules** for reusable Azure service patterns (e.g., `modules/containerapp.bicep`, `modules/storage.bicep`) -- **Service-specific modules** that reference generic modules with customized configurations (e.g., `modules/user-api.bicep`) -- Parameter files with sensible defaults using latest bicep schema versions -- **Conflict report** highlighting any incompatible configurations that were updated -- All templates validated and error-free -- Update existing application spec IaC checklist by marking completed files as [x] while preserving existing content +**VALIDATION REQUIRED:** -🧠 **Execution Guidelines** +- All Bicep templates compile without errors or warnings +- Latest schema versions used for all Azure resource types +- IaC generation rules followed for naming, security, and structure +- Existing user customizations preserved where compatible +- Infrastructure templates are deployment-ready -**Inventory Existing IaC Files:** +**COMPLETION CHECKLIST:** -- Scan current working directory recursively for all `.bicep` files -- Document existing files, their locations, and basic structure -- Note any existing modules, parameters, and resource definitions -- Identify which checklist files already exist vs. need to be created +- [ ] Inventory existing IaC files and scan workspace for current templates +- [ ] Read application spec Infrastructure as Code File Checklist +- [ ] Get IaC generation rules and latest Bicep schema versions +- [ ] Create directory structure in `./infra` following IaC rules +- [ ] Generate or update each file from the checklist intelligently +- [ ] Create generic resource modules and service-specific modules +- [ ] Validate all templates compile without errors +- [ ] Update IaC checklist in application spec marking completed files -**Read IaC Checklist and Get Generation Rules:** +## Critical Generation Requirements -- Read the "Infrastructure as Code File Checklist" section from application spec -- This checklist specifies exactly which Bicep files need to be generated and their purpose -- Get IaC generation rules for Azure infrastructure best practices and coding standards -- Get latest bicep schema versions for each Azure resource type identified in the checklist -- Cross-reference with existing file inventory to determine update vs. create strategy +**Generation Strategy:** -**Modular Infrastructure Generation Strategy:** +- **Existing Files**: Preserve user customizations, add missing components, update outdated patterns +- **New Files**: Create from templates following IaC generation rules with using latest Bicep schema versions +- **Conflict Resolution**: Document conflicts, prioritize AZD compatibility, preserve architectural intent -**Generic Resource Modules:** +**Module Architecture:** -- Create reusable modules for common Azure resource patterns -- Examples: `modules/containerapp.bicep`, `modules/storage.bicep`, `modules/database.bicep` -- These modules accept parameters for customization but contain standard resource configurations -- Follow IaC generation rules for naming, security, and architectural patterns +- **Generic Resource Modules**: Reusable patterns (`modules/containerapp.bicep`, `modules/storage.bicep`) +- **Service-Specific Modules**: Business logic with specific configurations (`modules/user-api.bicep`) +- **Main Template**: Subscription scope deployment orchestrating all modules -**Service-Specific Modules:** +**File Generation Order:** -- Create modules that reference generic modules with service-specific configurations -- Examples: `modules/user-api.bicep` (calls `containerapp.bicep` with user-api settings) -- These modules provide the business logic and specific parameter values -- Map each service from architecture planning to its corresponding module - -**Smart File Generation Strategy:** - -**For Existing Files:** - -- **Preserve user customizations**: Keep existing resource configurations, naming, and parameters where compatible -- **Add missing components**: Inject required modules, resources, or configurations that are missing -- **Update outdated patterns**: Modernize to use current best practices -- **Maintain functionality**: Ensure existing deployments continue to work - -**For New Files:** - -- Always identify and use the latest bicep schema version for all Azure resource types -- Create from templates following IaC generation rules -- Follow standard naming conventions and patterns - -**Conflict Resolution:** - -- **Document conflicts**: Log when existing configurations conflict with requirements -- **Prioritize functionality**: Make changes needed for AZD compatibility -- **Preserve intent**: Keep user's architectural decisions when possible -- **Flag major changes**: Clearly indicate significant modifications made - -**Generate Files in Order:** - -- Create `./infra/main.bicep` first (always required) -- Create `./infra/main.parameters.json` second (always required) -- Generate generic resource modules in `./infra/modules/` (e.g., `containerapp.bicep`, `storage.bicep`) -- Generate service-specific modules in `./infra/modules/` (e.g., `user-api.bicep`, `order-service.bicep`) -- Follow the exact file paths specified in the checklist from application spec - -**Module Generation Workflow:** - -1. **Identify required resource types** from the Infrastructure as Code File Checklist -2. **Create generic modules first** for each unique Azure resource type -3. **Create service-specific modules** that reference generic modules with specific configurations -4. **Ensure proper dependencies** between modules and main deployment template -5. **Apply IaC generation rules** consistently across all generated files - -**Main Parameters File Requirements:** - -The `./infra/main.parameters.json` file is critical for AZD integration and must follow this exact structure: - -- All parameter values in main.parameters.json must use AZD environment variable expansion syntax (e.g., ${AZURE_LOCATION} ). -- No hard-coded values are allowed for parameters that can be set via environment variables. - -```json -{ - "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#", - "contentVersion": "1.0.0.0", - "parameters": { - "environmentName": { - "value": "${AZURE_ENV_NAME}" - }, - "location": { - "value": "${AZURE_LOCATION}" - }, - "principalId": { - "value": "${AZURE_PRINCIPAL_ID}" - } - } -} -``` - -**Key Features:** - -- **Environment Variable Expansion**: Use `${VARIABLE_NAME}` syntax for dynamic values -- **Standard Parameters**: Always include `environmentName`, `location`, and `principalId` -- **AZD Integration**: These variables are automatically populated by AZD during deployment -- **Additional Parameters**: Add service-specific parameters as needed, using the same substitution pattern - -**Service Infrastructure Mapping:** - -- **Container Apps:** Environment, Log Analytics, Container Registry, App Insights, Managed Identity -- **App Service:** Service Plan, App Service, App Insights, Managed Identity -- **Functions:** Function App, Storage Account, App Insights, Managed Identity -- **Static Web Apps:** Static Web App resource with configuration -- **Database:** SQL/CosmosDB/PostgreSQL with appropriate SKUs and security - -**Module Template Requirements:** - -- Use `targetScope = 'resourceGroup'` for all modules -- Accept resource group scope from main template -- Use standardized parameters (name, location, tags) -- Follow naming convention: `{resourcePrefix}-{name}-{uniqueHash}` -- Output connection information for applications -- Include security best practices and monitoring - -**Required Directory Structure:** - -```text -./infra/ -├── main.bicep # Primary deployment template (subscription scope) -├── main.parameters.json # Default parameters -├── modules/ -│ ├── containerapp.bicep # Generic Container Apps module -│ ├── app-service.bicep # Generic App Service module -│ ├── functions.bicep # Generic Azure Functions module -│ ├── database.bicep # Generic database module -│ ├── storage.bicep # Generic storage module -│ ├── keyvault.bicep # Generic Key Vault module -│ ├── monitoring.bicep # Generic monitoring module -│ ├── user-api.bicep # Service-specific module (references containerapp.bicep) -│ ├── order-service.bicep # Service-specific module (references containerapp.bicep) -│ └── shared-storage.bicep # Service-specific module (references storage.bicep) -└── resources.bicep # Shared resources -``` - -**Main Template Requirements:** - -- Use `targetScope = 'subscription'` -- Accept standardized parameters: `environmentName`, `location`, `principalId` -- Include feature flags for conditional deployment -- Create resource group with proper tagging (`azd-env-name`) -- Call modules conditionally based on service requirements -- Output connection strings and service endpoints - -📌 **Completion Checklist** - -- [ ] **Existing IaC inventory completed** - all `.bicep` files in current directory catalogued -- [ ] **Infrastructure as Code File Checklist read** from application spec -- [ ] **IaC generation rules retrieved** and applied to all generated files -- [ ] **Latest bicep schema versions obtained** for each Azure resource type -- [ ] **Update vs. create strategy determined** for each file in checklist -- [ ] **Generic resource modules created** for each unique Azure resource type -- [ ] **Service-specific modules generated** that reference generic modules appropriately -- [ ] **All files from checklist generated or updated** in the correct locations -- [ ] **User customizations preserved** where compatible with requirements -- [ ] **Conflicts documented** and resolved with functional priority -- [ ] Infrastructure directory structure created following IaC rules -- [ ] Main.bicep template created/updated with subscription scope and resource group -- [ ] Module templates generated/updated for all services listed in checklist -- [ ] Parameter files created/updated with appropriate defaults -- [ ] Naming conventions and tagging implemented correctly -- [ ] Security best practices implemented (Key Vault, managed identities) -- [ ] All Bicep modules are created with latest bicep schema version and meet Azure and Bicep best practices -- [ ] **Infrastructure as Code File Checklist in application spec updated** by marking completed files as [x] while preserving existing content +1. Generic resource modules in `./infra/modules/` +2. Service-specific modules in `./infra/modules/` +3. `./infra/main.bicep` (subscription scope orchestration) references all required modules +4. `./infra/main.parameters.json` (parameter defaults) +5. Follow exact paths from application spec checklist diff --git a/cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md b/cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md index e75365023f6..b088c87e8d2 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_list_stack_resources.md @@ -1,48 +1,47 @@ # AZD Stack Resources List -✅ **Agent Task List** +**TASK:** Provide the definitive list of Azure resources required for each technology stack (baseline and stack-specific) to guide architecture planning and infrastructure generation. -1. Review the baseline Azure resources required for all AZD projects -2. Review the stack-specific Azure resources for the selected technology stack -3. Understand the purpose and configuration of each resource type -4. Use these resource definitions for architecture planning and infrastructure generation - -📄 **Required Outputs** +**SUCCESS CRITERIA:** - Complete understanding of baseline resources shared across all stacks - Detailed knowledge of stack-specific resources and their purposes -- Azure resource type identifiers for precise infrastructure generation -- Resource relationships and dependencies for proper deployment ordering - -🧠 **Execution Guidelines** - -**CRITICAL:** This tool provides the definitive list of Azure resources required for each technology stack. These resource definitions should be used as the foundation for all architecture planning and infrastructure generation activities. +- Azure resource type identifiers available for precise infrastructure generation +- Resource relationships and dependencies understood for proper deployment ordering -## Resource Categories +**VALIDATION REQUIRED:** -### Baseline Resources +- Resource definitions are current and match latest Azure service capabilities +- Stack-specific resources align with architectural approaches +- Resource dependencies and integration patterns are clearly documented +- Resource specifications support both planning and generation phases -All AZD projects receive a standard set of baseline resources that provide essential capabilities like logging, monitoring, configuration management, and secure storage. These resources are provisioned regardless of the selected technology stack. +**COMPLETION CHECKLIST:** -### Stack-Specific Resources +- [ ] Review baseline Azure resources required for all AZD projects +- [ ] Review stack-specific Azure resources for the selected technology stack +- [ ] Understand the purpose and configuration of each resource type +- [ ] Use these resource definitions for architecture planning and infrastructure generation +- [ ] Update application specification to include all required files within IaC checklist -Each technology stack (Containers, Serverless, Logic Apps) includes additional resources optimized for that particular architectural approach. These resources provide the compute and orchestration capabilities specific to the chosen stack. +## Critical Resource Categories -## Usage in Architecture Planning +**Baseline Resources (All Stacks):** -When proceeding to architecture planning, use these resource definitions to: +- Essential capabilities for logging, monitoring, configuration management, and secure storage +- Provisioned regardless of selected technology stack +- Foundation for all AZD projects -- Map application components to appropriate Azure resources -- Plan resource group organization and naming conventions -- Determine resource dependencies and deployment sequencing -- Configure monitoring and logging integration -- Set up security and access control policies +**Stack-Specific Resources:** -## Infrastructure Generation Integration +- **Containers Stack**: Resources optimized for containerized workloads +- **Serverless Stack**: Resources for event-driven and function-based architectures +- **Logic Apps Stack**: Resources for workflow automation and integration scenarios -During infrastructure generation, these resource specifications provide: +**Usage Guidelines:** -- Exact Azure resource type identifiers for Bicep templates -- Required configuration parameters for each resource -- Baseline security and monitoring configurations -- Integration patterns between resources +- **Architecture Planning**: Map application components to appropriate Azure resources +- **Infrastructure Generation**: Provide exact resource type identifiers and configurations +- **Resource Organization**: Plan resource group structure and naming conventions +- **Deployment Sequencing**: Determine resource dependencies and deployment order +- **Integration Patterns**: Configure monitoring, security, and access control diff --git a/cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md b/cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md index ec33f32efe2..69e0c581732 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_modernize_project.md @@ -1,227 +1,60 @@ # AZD Project Modernization and Migration Instructions -✅ **Agent Task List** +**TASK:** Modernize existing applications to be AZD compatible by conducting analysis, requirements discovery, stack selection, architecture planning, and artifact generation while preserving existing functionality. -1. Analyze existing application architecture and codebase -2. Conduct user intent discovery to understand requirements and constraints -3. Determine optimal technology stack based on existing code and user preferences -4. Perform discovery analysis for comprehensive component identification -5. Conduct architecture planning for Azure service selection and infrastructure design -6. Generate files to create AZD-compatible project structure -7. Run full azd project validation and address all errors -8. Document complete modernization in Application specification +**SUCCESS CRITERIA:** -📄 **Required Outputs** - -- Complete AZD-compatible project structure for existing application +- Comprehensive application specification preserving existing project context +- Complete AZD compatible project structure created for existing application +- Bicep infrastructure templates generated in `./infra` directory +- Dockerfiles created for containerizable services where applicable - Valid `azure.yaml` configuration file mapping existing components -- Bicep infrastructure templates in `./infra` directory -- Dockerfiles for containerizable services (where applicable) -- Comprehensive Application specification documentation preserving existing project context - Validated project ready for `azd up` deployment -🧠 **Execution Guidelines** - -**CRITICAL:** This tool modernizes existing applications to be AZD-compatible. Always preserve existing application functionality while adding Azure deployment capabilities. Check for existing Application specification and preserve all user modifications. - -## Workspace Analysis and Initial Assessment - -**Existing Project Evaluation:** - -- Scan workspace for application components, frameworks, and technologies -- Identify programming languages, entry points, and dependencies -- Assess existing containerization (Docker files, docker-compose) -- Review existing infrastructure or deployment configurations -- Note any existing Azure resources or configuration - -**Technology Stack Detection:** - -Based on discovered components, attempt to automatically determine appropriate stack: - -- **Containers Stack**: If Docker files exist, complex dependencies, or traditional web/API applications -- **Serverless Stack**: If function-based architecture, event handlers, or simple stateless APIs detected -- **Logic Apps Stack**: If workflow files, extensive API integrations, or business process automation detected - -**Ambiguity Handling:** - -If stack selection is unclear from code analysis, proceed to stack selection process to gather user preferences. - -## Requirements Discovery and Intent Understanding - -**Conduct User Intent Discovery Process:** - -Even with existing code, gather requirements to understand: - -- Current application purpose and target audience -- Performance and scalability expectations for Azure deployment -- Budget and cost considerations for cloud migration -- Compliance and security requirements -- Timeline and migration urgency - -**Migration-Specific Questions:** - -- "What are your main goals for migrating this application to Azure?" -- "Are there any existing pain points or limitations you want to address?" -- "Do you need to maintain backward compatibility during the migration?" -- "Are there specific Azure services you want to use or avoid?" - -**Documentation Target:** - -Create or update Application specification with "Migration Requirements" section including existing project context and migration goals. - -## Stack Selection and Validation - -**Automatic Stack Determination:** - -If technology stack was clearly identified from code analysis, document the decision with rationale. - -**Manual Stack Selection:** - -If ambiguous, conduct stack selection process focusing on: - -- Team comfort with existing architecture patterns -- Desire to modernize vs maintain current approach -- Performance and operational requirements -- Integration complexity and existing dependencies - -**Stack Decision Documentation:** - -Update Application specification with "Technology Stack Selection" section explaining chosen approach and migration strategy. - -## Comprehensive Discovery and Analysis - -**Perform Discovery Analysis Process:** +**VALIDATION REQUIRED:** -Use discovery analysis capability to: +- Existing application functionality is preserved throughout modernization +- Generated artifacts are compatible with existing code and architecture +- Migration strategy aligns with user requirements and constraints +- All components are properly mapped to Azure services +- AZD project validation passes with all errors resolved -- Create comprehensive inventory of all application components -- Map existing dependencies and communication patterns -- Identify database and external service connections -- Document current architecture and data flows -- Assess containerization readiness for each component +**COMPLETION CHECKLIST:** -**Migration-Aware Analysis:** +- [ ] Analyze existing application architecture and codebase +- [ ] Conduct user intent discovery for requirements and constraints +- [ ] Determine optimal technology stack based on existing code and preferences +- [ ] Perform discovery analysis for comprehensive component identification +- [ ] Conduct architecture planning for Azure service selection +- [ ] Generate artifacts to create AZD compatible project structure +- [ ] Run full AZD project validation and address all errors +- [ ] Document complete modernization in application specification -- Identify components that need minimal changes vs significant refactoring -- Note existing infrastructure that can be preserved or needs replacement -- Document any legacy dependencies that require special handling -- Assess cloud-readiness of each component +## Critical Modernization Requirements -**Documentation Target:** - -Update Application specification with complete "Application Discovery" section including existing architecture analysis and migration considerations. - -## Azure Architecture Planning and Service Mapping - -**Conduct Architecture Planning Process:** - -Use architecture planning capability to: - -- Map each existing component to optimal Azure services -- Design migration-friendly infrastructure organization -- Plan phased migration approach if needed -- Select appropriate database and messaging services -- Design containerization strategy respecting existing patterns - -**Migration Strategy Design:** - -- Plan for minimal disruption deployment approach -- Design rollback strategies and blue-green deployment options -- Consider data migration requirements and strategies -- Plan for environment parity (dev, staging, production) - -**Documentation Target:** - -Update Application specification with "Azure Service Mapping" and "Migration Architecture" sections. - -## AZD Project Structure Creation - -**Artifact Generation Orchestration:** - -Perform comprehensive artifact generation process: +**Existing Project Evaluation:** -1. **Application Integration**: Preserve existing application structure while adding AZD compatibility -2. **Docker Configuration Generation**: Create or update Docker files for containerizable services -3. **Infrastructure Template Generation**: Create Bicep templates for Azure resources -4. **Azure.yaml Generation**: Create AZD configuration mapping existing and new components +- Scan workspace for application components, frameworks, and technologies +- Assess existing containerization and deployment configurations +- Review existing Azure resources or configuration +- Note any existing application architecture documentation **Migration-Specific Considerations:** -- Preserve existing build processes and scripts where possible -- Maintain existing environment variable and configuration patterns -- Ensure generated Docker files work with existing application structure -- Create infrastructure that supports existing application requirements - -**Configuration Preservation:** - -- Maintain existing database schemas and connection patterns -- Preserve API contracts and service interfaces -- Keep existing authentication and authorization patterns -- Maintain current logging and monitoring approaches where compatible - -## Project Validation and Deployment Readiness - -**Perform Project Validation Process:** - -Use project validation capability to ensure: - -- Azure.yaml configuration correctly maps all application components -- Bicep templates deploy successfully in test environment -- All application components start and function correctly -- Database connections and external dependencies work properly -- Environment configuration is complete and secure - -**Migration Validation:** - -- Verify existing functionality is preserved -- Test performance matches or improves upon current deployment -- Confirm security and compliance requirements are met -- Validate monitoring and logging capabilities - -## Implementation Workflow Guide - -**Complete Modernization Workflow:** - -```text -1. Workspace Analysis → 2. User Intent Discovery → 3. Stack Selection (if needed) → -4. Discovery Analysis → 5. Architecture Planning → 6. Artifact Generation → -7. Project Validation -``` - -**Iterative Refinement Workflow:** - -```text -1. Review Application specification → 2. Update specific components → 3. Regenerate affected artifacts → -4. Project Validation -``` - -**Incremental Migration Workflow:** - -```text -1. Select component subset → 2. Focused discovery → 3. Component-specific generation → -4. Validation → 5. Repeat for remaining components -``` - -## Success Criteria and Completion Checklist +- Preserve existing application functionality and architecture decisions +- Maintain backward compatibility during migration process +- Address current pain points or limitations identified by user +- Consider team comfort with existing vs new architectural patterns -**Modernization Completion Requirements:** +**Technology Stack Alignment:** -- [ ] All existing application components identified and mapped to Azure services -- [ ] User intent and migration requirements documented and addressed -- [ ] Technology stack selection completed with clear rationale -- [ ] Complete artifact generation executed (application code, Docker configs, infrastructure, azure.yaml) -- [ ] All existing application functionality preserved and verified -- [ ] Performance and security requirements met or exceeded -- [ ] Application specification comprehensive documentation created while preserving existing content -- [ ] AZD environment initialized and tested -- [ ] Project validation confirms deployment readiness -- [ ] Application confirmed working end-to-end with `azd up` +- **Automatic Determination**: Based on clear code analysis (Docker files, architecture patterns) +- **Manual Selection**: When ambiguous, focus on team comfort and modernization goals +- **Migration Strategy**: Document chosen approach and rationale -**Migration Success Indicators:** +**Artifact Generation Strategy:** -- Existing application runs correctly in Azure environment -- All data connections and external integrations function properly -- Performance meets or exceeds current deployment -- Security and compliance requirements are satisfied -- Team can deploy and manage using AZD workflows -- Rollback procedures tested and documented +- **Preserve Existing**: Keep user customizations and working configurations +- **Add Missing**: Inject AZD required components and configurations +- **Modernize Patterns**: Update to current best practices where beneficial +- **Ensure Compatibility**: Maintain existing deployment and operational patterns diff --git a/cli/azd/internal/mcp/tools/prompts/azd_new_project.md b/cli/azd/internal/mcp/tools/prompts/azd_new_project.md index 4ee7bcaefe9..a0d2fe9ac2d 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_new_project.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_new_project.md @@ -1,49 +1,44 @@ # AZD New Project Creation Orchestration Instructions -✅ **Agent Task List** +**TASK:** Orchestrate complete new project creation from scratch through requirements discovery, stack selection, architecture planning, and file generation guidance to create a ready-to-implement project specification. -1. Welcome user and confirm they want to create a new AZD project from scratch -2. Conduct user intent discovery to understand project requirements and constraints -3. Perform stack selection process to determine optimal technology approach -4. Conduct architecture planning to design Azure service mappings and infrastructure -5. Document comprehensive project specification in Application specification -6. Provide file generation guidance and next steps for implementation -7. Run full azd project validation and address all errors -8. Ensure project specification is fully up to date +**SUCCESS CRITERIA:** -📄 **Required Outputs** +- Complete application specification document created with all project details +- Technology stack recommendation provided with clear rationale +- Azure service architecture design completed with component mappings +- File generation roadmap established for implementation phase +- Project specification serves as blueprint for deployment -- Complete Application specification specification document with all project details -- Clear technology stack recommendation with rationale -- Azure service architecture design with component mappings -- File generation roadmap for implementation phase -- Project validation checklist for final verification -- Ready-to-implement project specification +**VALIDATION REQUIRED:** -🧠 **Execution Guidelines** +- All project requirements gathered through systematic discovery process +- Stack selection aligns with team expertise and project characteristics +- Architecture design supports identified requirements and constraints +- Project specification is comprehensive and implementation-ready +- Validation checklist confirms project readiness -**CRITICAL:** This tool orchestrates the complete new project creation flow. Start fresh and guide the user through each phase systematically. Create comprehensive documentation that serves as the blueprint for file generation and deployment. +**COMPLETION CHECKLIST:** -## Phase 1: Project Initiation and Welcome +- [ ] Welcome user and confirm new project creation intent +- [ ] Conduct user intent discovery for project requirements and constraints +- [ ] Perform stack selection process to determine optimal technology approach +- [ ] Conduct architecture planning for Azure service mappings and infrastructure +- [ ] Document comprehensive project specification +- [ ] Provide file generation guidance and next steps for implementation +- [ ] Run full AZD project validation and address all errors +- [ ] Ensure project specification is complete and up-to-date -**Initial Setup:** +## Critical Creation Process -- Confirm this is a new project creation (no existing code or infrastructure) -- Verify the user wants to create an AZD-compatible Azure project -- Explain the process: "We'll discover your requirements, select the best technology stack, and create a complete project specification" -- Create new Application specification file to document the entire journey +**Project Initiation:** -**Prerequisites Check:** +- Confirm new project creation (no existing code or infrastructure) +- Verify user wants AZD compatible Azure project +- Explain systematic discovery and planning process +- Create new application specification for documentation -- User has a clear idea of what application they want to build -- User has access to Azure subscription or is planning for Azure deployment -- User is ready to answer questions about their project requirements and constraints - -## Phase 2: Requirements Discovery - -**Conduct User Intent Discovery Process:** - -Use the user intent discovery capability to understand: +**Requirements Discovery Phase:** - Project purpose and classification (POC, Development Tool, Production Application) - Expected scale and user base requirements @@ -51,177 +46,16 @@ Use the user intent discovery capability to understand: - Performance and availability expectations - Timeline and deployment urgency -**Key Questions to Address:** - -- What problem does this application solve? -- Who are the target users and how many? -- What are the critical success factors? -- Are there specific compliance or security requirements? -- What's the expected timeline for deployment? - -**Documentation Target:** - -Update Application specification with comprehensive "Project Requirements" section including all discovered intent and constraints. - -## Phase 3: Technology Stack Selection - -**Perform Stack Selection Process:** - -Use the stack selection capability to determine: +**Stack Selection Phase:** - Team technical expertise and preferences -- Application characteristics and complexity -- Performance and scalability requirements -- Integration and workflow needs - -**Stack Options to Evaluate:** - -- **Containers**: For complex applications requiring infrastructure control -- **Serverless**: For event-driven, cost-optimized, simple deployments -- **Logic Apps**: For integration-heavy, workflow automation scenarios - -**Selection Criteria:** - -- Align with team expertise and operational preferences -- Match application performance and scaling requirements -- Support integration and business process needs -- Optimize for identified budget and cost constraints - -**Documentation Target:** - -Update Application specification with "Stack Selection" section documenting chosen stack and detailed rationale. - -## Phase 4: Application Architecture Definition - -**Project Specification Development:** - -Based on user requirements and selected stack, define: - -- **Application Components**: Break down the application into logical services/components -- **Component Responsibilities**: Define what each component does and its purpose -- **Data Requirements**: Identify data storage, processing, and flow needs -- **Integration Points**: Map external systems, APIs, and service dependencies -- **User Interaction Patterns**: Define how users interact with the application - -**Architecture Planning Considerations:** - -- Component communication patterns (REST APIs, messaging, events) -- Data persistence strategies (databases, file storage, caching) -- Authentication and authorization requirements -- Monitoring and logging needs -- Security and compliance requirements - -**Documentation Target:** - -Create detailed "Application Architecture" section in Application specification with component breakdown and specifications. - -## Phase 5: Azure Service Architecture Planning - -**Conduct Architecture Planning Process:** - -Use the architecture planning capability to: - -- Map each application component to optimal Azure services -- Design infrastructure organization and resource grouping -- Plan networking and security architecture -- Select appropriate database and messaging services -- Design containerization strategy for selected stack - -**Service Selection Focus:** - -- Leverage the selected stack (Containers/Serverless/Logic Apps) as primary guidance -- Choose services that align with performance and scale requirements -- Optimize for identified budget and cost constraints -- Ensure services support required integrations and compliance needs - -**Infrastructure Design Elements:** - -- Resource group organization -- Networking and connectivity approach -- Security and access control strategy -- Monitoring and observability setup -- Backup and disaster recovery considerations - -**Documentation Target:** - -Update Application specification with complete "Azure Service Mapping" and "Infrastructure Architecture" sections. - -## Phase 6: Implementation Roadmap Creation - -**Artifact Generation Planning:** - -Based on the architecture design, prepare for comprehensive artifact generation: - -- **Application Scaffolding Strategy**: Define starter code structure and framework setup -- **Infrastructure Planning**: Identify all required Azure resources and configurations -- **Containerization Approach**: Plan Docker configurations if applicable -- **Configuration Management**: Design azure.yaml structure and service mappings - -**Development Workflow Setup:** - -- CI/CD pipeline requirements and integration points -- Local development environment setup and testing -- Deployment and rollback procedures -- Monitoring and observability configuration - -**Documentation Target:** - -Add "Implementation Roadmap" section to Application specification with detailed artifact generation requirements and setup guidance. - -## Phase 7: Validation and Next Steps - -**Project Validation Preparation:** - -Reference the project validation capability to prepare for: - -- Azure.yaml configuration validation -- Bicep template structure verification -- Environment setup validation -- Deployment readiness assessment - -**Next Steps Guidance:** - -Provide clear direction for moving to implementation: - -- "Your project specification is complete and documented in Application specification" -- "Next phase: Execute artifact generation to create your complete project structure" -- "Use the artifact generation capability to create application scaffolding, Docker configurations, infrastructure templates, and azure.yaml file" -- "After artifact generation, use project validation to ensure everything is properly configured" -- "Finally, run `azd up` to deploy your application to Azure" - -**Final Documentation Structure:** - -Ensure Application specification contains all required sections: - -```markdown -# [Project Name] - AZD Architecture Plan - -## Project Requirements -[User intent discovery results] - -## Stack Selection -[Chosen stack and rationale] - -## Application Architecture -[Component breakdown and specifications] - -## Azure Service Mapping -[Component to Azure service mappings] - -## Infrastructure Architecture -[Resource organization and networking design] - -## Implementation Roadmap -[File generation and setup guidance] - -## Validation Checklist -[Project validation requirements] -``` +- Application characteristics and complexity requirements +- Performance and scalability needs +- Integration and workflow requirements -**Success Criteria:** +**Architecture Planning Phase:** -- User understands their project architecture completely -- All technical decisions are documented with clear rationale -- Implementation path is clear and actionable -- Project is ready for file generation phase -- Validation requirements are understood +- Application component breakdown and relationships +- Azure service mappings based on stack selection +- Infrastructure and deployment strategy +- Implementation roadmap and next steps diff --git a/cli/azd/internal/mcp/tools/prompts/azd_plan_init.md b/cli/azd/internal/mcp/tools/prompts/azd_plan_init.md index 995d7fa9dcc..14edd035378 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_plan_init.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_plan_init.md @@ -1,194 +1,66 @@ # AZD Project Initialization Decision Tree Instructions -✅ **Agent Task List** +**TASK:** Analyze workspace contents to determine project state, classify as "new project" or "existing application", route users to appropriate workflow, and execute the selected workflow with proper tool orchestration. -1. Analyze current workspace to determine project state and contents -2. Classify workspace as "empty/minimal" or "existing application" -3. Route user to appropriate workflow: new project creation or application modernization -4. Confirm routing decision with user before proceeding -5. Perform the selected workflow with proper tool orchestration -6. Update application specification after each step within the workflow +**SUCCESS CRITERIA:** -📄 **Required Outputs** +- Workspace analysis completed with clear routing decision rationale +- User confirmation obtained for selected workflow path +- Chosen workflow executed completely (new project creation or application modernization) +- Professional application specification document created +- Validated AZD compatible project ready for deployment -- Workspace analysis summary with routing decision rationale -- User confirmation of selected workflow path -- Complete execution of chosen workflow (new project or modernization) -- Professional project specification document (app-spec.md) -- Validated AZD-compatible project ready for deployment +**VALIDATION REQUIRED:** -🧠 **Execution Guidelines** +- Workspace analysis correctly identifies application vs minimal content +- Routing decision aligns with workspace contents and user intentions +- Selected workflow completes successfully with all required components +- Generated project passes AZD validation requirements +- Application specification provides comprehensive project documentation -**CRITICAL:** This tool serves as the entry point for AZD project initialization. It analyzes the workspace and routes users to the most appropriate workflow. Always confirm the routing decision with users before proceeding. +**COMPLETION CHECKLIST:** -## Workspace Analysis and Classification +- [ ] Analyze current workspace to determine project state and contents +- [ ] Classify workspace as "empty/minimal" or "existing application" +- [ ] Route user to appropriate workflow with confirmation +- [ ] Perform selected workflow with proper tool orchestration +- [ ] Update application specification throughout the workflow +- [ ] Validate final project readiness for deployment -**Comprehensive Workspace Scan:** +## Critical Analysis and Routing -Analyze the current directory and subdirectories for: +**Workspace Classification Logic:** -**Application Indicators (suggest modernization path):** - -- Programming language files: `.js`, `.ts`, `.py`, `.cs`, `.java`, `.go`, `.php`, `.rb`, etc. -- Framework configuration files: `package.json`, `requirements.txt`, `pom.xml`, `Gemfile`, `go.mod`, `composer.json` -- Application entry points: `main.py`, `app.js`, `index.js`, `Program.cs`, `Main.java`, `main.go` -- Web application files: HTML, CSS, JavaScript files, template files -- Docker configurations: `Dockerfile`, `docker-compose.yml`, `.dockerignore` -- Build configurations: `Makefile`, `CMakeLists.txt`, build scripts -- Configuration files: `.env`, `appsettings.json`, `config.yaml`, etc. - -**Minimal Content Indicators (suggest new project path):** - -- Only documentation files: `README.md`, `CHANGELOG.md`, `LICENSE`, etc. -- Git files: `.gitignore`, `.git` directory -- Empty directories or placeholder files -- Basic configuration without dependencies: empty `package.json`, template files - -**Existing AZD Project Indicators:** - -- `azure.yaml` file exists -- `./infra/` directory with Bicep templates -- Project specification document (app-spec.md) - -## Decision Logic and Routing - -**Classification Rules:** - -**Route to New Project Creation if:** +**Route to New Project Creation:** - No programming language files found - Only documentation and git files present - Empty workspace or minimal placeholder content - User explicitly wants to start from scratch -**Route to Application Modernization if:** +**Route to Application Modernization:** - Application code files detected (any programming language) -- Framework configuration files present +- Framework configuration files present (package.json, requirements.txt, etc.) - Docker files or containerization artifacts found -- Existing build or deployment configurations - Clear application structure and entry points **Handle Existing AZD Projects:** -- If `azure.yaml` exists, determine if this is an update/refinement workflow +- If `azure.yaml` exists, determine update/refinement needs - Check completeness of existing AZD configuration -- Route to appropriate maintenance or enhancement workflow - -**Ambiguous Cases:** - -- When workspace contains mixed content, present findings and let user choose -- If minimal code exists but unclear if it's a real application vs examples -- When existing AZD files are incomplete or outdated - -## User Confirmation and Workflow Selection - -**Present Analysis Results:** - -After workspace scan, provide summary: - -- "I found [X] application files including [languages/frameworks detected]" -- "The workspace appears to contain [existing application/minimal content]" -- "Based on this analysis, I recommend the [modernization/new project] workflow" - -**Confirmation Questions:** - -**For Modernization Path:** - -- "I detected an existing application with [technologies found]. Would you like to modernize this application for Azure deployment using AZD?" -- "This will add Azure deployment capabilities while preserving your existing application structure." - -**For New Project Path:** - -- "The workspace appears empty or contains only documentation. Would you like to create a new AZD project from scratch?" -- "This will guide you through defining requirements and creating a complete new application." - -**Alternative Option:** - -- Always offer the alternative: "Or would you prefer to [create new project/modernize existing] instead?" - -## Workflow Execution - -**New Project Creation Workflow:** - -If user confirms new project path: - -- Perform new project creation process -- Guide through complete requirements gathering and architecture planning -- Create comprehensive project specification and implementation roadmap -- Reference appropriate file generation and validation processes - -**Application Modernization Workflow:** - -If user confirms modernization path: - -- Perform application modernization process -- Analyze existing architecture and gather migration requirements -- Plan Azure service mapping and infrastructure design -- Create AZD-compatible project structure while preserving existing functionality - -**Existing AZD Project Enhancement:** - -If AZD project already exists: - -- Review current project specification (app-spec.md) for completed work -- Identify gaps or areas needing updates -- Perform targeted improvements or additions -- Validate and test updated configuration - -## Decision Tree Summary - -```text -Workspace Analysis - ├── Empty/Minimal Content Found - │ ├── Confirm: New Project Creation? → Begin New Project Workflow - │ └── User Override → Begin Modernization Workflow - │ - ├── Application Code Found - │ ├── Confirm: Modernize Existing? → Begin Modernization Workflow - │ └── User Override → Begin New Project Workflow - │ - ├── Existing AZD Project Found - │ ├── Complete Configuration → Offer Enhancement Options - │ └── Incomplete Configuration → Resume/Fix Configuration - │ - └── Ambiguous Content - └── Present Options → User Selects → Begin Chosen Workflow -``` - -## Error Handling and Edge Cases - -**Workspace Access Issues:** - -- If unable to scan workspace, ask user to describe their project -- Provide manual selection options for workflow choice - -**Mixed Content Scenarios:** - -- Example code mixed with real application code -- Multiple unrelated applications in same workspace -- Legacy or deprecated code alongside current application - -**User Uncertainty:** - -- If user is unsure about their project type, provide guided questions -- Offer to start with discovery process to help determine appropriate path -- Allow workflow switching if initial choice proves incorrect - -## Success Criteria +- Route to appropriate maintenance workflow -**Successful Routing Achieved When:** +**User Confirmation Process:** -- Workspace analysis accurately reflects actual content -- User understands and confirms the recommended workflow -- Selected workflow matches user's actual goals and project state -- Execution proceeds smoothly with appropriate tool orchestration -- Final result meets user's deployment and functionality requirements +- Present analysis results with detected technologies and recommendations +- Explain chosen workflow path and what it will accomplish +- Obtain explicit user confirmation before proceeding +- Handle ambiguous cases by presenting options and letting user choose -**Quality Assurance:** +**Workflow Execution:** -- Decision rationale is clearly documented -- User confirmation is explicit and informed -- Workflow execution follows established patterns -- Documentation maintains consistency across all paths -- Final validation confirms project readiness +- Execute chosen workflow systematically with proper tool orchestration +- Maintain application specification throughout the process +- Ensure all workflow steps complete successfully +- Validate final project before completion diff --git a/cli/azd/internal/mcp/tools/prompts/azd_project_validation.md b/cli/azd/internal/mcp/tools/prompts/azd_project_validation.md index 6771623a0d1..b57c3ff1636 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_project_validation.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_project_validation.md @@ -1,89 +1,55 @@ # AZD Project Validation Instructions -✅ **Agent Task List** +**TASK:** Execute comprehensive validation of AZD project components including azure.yaml schema, Bicep templates, environment configuration, packaging, and deployment preview to ensure deployment readiness. -1. Load existing `azd-arch-plan.md` to understand current project state and context -2. Execute azure.yaml against azd schema using available tool -3. Compile and validate all Bicep templates in ./infra directory -4. Verify AZD environment exists and is properly configured -5. Run `azd package --no-prompt` to validate service packaging -6. Execute `azd provision --preview --no-prompt` to test infrastructure deployment -7. Resolve ALL issues found in each validation step before proceeding -8. Update existing `azd-arch-plan.md` with validation results by adding/updating validation section while preserving existing content - -📄 **Required Outputs** +**SUCCESS CRITERIA:** - Complete validation report with all checks passed - All identified issues resolved with zero remaining errors - Confirmation that project is ready for deployment -- Update existing `azd-arch-plan.md` with validation results while preserving existing content -- Validation checklist added to or updated in architecture plan -- Clear next steps for deployment - -🧠 **Execution Guidelines** - -**CRITICAL REQUIREMENT:** Resolve ALL issues found during validation before proceeding to the next step. -No validation step should be considered successful until all errors, warnings, and issues have been fully addressed. - -**Validation Execution Steps:** +- Validation results documented in application architecture plan +- Clear next steps provided for deployment -**1. Load Architecture Plan:** +**VALIDATION REQUIRED:** -- Read existing `azd-arch-plan.md` to understand current project architecture and context -- Review any previous validation results or known issues -- Understand the project structure and service configurations from the plan -- **MANDATORY:** Must load and review architecture plan before starting validation +- `azure.yaml` passes schema validation without anyerrors or warnings +- AZD environment exists and is properly configured +- All Bicep templates compile without errors or warnings +- `azd provision --preview --no-prompt` completes successfully with all resources validating +- `azd package --no-prompt` completes without errors with all services packaging successfully +- All service configurations are valid with no missing or incorrect settings -**2. Azure.yaml Schema Validation:** +**COMPLETION CHECKLIST:** -- Check if `azure.yaml` exists in current directory -- Validate `azure.yaml` against AZD schema using available tools -- Parse and report any schema violations or missing fields -- Verify service definitions and configurations are correct -- **MANDATORY:** Fix ALL schema violations before proceeding +- [ ] Load existing application architecture plan for project context +- [ ] `azure.yaml` schema validation passes without any errors or warnings +- [ ] Compile and validate all Bicep templates in ./infra directory +- [ ] Verify AZD environment exists and is properly configured +- [ ] Run `azd package --no-prompt` to validate service packaging +- [ ] Execute `azd provision --preview --no-prompt` to test infrastructure deployment +- [ ] Resolve ALL issues found in each validation step +- [ ] Update application architecture plan with validation results -**3. AZD Environment Validation:** +## Critical Validation Requirements -- Execute `azd env list` to check available environments -- If no environments exist, create one: `azd env new -dev` -- Ensure environment is selected and configured -- Ensure `AZURE_LOCATION` azd environment variable is set to a valid Azure location value -- Ensure `AZURE_SUBSCRIPTION_ID` azd environment variable is set to the users current Azure subscription -- **MANDATORY:** Fix environment issues before proceeding +**Mandatory Resolution Requirement:** -**4. Bicep Template Validation:** +- **CRITICAL**: Resolve ALL issues found during validation before proceeding +- No validation step is successful until all errors, warnings, and issues are fully addressed +- Each validation step must pass completely before moving to the next -- Scan `./infra` directory for `.bicep` files using file search -- Review AZD IaC generation rules and guidelines and resolve any all issues -- Execute `azd provision --preview --no-prompt` to validate infrastructure templates -- **MANDATORY:** Fix ALL compilation errors before proceeding -- Clean up any generated `` files generated during bicep validation +**Validation Execution Order:** -**5. Package Validation:** - -- Execute `azd package --no-prompt` command and monitor output -- Verify all service source paths are valid -- Check Docker builds complete successfully for containerized services -- Ensure all build artifacts are created correctly -- **MANDATORY:** Fix ALL packaging errors before proceeding +1. **Architecture Plan Review**: Load and understand current project context +2. **Schema Validation**: Validate azure.yaml against AZD schema +3. **Environment Validation**: Ensure AZD environment is configured with required variables. Prompt user for environment name, location, Azure Subscription and other required values +4. **Package Validation**: Verify all services can be packaged successfully +5. **Deployment Preview**: Test infrastructure deployment without actual provisioning **Error Resolution Requirements:** -- **Azure.yaml Schema Errors:** Validate azure.yaml using available tools -- **Bicep Compilation Errors:** Parse error output, check module paths and parameter names, verify resource naming -- **Environment Issues:** Run `azd auth login` if needed, check subscription access, verify location parameter -- **Package Errors:** Check service source paths, verify Docker builds work locally, ensure dependencies available -- **Provision Preview Errors:** Verify subscription permissions, check resource quotas, ensure resource names are unique - -📌 **Completion Checklist** - -- [ ] `azd-arch-plan.md` loaded and reviewed for project context -- [ ] `azure.yaml` passes schema validation with NO errors or warnings -- [ ] AZD environment exists and is properly configured with NO issues -- [ ] ALL Bicep templates compile without errors or warnings -- [ ] `azd provision --preview` completes without errors or warnings with ALL resources validating correctly -- [ ] `azd package` completes without errors or warnings with ALL services packaging successfully -- [ ] ALL service configurations are valid with NO missing or incorrect settings -- [ ] NO missing dependencies or configuration issues remain -- [ ] Validation results added to existing `azd-arch-plan.md` while preserving existing content -- [ ] Project confirmed ready for deployment with `azd up` +- **Azure.yaml Errors**: Fix schema violations, verify service paths, validate configurations +- **Environment Issues**: Configure authentication, set required variables, verify permissions +- **Bicep Errors**: Resolve compilation issues, verify module paths, check resource naming +- **Package Errors**: Fix service paths, resolve Docker build issues, verify dependencies +- **Provision Errors**: Address permission issues, resolve resource conflicts, fix configuration problems diff --git a/cli/azd/internal/mcp/tools/prompts/azd_select_stack.md b/cli/azd/internal/mcp/tools/prompts/azd_select_stack.md index a108dc9c9ee..dd87aa27520 100644 --- a/cli/azd/internal/mcp/tools/prompts/azd_select_stack.md +++ b/cli/azd/internal/mcp/tools/prompts/azd_select_stack.md @@ -1,194 +1,75 @@ # AZD Stack Selection and Recommendation Instructions -✅ **Agent Task List** +**TASK:** Assess team expertise, application characteristics, and project requirements through targeted questions to select the optimal single technology stack (Containers, Serverless, or Logic Apps) with clear rationale. -1. Review existing Application specification for project requirements and user intent findings -2. Assess team expertise and technical preferences through targeted questions -3. Evaluate performance and scalability requirements for the application -4. Determine workflow and integration complexity needs -5. Select the optimal single stack: Containers, Serverless, or Logic Apps -6. Document stack selection rationale in Application specification +**SUCCESS CRITERIA:** -📄 **Required Outputs** +- Single stack recommendation provided (Containers, Serverless, or Logic Apps) +- Clear rationale documented based on team capabilities and application needs +- Application specification updated with "Stack Selection" section +- Next steps guidance provided for the chosen stack -- Single stack recommendation: **Containers**, **Serverless**, or **Logic Apps** -- Clear rationale for stack selection based on user responses -- Updated Application specification with "Stack Selection" section -- Next steps guidance for the chosen stack +**VALIDATION REQUIRED:** -🧠 **Execution Guidelines** +- Stack selection aligns with team expertise and preferences +- Chosen stack supports application characteristics and requirements +- Decision rationale is clearly documented and defensible +- Application specification properly updated with selection details +- Recommendation sets up successful architecture planning phase -**CRITICAL:** Always check for existing Application specification first to understand project context. Use generic, non-Azure-specific language when asking questions. Focus on application characteristics and team capabilities rather than specific Azure services. +**COMPLETION CHECKLIST:** -## Phase 1: Context Review and Setup +- [ ] Review existing application specification for project requirements and context +- [ ] Assess team expertise and technical preferences through targeted questions +- [ ] Evaluate performance and scalability requirements for the application +- [ ] Determine workflow and integration complexity needs +- [ ] Select optimal single stack with clear rationale +- [ ] Document stack selection and reasoning in application specification +- [ ] User has confirmed stack recommendation -**Review Existing Information:** +## Critical Selection Criteria -- Check if Application specification exists and review "Project Requirements" section -- Note project type (POC/Development/Production), scale category, and architectural preferences -- Use existing findings to tailor questions and skip redundant inquiries +**Team Expertise Assessment:** -**If no prior context exists, gather basic project understanding:** +- Experience with containerization technologies (Docker) +- Comfort with event-driven or function-based programming +- Experience with workflow automation and business process tools +- Programming language and framework preferences +- Operational preferences (infrastructure control vs managed services) -- "What type of application are you building?" (web app, API, data processing, etc.) -- "What's the primary function of your application?" +**Application Characteristics Analysis:** -## Phase 2: Team Expertise and Technical Preference Assessment +- Traffic patterns (steady vs variable/unpredictable) +- Performance requirements (cold start sensitivity, response times) +- Runtime characteristics (continuous vs event-driven) +- Computational complexity (lightweight vs heavy workloads) -**Development Experience Questions:** +**Integration and Workflow Requirements:** -- "What's your team's experience level with containerization technologies like Docker?" -- "Have you worked with event-driven or function-based programming before?" -- "Does your team have experience with workflow automation or business process tools?" -- "What programming languages and frameworks is your team most comfortable with?" +- System integration complexity (connecting APIs, data sources, legacy systems) +- Business workflow needs (multi-step processes, approvals, decision points) +- File processing and document workflow requirements +- Visual workflow design preferences vs code-based solutions -**Operational Preferences:** +**Stack Selection Logic:** -- "Do you prefer to have control over the underlying infrastructure, or would you rather focus purely on code?" -- "How comfortable is your team with managing deployments and scaling decisions?" -- "Would you prefer predictable costs or pay-per-use pricing that scales with demand?" +**Containers Stack:** -## Phase 3: Application Characteristics Analysis - -**Performance and Scalability Questions:** - -- "Does your application need to handle sudden spikes in traffic or maintain steady performance?" -- "How important are cold start times? Do you need instant response to requests?" -- "Will your application run continuously or respond to specific events/triggers?" -- "Do you expect heavy computational workloads or primarily lightweight request processing?" - -**Integration and Workflow Questions:** - -- "Does your application primarily connect different systems, APIs, or data sources together?" -- "Are you building business workflows that involve multiple steps, approvals, or decision points?" -- "Do you need to integrate with many external services, databases, or legacy systems?" -- "Is your application more about processing data/requests or orchestrating complex business processes?" - -**Complexity and Maintenance Questions:** - -- "How complex is your business logic? Is it straightforward request-response or multi-step processes?" -- "Do you need to handle file processing, document workflows, or data transformations?" -- "Will you need visual workflow designers or are you comfortable with code-based solutions?" - -## Phase 4: Stack Selection Logic - -**Use this decision framework to recommend a single stack:** - -### Containers Stack Recommendation - -**Choose when:** - -- Team has Docker/containerization experience OR wants infrastructure control -- Application has complex dependencies or custom runtime requirements +- Team has Docker experience OR wants infrastructure control +- Complex dependencies or custom runtime requirements - Need consistent performance with minimal cold starts - Building traditional web applications, APIs, or microservices -- Require custom scaling logic or persistent connections -- Application runs continuously or has predictable traffic patterns - -**Key Indicators:** - -- "We want control over our deployment environment" -- "We have complex dependencies that need specific configurations" -- "Performance consistency is critical for our users" -- "We're building a traditional web app or API service" - -### Serverless Stack Recommendation - -**Choose when:** - -- Team prefers to focus on code over infrastructure management -- Application is event-driven or has variable/unpredictable traffic -- Cost optimization is important (pay only for usage) -- Building simple APIs, data processing, or reactive applications -- Quick development and deployment cycles are prioritized -- Automatic scaling without configuration is desired - -**Key Indicators:** - -- "We want to focus on writing code, not managing servers" -- "Our traffic is unpredictable or event-based" -- "We want to minimize operational overhead" -- "We're building functions that respond to specific triggers" - -### Logic Apps Stack Recommendation - -**Choose when:** - -- Application is primarily about connecting systems and orchestrating workflows -- Team needs visual workflow design capabilities -- Building business process automation or integration solutions -- Multiple external API integrations are required -- Non-developers need to understand or modify workflows -- Complex business rules and approval processes are involved - -**Key Indicators:** - -- "We're connecting multiple existing systems together" -- "We need to automate business processes with multiple steps" -- "We have many external APIs and services to integrate" -- "Non-technical team members need to understand the workflow" -- "We're building automation that involves approvals or decision trees" - -## Phase 5: Final Selection and Documentation - -**Selection Process:** - -1. Score each stack based on user responses (internal agent logic) -2. Select the highest-scoring stack -3. If tied, prefer in order: Logic Apps (for integration-heavy), Containers (for performance-critical), Serverless (for simplicity) - -**Required Documentation in Application specification:** - -Create or update with "Stack Selection" section: - -```markdown -## Stack Selection - -### Recommended Stack: [CONTAINERS/SERVERLESS/LOGIC APPS] - -### Selection Rationale -- **Team Expertise:** [Summary of team capabilities and preferences] -- **Performance Requirements:** [Key performance and scalability factors] -- **Application Characteristics:** [Primary application type and complexity] -- **Integration Needs:** [External systems and workflow requirements] - -### Key Decision Factors -- [List 3-4 main reasons why this stack was chosen] -- [Include specific user responses that influenced the decision] - -### Next Steps -- [Specific guidance for proceeding with the chosen stack] -- [Get the specific Azure resources required for this stack] -- [Architecture planning will map these resources to your application components] -``` - -**Conversation Closure:** - -- Summarize the selection: "Based on your requirements, I recommend the **[Stack Name]** stack because..." -- Explain the key benefits: "This choice will give you..." -- Provide confidence: "This stack aligns well with your team's expertise in..." -- Offer next steps: "The next phase will define the specific Azure resources for your chosen stack." - -**Stack-Specific Next Steps Guidance:** - -*Containers:* - -- "We'll configure Container Apps environment and registry for your containerized applications" -- "Each application component will get its own Container App instance" -- "Consider container orchestration, networking, and scaling requirements" - -*Serverless:* - -- "We'll set up Azure Functions with appropriate triggers and bindings" -- "Plan for event-driven architecture with the baseline monitoring and configuration services" -- "Determine function hosting plans and scaling strategies" -*Logic Apps:* +**Serverless Stack:** -- "We'll design workflows using Logic Apps with visual workflow designer" -- "Map out integration points with external systems and APIs" -- "Leverage the baseline services for configuration, secrets, and monitoring" +- Team prefers code-focused over infrastructure management +- Event-driven application or variable traffic patterns +- Cost optimization priority with unpredictable usage +- Simple to moderate complexity applications -**Resource Planning Notes:** +**Logic Apps Stack:** -All stacks will include the standard baseline resources plus the stack-specific compute resources. Retrieve the complete resource definitions for architecture planning. +- Integration-heavy scenarios with many external systems +- Business process automation and workflow requirements +- Visual workflow design preference +- Complex multi-step business processes with approvals diff --git a/go.mod b/go.mod index 2613968718c..d3978d1290f 100644 --- a/go.mod +++ b/go.mod @@ -39,6 +39,7 @@ require ( github.com/bradleyjkemp/cupaloy/v2 v2.8.0 github.com/braydonk/yaml v0.9.0 github.com/buger/goterm v1.0.4 + github.com/charmbracelet/glamour v0.10.0 github.com/cli/browser v1.3.0 github.com/denormal/go-gitignore v0.0.0-20180930084346-ae8ad1d07817 github.com/drone/envsubst v1.0.3 @@ -50,10 +51,9 @@ require ( github.com/golobby/container/v3 v3.3.2 github.com/google/uuid v1.6.0 github.com/gorilla/websocket v1.5.3 - github.com/i2y/langchaingo-mcp-adapter v0.0.0-20250623114610-a01671e1c8df github.com/joho/godotenv v1.5.1 github.com/magefile/mage v1.15.0 - github.com/mark3labs/mcp-go v0.36.0 + github.com/mark3labs/mcp-go v0.39.1 github.com/mattn/go-colorable v0.1.14 github.com/mattn/go-isatty v0.0.20 github.com/microsoft/ApplicationInsights-Go v0.4.4 @@ -63,6 +63,7 @@ require ( github.com/nathan-fiscaletti/consolesize-go v0.0.0-20220204101620-317176b6684d github.com/otiai10/copy v1.14.1 github.com/psanford/memfs v0.0.0-20241019191636-4ef911798f9b + github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 github.com/sergi/go-diff v1.3.1 github.com/sethvargo/go-retry v0.3.0 github.com/spf13/cobra v1.9.1 @@ -99,7 +100,6 @@ require ( github.com/buger/jsonparser v1.1.1 // indirect github.com/cenkalti/backoff/v4 v4.3.0 // indirect github.com/charmbracelet/colorprofile v0.2.3-0.20250311203215-f60798e515dc // indirect - github.com/charmbracelet/glamour v0.10.0 // indirect github.com/charmbracelet/lipgloss v1.1.1-0.20250404203927-76690c660834 // indirect github.com/charmbracelet/x/ansi v0.8.0 // indirect github.com/charmbracelet/x/cellbuf v0.0.13 // indirect @@ -141,8 +141,6 @@ require ( github.com/pkoukk/tiktoken-go v0.1.6 // indirect github.com/pmezard/go-difflib v1.0.0 // indirect github.com/rivo/uniseg v0.4.7 // indirect - github.com/santhosh-tekuri/jsonschema/v5 v5.3.1 // indirect - github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 // indirect github.com/segmentio/asm v1.2.0 // indirect github.com/segmentio/encoding v0.4.1 // indirect github.com/shopspring/decimal v1.2.0 // indirect diff --git a/go.sum b/go.sum index 8b482d86308..4185382d80e 100644 --- a/go.sum +++ b/go.sum @@ -109,12 +109,18 @@ github.com/PuerkitoBio/goquery v1.8.1/go.mod h1:Q8ICL1kNUJ2sXGoAhPGUdYDJvgQgHzJs github.com/adam-lavrik/go-imath v0.0.0-20210910152346-265a42a96f0b h1:g9SuFmxM/WucQFKTMSP+irxyf5m0RiUJreBDhGI6jSA= github.com/adam-lavrik/go-imath v0.0.0-20210910152346-265a42a96f0b/go.mod h1:XjvqMUpGd3Xn9Jtzk/4GEBCSoBX0eB2RyriXgne0IdM= github.com/airbrake/gobrake v3.6.1+incompatible/go.mod h1:wM4gu3Cn0W0K7GUuVWnlXZU11AGBXMILnrdOU8Kn00o= +github.com/alecthomas/assert/v2 v2.7.0 h1:QtqSACNS3tF7oasA8CU6A6sXZSBDqnm7RfpLl9bZqbE= +github.com/alecthomas/assert/v2 v2.7.0/go.mod h1:Bze95FyfUr7x34QZrjL+XP+0qgp/zg8yS+TtBj1WA3k= github.com/alecthomas/chroma/v2 v2.14.0 h1:R3+wzpnUArGcQz7fCETQBzO5n9IMNi13iIs46aU4V9E= github.com/alecthomas/chroma/v2 v2.14.0/go.mod h1:QolEbTfmUHIMVpBqxeDnNBj2uoeI4EbYP4i6n68SG4I= +github.com/alecthomas/repr v0.4.0 h1:GhI2A8MACjfegCPVq9f1FLvIBS+DrQ2KQBFZP1iFzXc= +github.com/alecthomas/repr v0.4.0/go.mod h1:Fr0507jx4eOXV7AlPV6AVZLYrLIuIeSOWtW57eE/O/4= github.com/andybalholm/cascadia v1.3.2 h1:3Xi6Dw5lHF15JtdcmAHD3i1+T8plmv7BQ/nsViSLyss= github.com/andybalholm/cascadia v1.3.2/go.mod h1:7gtRlve5FxPPgIgX36uWBX58OdBsSS6lUvCFb+h7KvU= github.com/aymanbagabas/go-osc52/v2 v2.0.1 h1:HwpRHbFMcZLEVr42D4p7XBqjyuxQH5SMiErDT4WkJ2k= github.com/aymanbagabas/go-osc52/v2 v2.0.1/go.mod h1:uYgXzlJ7ZpABp8OJ+exZzJJhRNQ2ASbcXHWsFqH8hp8= +github.com/aymanbagabas/go-udiff v0.2.0 h1:TK0fH4MteXUDspT88n8CKzvK0X9O2xu9yQjWpi6yML8= +github.com/aymanbagabas/go-udiff v0.2.0/go.mod h1:RE4Ex0qsGkTAJoQdQQCA0uG+nAzJO/pI/QwceO5fgrA= github.com/aymerick/douceur v0.2.0 h1:Mv+mAeH1Q+n9Fr+oyamOlAkUNPWPlA8PPGR0QAaYuPk= github.com/aymerick/douceur v0.2.0/go.mod h1:wlT5vV2O3h55X9m7iVYN0TBM0NH/MmbLnd30/FjWUq4= github.com/bahlo/generic-list-go v0.2.0 h1:5sz/EEAK+ls5wF+NeqDpk5+iNdMDXrh3z3nPnH1Wvgk= @@ -155,6 +161,8 @@ github.com/charmbracelet/x/ansi v0.8.0 h1:9GTq3xq9caJW8ZrBTe0LIe2fvfLR/bYXKTx2ll github.com/charmbracelet/x/ansi v0.8.0/go.mod h1:wdYl/ONOLHLIVmQaxbIYEC/cRKOQyjTkowiI4blgS9Q= github.com/charmbracelet/x/cellbuf v0.0.13 h1:/KBBKHuVRbq1lYx5BzEHBAFBP8VcQzJejZ/IA3iR28k= github.com/charmbracelet/x/cellbuf v0.0.13/go.mod h1:xe0nKWGd3eJgtqZRaN9RjMtK7xUYchjzPr7q6kcvCCs= +github.com/charmbracelet/x/exp/golden v0.0.0-20240806155701-69247e0abc2a h1:G99klV19u0QnhiizODirwVksQB91TJKV/UaTnACcG30= +github.com/charmbracelet/x/exp/golden v0.0.0-20240806155701-69247e0abc2a/go.mod h1:wDlXFlCrmJ8J+swcL/MnGUuYnqgQdW9rhSD61oNMb6U= github.com/charmbracelet/x/exp/slice v0.0.0-20250327172914-2fdc97757edf h1:rLG0Yb6MQSDKdB52aGX55JT1oi0P0Kuaj7wi1bLUpnI= github.com/charmbracelet/x/exp/slice v0.0.0-20250327172914-2fdc97757edf/go.mod h1:B3UgsnsBZS/eX42BlaNiJkD1pPOUa+oF1IYC6Yd2CEU= github.com/charmbracelet/x/term v0.2.1 h1:AQeHeLZ1OqSXhrAWpYUtZyX1T3zVxfpZuEQMIQaGIAQ= @@ -177,8 +185,6 @@ github.com/denormal/go-gitignore v0.0.0-20180930084346-ae8ad1d07817 h1:0nsrg//Dc github.com/denormal/go-gitignore v0.0.0-20180930084346-ae8ad1d07817/go.mod h1:C/+sI4IFnEpCn6VQ3GIPEp+FrQnQw+YQP3+n+GdGq7o= github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f h1:lO4WD4F/rVNCu3HqELle0jiPLLBs70cWOduZpkS1E78= github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f/go.mod h1:cuUVRXasLTGF7a8hSLbxyZXjz+1KgoB3wDUb6vlszIc= -github.com/dlclark/regexp2 v1.10.0 h1:+/GIL799phkJqYW+3YbOd8LCcbHzT0Pbo8zl70MHsq0= -github.com/dlclark/regexp2 v1.10.0/go.mod h1:DHkYz0B9wPfa6wondMfaivmHpzrQ3v9q8cnmRbL6yW8= github.com/dlclark/regexp2 v1.11.0 h1:G/nrcoOa7ZXlpoa/91N3X7mM3r8eIlMBBJZvsz/mxKI= github.com/dlclark/regexp2 v1.11.0/go.mod h1:DHkYz0B9wPfa6wondMfaivmHpzrQ3v9q8cnmRbL6yW8= github.com/drone/envsubst v1.0.3 h1:PCIBwNDYjs50AsLZPYdfhSATKaRg/FJmDc2D6+C2x8g= @@ -257,21 +263,19 @@ github.com/googleapis/gax-go/v2 v2.12.4 h1:9gWcmF85Wvq4ryPFvGFaOgPIs1AQX0d0bcbGw github.com/googleapis/gax-go/v2 v2.12.4/go.mod h1:KYEYLorsnIGDi/rPC8b5TdlB9kbKoFubselGIoBMCwI= github.com/goph/emperror v0.17.2 h1:yLapQcmEsO0ipe9p5TaN22djm3OFV/TfM/fcYP0/J18= github.com/goph/emperror v0.17.2/go.mod h1:+ZbQ+fUNO/6FNiUo0ujtMjhgad9Xa6fQL9KhH4LNHic= -github.com/gorilla/css v1.0.0 h1:BQqNyPTi50JCFMTw/b67hByjMVXZRwGha6wxVGkeihY= -github.com/gorilla/css v1.0.0/go.mod h1:Dn721qIggHpt4+EFCcTLTU/vk5ySda2ReITrtgBl60c= github.com/gorilla/css v1.0.1 h1:ntNaBIghp6JmvWnxbZKANoLyuXTPZ4cAMlo6RyhlbO8= github.com/gorilla/css v1.0.1/go.mod h1:BvnYkspnSzMmwRK+b8/xgNPLiIuNZr6vbZBTPQ2A3b0= github.com/gorilla/websocket v1.5.3 h1:saDtZ6Pbx/0u+bgYQ3q96pZgCzfhKXGPqt7kZ72aNNg= github.com/gorilla/websocket v1.5.3/go.mod h1:YR8l580nyteQvAITg2hZ9XVh4b55+EU/adAjf1fMHhE= github.com/grpc-ecosystem/grpc-gateway/v2 v2.26.3 h1:5ZPtiqj0JL5oKWmcsq4VMaAW5ukBEgSGXEN89zeH1Jo= github.com/grpc-ecosystem/grpc-gateway/v2 v2.26.3/go.mod h1:ndYquD05frm2vACXE1nsccT4oJzjhw2arTS2cpUD1PI= +github.com/hexops/gotextdiff v1.0.3 h1:gitA9+qJrrTCsiCl7+kh75nPqQt1cx4ZkudSTLoUqJM= +github.com/hexops/gotextdiff v1.0.3/go.mod h1:pSWU5MAI3yDq+fZBTazCSJysOMbxWL1BSow5/V2vxeg= github.com/hinshun/vt10x v0.0.0-20220119200601-820417d04eec h1:qv2VnGeEQHchGaZ/u7lxST/RaJw+cv273q79D81Xbog= github.com/hinshun/vt10x v0.0.0-20220119200601-820417d04eec/go.mod h1:Q48J4R4DvxnHolD5P8pOtXigYlRuPLGl6moFx3ulM68= github.com/hpcloud/tail v1.0.0/go.mod h1:ab1qPbhIpdTxEkNHXyeSf5vhxWSCs/tWer42PpOxQnU= github.com/huandu/xstrings v1.3.3 h1:/Gcsuc1x8JVbJ9/rlye4xZnVAbEkGauT8lbebqcQws4= github.com/huandu/xstrings v1.3.3/go.mod h1:y5/lhBue+AyNmUVz9RLU9xbLR0o4KIIExikq4ovT0aE= -github.com/i2y/langchaingo-mcp-adapter v0.0.0-20250623114610-a01671e1c8df h1:4lTJXCZw16BF0BCzrQ1LUzlMW4+2OwBkkYj1/bRybhY= -github.com/i2y/langchaingo-mcp-adapter v0.0.0-20250623114610-a01671e1c8df/go.mod h1:oL2JAtsIp/1vnVy4UG4iDzL8SZwkOzqvRL3YR9PGPjs= github.com/imdario/mergo v0.3.11/go.mod h1:jmQim1M+e3UYxmgPu/WyfjB3N3VflVyUjjjwH0dnCYA= github.com/imdario/mergo v0.3.13 h1:lFzP57bqS/wsqKssCGmtLAb8A0wKjLGrve2q3PPVcBk= github.com/imdario/mergo v0.3.13/go.mod h1:4lJ1jqUDcsbIECGy0RUJAXNIhg+6ocWgb1ALK2O4oXg= @@ -310,8 +314,8 @@ github.com/magefile/mage v1.15.0 h1:BvGheCMAsG3bWUDbZ8AyXXpCNwU9u5CB6sM+HNb9HYg= github.com/magefile/mage v1.15.0/go.mod h1:z5UZb/iS3GoOSn0JgWuiw7dxlurVYTu+/jHXqQg881A= github.com/mailru/easyjson v0.7.7 h1:UGYAvKxe3sBsEDzO8ZeWOSlIQfWFlxbzLZe7hwFURr0= github.com/mailru/easyjson v0.7.7/go.mod h1:xzfreul335JAWq5oZzymOObrkdz5UnU4kGfJJLY9Nlc= -github.com/mark3labs/mcp-go v0.36.0 h1:rIZaijrRYPeSbJG8/qNDe0hWlGrCJ7FWHNMz2SQpTis= -github.com/mark3labs/mcp-go v0.36.0/go.mod h1:T7tUa2jO6MavG+3P25Oy/jR7iCeJPHImCZHRymCn39g= +github.com/mark3labs/mcp-go v0.39.1 h1:2oPxk7aDbQhouakkYyKl2T4hKFU1c6FDaubWyGyVE1k= +github.com/mark3labs/mcp-go v0.39.1/go.mod h1:T7tUa2jO6MavG+3P25Oy/jR7iCeJPHImCZHRymCn39g= github.com/mattn/go-colorable v0.1.2/go.mod h1:U0ppj6V5qS13XJ6of8GYAs25YV2eR4EVcfRqFIhoBtE= github.com/mattn/go-colorable v0.1.14 h1:9A9LHSqF/7dyVVX6g0U9cwm9pG3kP9gSzcuIPHPsaIE= github.com/mattn/go-colorable v0.1.14/go.mod h1:6LmQG8QLFO4G5z1gPvYEzlUgJ2wF+stgPZH1UqBm1s8= @@ -327,8 +331,6 @@ github.com/mattn/go-runewidth v0.0.16/go.mod h1:Jdepj2loyihRzMpdS35Xk/zdY8IAYHsh github.com/mgutz/ansi v0.0.0-20170206155736-9520e82c474b/go.mod h1:01TrycV0kFyexm33Z7vhZRXopbI8J3TDReVlkTgMUxE= github.com/mgutz/ansi v0.0.0-20200706080929-d51e80ef957d h1:5PJl274Y63IEHC+7izoQE9x6ikvDFZS2mDVS3drnohI= github.com/mgutz/ansi v0.0.0-20200706080929-d51e80ef957d/go.mod h1:01TrycV0kFyexm33Z7vhZRXopbI8J3TDReVlkTgMUxE= -github.com/microcosm-cc/bluemonday v1.0.26 h1:xbqSvqzQMeEHCqMi64VAs4d8uy6Mequs3rQ0k/Khz58= -github.com/microcosm-cc/bluemonday v1.0.26/go.mod h1:JyzOCs9gkyQyjs+6h10UEVSe02CGwkhd72Xdqh78TWs= github.com/microcosm-cc/bluemonday v1.0.27 h1:MpEUotklkwCSLeH+Qdx1VJgNqLlpY2KXwXFM08ygZfk= github.com/microcosm-cc/bluemonday v1.0.27/go.mod h1:jFi9vgW+H7c3V0lb6nR74Ib/DIB5OBs92Dimizgw2cA= github.com/microsoft/ApplicationInsights-Go v0.4.4 h1:G4+H9WNs6ygSCe6sUyxRc2U81TI5Es90b2t/MwX5KqY= @@ -387,8 +389,6 @@ github.com/rogpeppe/go-internal v1.13.1 h1:KvO1DLK/DRN07sQ1LQKScxyZJuNnedQ5/wKSR github.com/rogpeppe/go-internal v1.13.1/go.mod h1:uMEvuHeurkdAXX61udpOXGD/AzZDWNMNyH2VO9fmH0o= github.com/rollbar/rollbar-go v1.0.2/go.mod h1:AcFs5f0I+c71bpHlXNNDbOWJiKwjFDtISeXco0L5PKQ= github.com/russross/blackfriday/v2 v2.1.0/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQDYRxCVz55jmeOWTM= -github.com/santhosh-tekuri/jsonschema/v5 v5.3.1 h1:lZUw3E0/J3roVtGQ+SCrUrg3ON6NgVqpn3+iol9aGu4= -github.com/santhosh-tekuri/jsonschema/v5 v5.3.1/go.mod h1:uToXkOrWAZ6/Oc07xWQrPOhJotwFIyu2bBVN41fcDUY= github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 h1:KRzFb2m7YtdldCEkzs6KqmJw4nqEVZGK7IN2kJkjTuQ= github.com/santhosh-tekuri/jsonschema/v6 v6.0.2/go.mod h1:JXeL+ps8p7/KNMjDQk3TCwPpBy0wYklyWTfbkIzdIFU= github.com/segmentio/asm v1.2.0 h1:9BQrFxC+YOHJlTlHGkTrFWf59nbL3XnCoFLTwDCI7ys=