Perform an Azure Well-Architected Framework review of the current workload IaC and architecture, generating findings and GitHub issues for improvements.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
This workflow performs a structured Azure Well-Architected Framework (WAF) review against your workload's IaC files and deployed infrastructure. It identifies risks across all 5 WAF pillars and creates GitHub issues to track remediation.
az) configured and authenticatedFetch current Azure WAF best practices:
https://learn.microsoft.com/en-us/azure/well-architected/https://learn.microsoft.com/en-us/azure/well-architected/service-guides/)If the microsoft.docs.mcp MCP server is available, use it to query the latest pillar checklists and service-specific recommendations.
Establish the review scope, then inventory both the code and the live environment:
**/*.bicep, bicepconfig.json**/*.tf (azurerm/azapi providers)**/azuredeploy*.json, **/*.template.json, files with $schema containing deploymentTemplateaz resource list --resource-group <rg> --output json (or subscription-wide), plus targeted az <service> show calls for configuration details the pillar checks need.Identify key Azure services in use (compute, data, networking, security, observability) and generate a Mermaid architecture diagram.
* → * allow rules)minimumTlsVersion, httpsOnly)az security pricing list)az consumption budget list)For each finding, classify:
🏗️ Azure Well-Architected Review Summary
📊 Review Results:
• IaC Files Analyzed: X
• Azure Services Identified: Y
• Total Findings: Z
• High Risk: A (immediate action required)
• Medium Risk: B (should address soon)
• Low Risk: C (nice to have)
🔴 Top High Risk Findings:
1. [Pillar]: [Finding] — [Why it matters]
2. [Pillar]: [Finding] — [Why it matters]
💡 This will create Z individual GitHub issues + 1 EPIC issue.
❓ Proceed with creating GitHub issues? (y/n)
Gate: Only proceed to Steps 6–7 if the user gives an explicit affirmative response (e.g. "y", "yes"). On a negative, ambiguous, or missing response, do not create any GitHub issues — output the full findings as formatted markdown to the console and stop.
Label with "well-architected" and the pillar name (e.g., "security", "reliability").
Title: [WAF-<PILLAR>] [Brief Finding] — [Risk Level]
Body:
## 🏗️ Well-Architected Finding: [Brief Title]
**Pillar**: [Name] | **Risk Level**: [High/Medium/Low] | **Effort**: [Low/Medium/High]
### 📋 Description
[Clear explanation of the finding and why it matters]
### 🔧 Remediation
**IaC Fix** (preferred):
```bicep
// Bicep example
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
name: storageAccountName
location: location
sku: { name: 'Standard_ZRS' }
kind: 'StorageV2'
properties: {
minimumTlsVersion: 'TLS1_2'
allowBlobPublicAccess: false
supportsHttpsTrafficOnly: true
}
}
```
**Azure CLI fallback**:
```bash
az storage account update --name <name> --resource-group <rg> \
--min-tls-version TLS1_2 --allow-blob-public-access false --https-only true
```
### 📚 Azure Reference
- [WAF Best Practice Link]
- [Microsoft Learn Documentation Link]
### ✅ Validation
- [ ] Change implemented in IaC and deployed
- [ ] Azure Policy compliance passes (if applicable)
- [ ] Microsoft Defender for Cloud recommendation resolved (if applicable)
**Well-Architected Recommendation**: [WAF checklist item this maps to]
Label with "well-architected" and "epic".
Title: [EPIC] Azure Well-Architected Review — X findings across 5 pillars
Body: Executive summary with pillar breakdown table (finding counts by pillar and risk level), Mermaid architecture diagram, prioritized checklist linking all individual issues (High → Medium → Low), and success criteria:
az resource list) and note the gapまだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Use this skill when the user explicitly asks to map, document, or onboard into an existing codebase. Trigger for prompts like "map this codebase", "document this architecture", "onboard me to this repo", or "create codebase docs". Do not trigger for routine feature implementation, bug fixes, or narrow code edits unless the user asks for repository-level discovery.
日本語の概要は準備中です。原文の説明を表示しています。
Run the AgentRC readiness assessment on the current repository and produce a static HTML dashboard at reports/index.html. Wraps `npx github:microsoft/agentrc readiness` and hands off rendering to the @ai-readiness-reporter custom agent. Supports policies (--policy) for org-specific scoring. Use when asked to assess, audit, or score the AI readiness of a repo.
日本語の概要は準備中です。原文の説明を表示しています。
Generate tailored AI agent instruction files via AgentRC instructions command. Produces .github/copilot-instructions.md (default, recommended for Copilot in VS Code) plus optional per-area .instructions.md files with applyTo globs for monorepos. Use after running /acreadiness-assess to close gaps in the AI Tooling pillar.
日本語の概要は準備中です。原文の説明を表示しています。
Help the user pick, write, or apply an AgentRC policy. Policies customise readiness scoring by disabling irrelevant checks, overriding impact/level, setting pass-rate thresholds, or chaining org baselines with team overrides. Use when the user asks about strict mode, AI-only scoring, custom weights, CI gating, or wants org-wide standardisation.
日本語の概要は準備中です。原文の説明を表示しています。
Use this skill when the user shares ad campaign performance data and asks what to cut, scale, or test. Trigger for prompts like "analyze my ad campaigns", "where am I wasting ad spend", "reallocate my ad budget", "which ads are actually working", or "ROAS analysis". Do not trigger for campaign planning or creative generation without performance data.
日本語の概要は準備中です。原文の説明を表示しています。
Add educational comments to the file specified, or prompt asking for file to comment if one is not provided.
日本語の概要は準備中です。原文の説明を表示しています。