// Creates Azure Architecture Decision Records (ADRs) with WAF mapping, alternatives, consequences, and implementation guidance; use for architecture decision documentation requests.
| name | azure-adr |
| description | Creates Azure Architecture Decision Records (ADRs) with WAF mapping, alternatives, consequences, and implementation guidance; use for architecture decision documentation requests. |
| compatibility | Works with Claude Code, GitHub Copilot, VS Code, and any Agent Skills compatible tool; no external dependencies required. |
| license | MIT |
| metadata | {"author":"jonathan-vella","version":"1.0","category":"document-creation"} |
Create formal Architecture Decision Records that document significant infrastructure decisions with Azure-specific context, WAF pillar analysis, and implementation guidance.
| Trigger Phrase | Use Case |
|---|---|
| "Create an ADR for..." | Document a specific architectural decision |
| "Document the decision to use..." | Record technology/pattern choice |
| "Record why we chose..." | Capture decision rationale |
| "Architecture decision record for..." | Formal ADR creation |
ADRs are saved to the project's agent-output folder:
agent-output/{project}/
├── 03-des-adr-0001-{short-title}.md # Design phase ADRs
└── 07-ab-adr-0001-{short-title}.md # As-built phase ADRs
03-des-adr- (design) or 07-ab-adr- (as-built)use-sql-database-for-state)# ADR-{NNNN}: {Decision Title}
<details open>
<summary><strong>📑 Decision Contents</strong></summary>
- [🔍 Context](#-context)
- [✅ Decision](#-decision)
- [🔄 Alternatives Considered](#-alternatives-considered)
- [⚖️ Consequences](#%EF%B8%8F-consequences)
- [🏛️ WAF Pillar Analysis](#%EF%B8%8F-waf-pillar-analysis)
- [🔒 Compliance Considerations](#-compliance-considerations)
- [📝 Implementation Notes](#-implementation-notes)
</details>
> Status: Proposed | Accepted | Deprecated | Superseded
> Date: {YYYY-MM-DD}
> Deciders: {team/person}
## 🔍 Context
What is the issue that we're seeing that is motivating this decision or change?
## ✅ Decision
What is the change that we're proposing and/or doing?
## 🔄 Alternatives Considered
| Option | Pros | Cons | WAF Impact |
| -------- | ---- | ---- | ------------------------------ |
| Option A | ... | ... | Security: +, Cost: - |
| Option B | ... | ... | Reliability: +, Performance: + |
## ⚖️ Consequences
### Positive
- List of positive outcomes
### Negative
- List of trade-offs or risks
### Neutral
- List of neutral observations
## 🏛️ WAF Pillar Analysis
| Pillar | Impact | Notes |
| ----------- | ------ | ----- |
| Security | ↑/↓/→ | ... |
| Reliability | ↑/↓/→ | ... |
| Performance | ↑/↓/→ | ... |
| Cost | ↑/↓/→ | ... |
| Operations | ↑/↓/→ | ... |
## 🔒 Compliance Considerations
- List any regulatory or compliance implications
## 📝 Implementation Notes
- Key implementation details or constraints
---
<div align="center">
| ⬅️ [Previous ADR](.) | 🏠 [Project Index](README.md) | ➡️ [Next ADR](.) |
| -------------------- | ----------------------------- | ---------------- |
</div>
Create an ADR documenting our decision to use Azure SQL Database
instead of Azure Cosmos DB for the e-commerce catalog service.
Consider WAF implications and cost trade-offs.
Document the architectural decision we made during implementation
to use Azure Front Door instead of Application Gateway.
Include the performance testing results that informed this choice.
Use the azure-adr skill to document the database decision from
the architecture assessment above as a formal ADR.
| Step | Context | ADR Type |
|---|---|---|
| Step 2 (Architect) | After WAF assessment | Design ADR (03-des-adr-*) |
| Step 5 (Bicep Code) | After implementation choices | As-built ADR (07-ab-adr-*) |
| Step 6 (Deploy) | After deployment decisions | As-built ADR (07-ab-adr-*) |
| Category | Example Decisions |
|---|---|
| Compute | AKS vs App Service, Container Apps vs Functions |
| Data | SQL Database vs Cosmos DB, Redis vs Table Storage |
| Networking | Hub-spoke vs flat, Private Link vs Service Endpoints |
| Security | Managed Identity vs SPN, Key Vault vs App Config |
| Integration | Event Grid vs Service Bus, API Management tiers |
azure-diagrams skill)deploy agent)bicep-plan agent)This skill produces artifacts in Step 3 (design) or Step 7 (as-built).
| Workflow Step | ADR Prefix | Status Default | Purpose |
|---|---|---|---|
| Step 3 (Design) | 03-des-adr- | Proposed | Document decisions before build |
| Step 7 (As-Built) | 07-ab-adr- | Accepted | Document implemented decisions |
03-des-adr- prefix07-ab-adr- prefix03-des-adr-07-ab-adr-Important: The 07-ab-adr- ADR may differ from 03-des-adr- if implementation required changes.
Document any deviations in the "Implementation Notes" section.
Follow these steps when creating ADRs:
agent-output/{project}/ for next sequence03-des-) or As-Built (07-ab-) based on contextBefore finalizing the ADR, verify:
{step}-adr-NNNN-{title-slug}.md)agent-output/{project}/03-des-adr-* or 07-ab-adr-*)| Anti-Pattern | Problem | Solution |
|---|---|---|
| Vague decision statements | "We decided to use a database" lacks specificity | State exact technology: "Use Azure SQL Database with geo-replication" |
| Missing alternatives | No record of other options considered | Document at least 2-3 alternatives with rejection rationale |
| One-sided consequences | Only listing positives | Include both positive AND negative consequences |
| Incomplete context | Decision without background | Explain the problem, constraints, and forces at play |
| Generic implementation notes | "Deploy to Azure" | Provide specific, actionable steps with commands/configs |
| Missing WAF alignment | No framework reference | Document which WAF pillars are affected and how |
Defines canonical artifact templates, H2 structures, and documentation styling rules for agent outputs (Steps 1-7); use for artifact generation, formatting, and template compliance.
Provides Azure defaults for naming, regions, tags, AVM-first modules, security baselines, WAF criteria, governance discovery, and pricing guidance across all agents.
Azure resource troubleshooting patterns including KQL templates, metric thresholds, health checks, and remediation playbooks. Use when diagnosing unhealthy Azure resources or building diagnostic workflows.
Maintains repository documentation accuracy and freshness; use for doc updates, agent or skill changes, staleness checks, changelog entries, and repo explanation requests.
Handles GitHub issues, pull requests, repositories, Actions, releases, and API tasks using MCP-first workflows with gh CLI fallback for advanced operations.
HackOps platform business rules, role matrix, lifecycle states, and scoring invariants. Use when building API routes, writing tests, or validating business logic for the HackOps hackathon management platform. Keywords: hackathon, team, coach, hacker, admin, rubric, scoring, leaderboard, event code, progression.