name	configure-component
description	Configure an individual application component by mapping it to an Azure service with SKU, region, and service-specific settings

Purpose

This skill configures a single application component by mapping it to a specific Azure service and capturing the configuration details. It generates infra/application-architecture/components/{component-id}.json for each configured component.

These JSON files are used by the IaC generation skills (/generate-code-bicep and /generate-code-terraform) to produce infrastructure code.

The configured component will be displayed in the UI when the user runs npx @zureltd/az-infra-harness and navigates to the Application Architecture section.

When to Use

Run this skill when:

An application component needs to be mapped to an Azure service
A component's Azure configuration needs to be updated
User explicitly runs /configure-component

Prerequisite: infra/application-definition/application-components.md must exist with at least one component defined. Run /application-components first if it doesn't.

Component ID Convention

The {component-id} used in the filename is derived from the component name in application-components.md:

Convert to lowercase
Replace spaces with hyphens
Remove special characters
Examples: "API Backend" → api-backend, "Web Frontend" → web-frontend, "Customer Database" → customer-database

Workflow

Step 0: Read Context for Defaults

Before starting the interactive flow, read existing context data to provide smart defaults:

infra/context/infrastructure-context.md — extract the preferred Azure region from network topology
infra/context/platform-context.md — extract shared services (Key Vault, Log Analytics) that may inform settings
infra/application-definition/non-functional-requirements.md — extract scale/availability requirements to suggest appropriate SKUs
infra/application-architecture/components/*.json — check what region and patterns already-configured components use for consistency

Use these as suggestions (clearly labelled) during the interactive flow. For example:

If prior components use eastus2, suggest that as the default region
If NFRs specify 99.9% uptime, recommend HA-capable SKUs
If NFRs mention high concurrent users, suggest higher scaling limits

Step 0b: Azure CLI Discovery (Optional)

If the user has Azure CLI (az) available, run discovery commands to suggest existing resources:

# Check if logged in
az account show --query "{subscription:name, id:id}" -o tsv 2>/dev/null

# List existing Container App Environments (for compute components)
az containerapp env list --query "[].{name:name, location:location, rg:resourceGroup}" -o table 2>/dev/null

# List existing SQL Servers (for data components)
az sql server list --query "[].{name:name, location:location, rg:resourceGroup}" -o table 2>/dev/null

# List existing Redis caches
az redis list --query "[].{name:name, location:location, sku:sku.name}" -o table 2>/dev/null

# List available regions
az account list-locations --query "[?metadata.regionType=='Physical'].{name:name, displayName:displayName}" -o table 2>/dev/null

If az is not available or not logged in: Skip silently and proceed with manual questions.

If resources are found: Present them as context: "I found an existing Container Apps Environment in eastus2 — would you like to deploy to the same region?"

Step 1: Read Existing Components

Read infra/application-definition/application-components.md to get the list of defined components.

If the file doesn't exist or is empty:

I need a list of application components before I can configure them. Please run /application-components first to define your application's components.

Stop the skill.

Also check infra/application-architecture/components/ for any already-configured component JSON files.

Step 2: Present Component Selection

Present the list of components to the user and indicate which are already configured.

Here are your application components:

1. **API Backend** (Compute) — [description] ✅ Already configured
2. **Web Frontend** (Compute) — [description] ⬜ Not yet configured
3. **Customer Database** (Data) — [description] ⬜ Not yet configured
4. **Application Gateway** (Networking) — [description] ⬜ Not yet configured

Which component would you like to configure? (Enter the number or name)

Wait for the user's selection before proceeding.

Step 3: Interactive Configuration

This skill MUST comply with the shared Interaction & Validation Standard: .opencode/skills/_shared/interaction-validation-standard.md

Use the TodoWrite tool to create a task list at the start with these high-priority items (adjust based on component type):

Azure Service selection
SKU / Tier
Region
Service-specific settings

Question 1: Azure Service

First, suggest appropriate Azure services based on the component type:

For Compute components:

For the **[Component Name]** component ([description]), which Azure service would you like to use?

Common options for compute:
- **Azure Container Apps** — serverless containers with auto-scaling (recommended for APIs, workers)
- **Azure App Service** — PaaS web hosting (recommended for web frontends, simple APIs)
- **Azure Kubernetes Service (AKS)** — full container orchestration (for complex microservices)
- **Azure Functions** — serverless event-driven compute (for short-running tasks)
- **Azure Container Instances** — simple container hosting (for batch jobs)

Which would you like to use?

For Data components:

For the **[Component Name]** component ([description]), which Azure service would you like to use?

Common options for data:
- **Azure SQL Database** — managed relational database (SQL Server compatible)
- **Azure Database for PostgreSQL Flexible Server** — managed PostgreSQL
- **Azure Cosmos DB** — globally distributed NoSQL database
- **Azure Cache for Redis** — managed Redis cache
- **Azure Service Bus** — enterprise messaging (queues and topics)
- **Azure Storage Account** — blob, file, queue, and table storage
- **Azure Event Hubs** — event streaming at scale

Which would you like to use?

For Networking components:

For the **[Component Name]** component ([description]), which Azure service would you like to use?

Common options for networking:
- **Azure Application Gateway** — L7 load balancer with WAF
- **Azure Front Door** — global CDN + load balancing
- **Azure API Management** — API gateway with policies, developer portal
- **Azure Load Balancer** — L4 load balancer (internal or public)
- **Azure Firewall** — network-level traffic filtering

Which would you like to use?

Question 2: SKU / Pricing Tier

After the user selects an Azure service, ask about the SKU. Present the relevant options for that specific service:

Example for Container Apps:

Which pricing tier would you like for Container Apps?
- **Consumption** — pay per use, scale to zero (recommended for variable workloads)
- **Dedicated** — dedicated compute with reserved capacity (for predictable, high-volume workloads)

Example for Azure SQL Database:

Which service tier would you like for Azure SQL Database?
- **General Purpose** — balanced compute and storage (most common)
- **Business Critical** — high performance with in-memory OLTP
- **Serverless** — auto-pause during inactivity, pay per vCore-second
- **Hyperscale** — very large databases (100TB+)

Question 3: Region

Which Azure region should this component be deployed to?

If you're not sure, the most common choices are:
- East US 2 (eastus2)
- West Europe (westeurope)
- North Europe (northeurope)
- UK South (uksouth)

Or specify another region if required.

Validation: Must match a valid Azure region name or common alias.

Question 4: Service-Specific Settings

Ask for the most important configuration settings for the chosen service. Focus on the settings that affect IaC generation.

For Container Apps (Consumption):

For Container Apps, please provide:
1. **Minimum replicas**: How many instances should always be running? (e.g., 0 for scale-to-zero, 1 to keep warm, 2 for HA)
2. **Maximum replicas**: Maximum number of instances during peak load? (e.g., 10)
3. **CPU**: vCPU allocation per replica? (e.g., 0.5, 1.0)
4. **Memory**: Memory per replica? (e.g., 1Gi, 2Gi)
5. **Ingress**: Should this component accept external traffic (external) or only internal traffic (internal)?
6. **Private endpoint**: Should this component be accessible only via private endpoint (internal VNet)?

For Azure SQL Database:

For Azure SQL Database, please provide:
1. **Compute tier**: Serverless or Provisioned?
2. **vCores**: How many vCores? (e.g., 2, 4, 8 for Provisioned; min/max for Serverless)
3. **Storage**: Maximum storage size? (e.g., 32 GB, 128 GB)
4. **Backup retention**: How many days of backup retention? (default: 7)
5. **Geo-redundancy**: Enable geo-redundant backups? (yes/no)
6. **Private endpoint**: Should the database only be accessible via private endpoint?

For other services: Ask for the equivalent critical settings based on the service type. Focus on what will actually vary in the Bicep/Terraform code.

Step 4: Open Items Gate

Before generating the JSON, summarize any missing information:

Open Items:
- [Missing Item 1]
- [Missing Item 2]

Resolve all open items. Only proceed when there are zero open items.

Step 5: Generate JSON

Once all information is gathered, create the JSON file with this structure:

{
  "azureService": "Container Apps",
  "sku": "Consumption",
  "region": "eastus2",
  "settings": {
    "minReplicas": 2,
    "maxReplicas": 10,
    "cpu": 1.0,
    "memory": "2Gi",
    "ingress": "external",
    "privateEndpoint": true
  }
}

JSON formatting rules:

azureService: full Azure service name (e.g., "Container Apps", "Azure SQL Database")
sku: tier/SKU name as it appears in Azure portal
region: Azure region short name (e.g., "eastus2", "westeurope")
settings: service-specific key-value pairs; keys in camelCase; values must be correct types (numbers, strings, booleans)
No trailing commas
Properly formatted with 2-space indentation

Step 6: Validation

Before saving:

✅ All required fields present: azureService, sku, region, settings
✅ settings contains at least 2 service-specific values
✅ JSON is valid (no syntax errors)
✅ No placeholder text remains
✅ All TodoWrite tasks marked complete

Step 7: Save File

Target location: infra/application-architecture/components/{component-id}.json

Pre-save checks:

Verify directory infra/application-architecture/components/ exists
If the directory does not exist, create it (including all parent directories) and continue.

Error handling:

If write fails: "Error: Failed to write file. Please check file permissions and try again."

Step 8: Confirm to User and Offer to Continue

✅ Configured [Component Name] successfully!

📄 File location: infra/application-architecture/components/[component-id].json

Azure Service: [Azure Service]
SKU: [SKU]
Region: [Region]

🌐 To view in the UI:
   1. Ensure the Az Infra Harness is running: `npx @zureltd/az-infra-harness`
   2. Refresh your browser
   3. Navigate to the Application Architecture section

Would you like to configure another component? Remaining unconfigured components:
- [Component 2]
- [Component 3]

Say "yes" to continue, or "done" when you've configured all the components you need.

If the user wants to configure another component, return to Step 2 with the updated list.

When all components are configured (none remaining with ⬜ status), display:

The next step is to run /architecture-diagram to generate the architecture diagram for your application.

If the user says "done" but some components are still unconfigured, acknowledge and stop without suggesting the next step.

Error Handling

If application-components.md doesn't exist:

Stop immediately with clear message directing user to run /application-components first

If all components are already configured:

Present the list of configured components
Ask which one to reconfigure: "All components are already configured. Which would you like to update?"

If directory doesn't exist:

Create the directory (including all parent directories) and continue

If user selects an Azure service outside the suggested list:

Accept it — the suggestions are guides, not constraints
Ask for the SKU and settings appropriate to that service

If write fails:

Show clear error with actionable advice

Example Interaction

Agent: "Here are your application components:

API Backend (Compute) — Handles customer authentication, order processing, and business logic ⬜ Not yet configured
Customer Database (Data) — Stores customer profiles and application state ⬜ Not yet configured
Application Gateway (Networking) — Entry point with SSL termination and WAF ⬜ Not yet configured

Which component would you like to configure?"

User: "1"

Agent: "For the API Backend (Compute), which Azure service would you like to use? [Shows Compute options]"

User: "Container Apps"

Agent: "Which pricing tier? Consumption or Dedicated?"

User: "Consumption"

[Conversation continues through region and settings]

Agent: "✅ Configured API Backend successfully!

📄 File location: infra/application-architecture/components/api-backend.json

Would you like to configure another component?"

Reference Files

Sample output: infra/application-architecture/components/api-backend.json
Component list: infra/application-definition/application-components.md
Interaction standard: .opencode/skills/_shared/interaction-validation-standard.md
Documentation: DATA-STRUCTURE.md

Success Criteria

✅ JSON file created at infra/application-architecture/components/{component-id}.json
✅ All required JSON fields are present and correctly typed (azureService, sku, region, settings)
✅ All TodoWrite tasks were used and completed
✅ All validation rules pass
✅ File is valid JSON (parseable)
✅ User is informed of successful creation
✅ UI displays the component configuration after browser refresh
✅ All interaction requirements defined in the Interaction & Validation Standard were satisfied