How I used Kiro powers to bridge my cloud platform knowledge gap
Quick Start: Just Try It
Want to skip the story and experiment with power?
Open Kiro IDE → Powers panel → Add power from GitHub → Enter the URL for the power you want:
| Power | URL |
|---|---|
| azure-architect | https://github.com/requix/azure-kiro-powers/tree/main/azure-architect |
| azure-operations | https://github.com/requix/azure-kiro-powers/tree/main/azure-operations |
| azure-monitoring | https://github.com/requix/azure-kiro-powers/tree/main/azure-monitoring |
Click Install.
⚠️ Before installing: These are third-party powers, not official Kiro or Microsoft tools. Review the repository and code before installing.
No authentication needed for azure-architect. Start with: "What are the best practices for Azure storage account security?"
Have fun.
If you're interested in building Kiro powers yourself, the rest of this post walks through the development process, design decisions, and what I learned.
The Context
You never know what the next project brings you.
I'm an AWS cloud architect. Have been for years. Then I joined a project running entirely on Azure. Different services, different naming conventions, same deadline pressure.
Here's the irony: I reached for Kiro - an AWS IDE - to help me learn Azure. An AWS architect using an AWS tool to work with Microsoft's cloud. The cloud world is strange sometimes.
But it made sense. I didn't have months to follow the classic learning path - certifications, documentation deep-dives, sandbox experiments. I needed to ship. I needed Azure knowledge in context, at the moment of need, without constantly switching between documentation tabs and my development environment.
So I built first, learned along the way. Three Kiro powers for Azure. Each design choice taught me how Azure actually works.
What Kiro Powers Are
Powers are Kiro's extension system. They solve two problems that traditional MCP setups create:
Without framework context, agents guess. Your agent can call Azure APIs, but does it know the right patterns? Without built-in expertise, you're both manually reading documentation and refining approaches until the output is right.
With too much context, agents slow down. Connect five MCP servers and your agent loads 100+ tool definitions before writing a single line of code. Five servers might consume 50,000+ tokens - 40% of your context window - before your first prompt. More tools should mean better results, but unstructured context overwhelms the agent.
Powers fix this through dynamic loading. Instead of loading all MCP tools at once, powers activate based on keywords in your conversation. Mention "Azure architecture" and the azure-architect power loads. Switch to deployment topics and azure-operations activates.
A power consists of:
-
POWER.md- Required. Contains frontmatter (metadata, keywords for activation) and instructions (onboarding steps, steering guidance) -
mcp.json- Optional. MCP server configuration for tool integrations -
steering/- Optional. Workflow-specific guidance files -
hooks/- Optional. Automated tasks that run on IDE events or via slash commands
My Azure powers use the first three. Hooks are useful for validation workflows or automated setup tasks - something to explore in future iterations.
Three Powers, Not One: The Design Decision
The official Azure MCP Server has dozens of namespaces. Loading everything at once would defeat the purpose of powers - you'd be back to context overload.
I split it into three powers based on workflow phases:
┌─────────────────┐ ┌──────────────────┐ ┌───────────────────┐
│ azure-architect │ ──▶ │ azure-operations │ ──▶ │ azure-monitoring │
│ │ │ │ │ │
│ "Design it" │ │ "Build & run it" │ │ "Watch & fix it" │
│ Design tools │ │ Resource mgmt │ │ Observability │
└─────────────────┘ └──────────────────┘ └───────────────────┘
azure-architect: Best practices, architecture guidance, documentation search, schema references. Design-time namespaces only.
azure-operations: Storage, databases, RBAC, Key Vault, AKS management. Resource management namespaces.
azure-monitoring: Log Analytics, metrics, alerts, resource health. Observability namespaces.
The primary benefit is focus. Each power loads only the tools relevant to that workflow phase. When you're designing infrastructure, you don't need monitoring tools consuming context. When you're debugging production, you don't need architecture best practices.
When you install all three powers, Kiro automatically selects the right one based on your request. Ask about Azure best practices, it uses architect. Query storage accounts, it switches to operations. Check resource health, it activates monitoring.
A secondary benefit is authentication separation. The architect power works without az login - useful for design work on a fresh machine. The operations and monitoring powers require authentication, with monitoring limited to read-only namespaces.
⚠️ Note on permissions: Your Azure permissions come from
az login. If you authenticate with write access, that access exists regardless of which power is active. The powers organize workflows; your Azure RBAC controls what's actually permitted.
Building azure-architect: The MCP Configuration
The mcp.json file defines which MCP servers and namespaces a power uses:
{
"mcpServers": {
"microsoft-docs": {
"type": "http",
"url": "https://learn.microsoft.com/api/mcp"
},
"azure-mcp": {
"command": "npx",
"args": [
"-y",
"@azure/mcp@latest",
"server",
"start",
"--namespace", "documentation",
"--namespace", "bicepschema",
"--namespace", "cloudarchitect",
"--namespace", "bestpractices"
],
"env": {
"AZURE_MCP_COLLECT_TELEMETRY": "false"
}
}
}
}
Two MCP servers. Microsoft Learn for documentation search. Azure MCP for design tools.
The --namespace flags are where token efficiency happens. Without them, the Azure MCP server loads all namespaces. By specifying only design-time namespaces, this power stays focused - loading exactly what's needed for architecture work, nothing more.
Steering Files: Teaching Kiro How to Think
MCP connections give Kiro access to tools. Steering files teach it when and how to use them.
Here's a section from the naming conventions steering file:
## Azure Resource Naming Pattern
{resource-type}-{workload}-{environment}-{region}-{instance}
Examples:
- st-payments-prod-westeu-001 (storage account)
- kv-payments-prod-westeu-001 (key vault)
- aks-payments-prod-westeu-001 (kubernetes cluster)
When user asks to create a resource:
1. Ask for workload name if not provided
2. Infer environment from context or ask
3. Apply naming pattern automatically
This isn't just reference material. It's encoded behavior. When I ask Kiro to create a storage account, it doesn't just generate code - it asks clarifying questions and applies the naming pattern automatically.
The steering files also include ready-to-use patterns. From the KQL patterns file:
// Error Rate Calculation
AppServiceHTTPLogs
| where TimeGenerated > ago(1h)
| summarize
TotalRequests = count(),
ErrorCount = countif(ScStatus >= 500),
ErrorRate = round(countif(ScStatus >= 500) * 100.0 / count(), 2)
// Response Time Percentiles
AppServiceHTTPLogs
| where TimeGenerated > ago(6h)
| summarize
p50 = percentile(TimeTaken, 50),
p95 = percentile(TimeTaken, 95),
p99 = percentile(TimeTaken, 99)
by bin(TimeGenerated, 15m)
These aren't just examples. They're templates Kiro adapts to specific queries. When I ask "show me slow requests from the last hour," Kiro modifies the percentile pattern with my timeframe.
Real Usage: What Actually Gets Used
After completing an IaC authoring task with the azure-architect power, I asked Kiro to analyze its own tool usage. Here's the honest breakdown:
| Tool | Used | Value |
|---|---|---|
microsoft_docs_search |
✅ | High - Found exact configuration patterns and integration details |
get_azure_bestpractices |
✅ | Medium - General Azure coding guidelines |
azureterraformbestpractices |
✅ | Medium - Validation workflow patterns |
bicepschema |
✅ | Discovered it exists, didn't use for this task |
The verdict from Kiro: "Documentation search was the killer feature. Worth having for the documentation search alone."
What made the documentation search valuable wasn't generic information - it was concrete implementation details: exact API endpoint formats, available metrics and thresholds, configuration patterns for specific integrations.
The best practices tools confirmed patterns but didn't provide service-specific guidance. Moderately useful, not transformative.
What this reveals about the three-power design:
Kiro noted that operational tools (subscription queries, live resource inspection) weren't needed for this IaC authoring task. Those capabilities "would shine more in a 'diagnose my existing infrastructure' scenario rather than 'author new IaC.'"
This is exactly why the powers are separated. The architect power handles design-time work with minimal context overhead. The operations and monitoring powers exist for when you need to interact with live resources.
Different workflows. Different tools. Focused context.
Security Steering: Making Best Practices Unavoidable
The azure-operations power includes security guidelines that encode least privilege into every workflow:
## Least Privilege Patterns
### Pattern 1: Application Access to Storage
**Instead of:** Contributor role on storage account
**Use:** Storage Blob Data Contributor on specific container
### Pattern 2: Application Access to Key Vault
**Instead of:** Key Vault Contributor
**Use:** Key Vault Secrets User (read-only) or Key Vault Secrets Officer (read/write)
### Pattern 3: CI/CD Pipeline Access
**Instead of:** Contributor on subscription
**Use:** Contributor on specific resource groups + specific data plane roles
When I ask about access management, Kiro frames answers in terms of principals, definitions, and scopes. The steering file made it harder to give overly permissive advice.
The Development Process: Using Kiro to Build Kiro Powers
Here's the meta part: I used Kiro to build these powers.
The Kiro team maintains a power-builder power specifically for creating new powers. Install it, and Kiro becomes your power development assistant.
Spec Mode for Requirements
Kiro's Spec mode generates structured plans from descriptions. I described what I wanted - three workflow-aligned powers with namespace separation - and Spec mode produced:
- Requirements documents for each power
- File structure recommendations
- Task lists for implementation
The Iteration Loop
- Define MCP configuration - Which namespaces to include
- Write steering files - Patterns, workflows, decision trees
- Install power locally - Powers panel → Add power from Local Path
- Test with real queries - "List my storage accounts"
- Check tool availability - Verify expected tools load
- Refine based on gaps - Fix tool names, add missing patterns
Step 5 caught several issues. The Azure MCP uses azmcp_ prefixes for tool names. My early documentation referenced incorrect names. Testing revealed the mismatch.
Local Installation
Installing during development:
- Open Kiro's Powers panel
- Click Add power from Local Path
- Select the power directory containing
POWER.md - Click Install
No build step. No packaging. Direct folder reference. Change a steering file, reload the power, test immediately.
Once ready, push to a public GitHub repository and others can install via Add power from GitHub using the URL to the specific power folder.
What Actually Matters
Powers aren't just a packaging format. They're a model for how AI agents should acquire expertise.
The old approach: stuff everything into context upfront. Hope the agent figures out what's relevant. Watch token costs climb while response quality drops.
The new approach: agents learn what they need, when they need it. Expertise flows in on demand. Context stays focused. The agent expands its capabilities as the tools around it evolve.
This matters beyond my Azure learning curve. HashiCorp built their Terraform power in days after learning about the format. Stripe, Supabase, Datadog - all shipping domain expertise as installable packages. The pattern scales.
For tool providers: Write one POWER.md, and your expertise reaches every developer using powers. No maintaining separate integrations for each AI tool.
For teams: Package internal knowledge - your design system, your deployment patterns, your security policies - as powers. Every developer's agent knows how to use them correctly.
For individuals: Install the expertise you need today. Uninstall when you're done. Your agent's capabilities match your current project, not some generic average.
This is what separates useful AI assistance from the "chat with docs" experience. Not just answering questions. Bringing the right context at the right moment, then getting out of the way.
Documentation teaches concepts. Powers teach workflows. The difference is action.
The Future: Cross-Tool Compatibility
Today, powers work in Kiro IDE. The team is building toward a future where powers work across any AI development tool - Kiro CLI, Cursor, Claude Code, and beyond.
The Model Context Protocol provides a standard for tool communication. Powers extend this with standards for packaging, activation, and knowledge transfer.
This matters for the ecosystem. Tool providers don't want to maintain separate integrations for each AI tool. Write one POWER.md, use it anywhere.
I'm particularly interested in Kiro CLI support. Running these powers from a terminal would match my actual workflow better than the IDE interface.
Tradeoffs
Cognitive Distance from the Platform
Using powers means interacting with Azure through an abstraction layer. For learning fundamentals, this might hide important details.
MCP Server Dependency
These powers depend on Microsoft maintaining the Azure MCP Server. Version updates have already changed tool naming conventions, requiring documentation updates across all three powers.
Steering File Maintenance
Steering files encode current best practices. Azure evolves. The files need periodic updates to stay relevant.
What I'd Change
Better Tool Discovery
You need to know what tools exist to use them effectively. A more systematic discovery mechanism would help - something that surfaces available capabilities based on what you're trying to accomplish.
Add Hooks for Validation
The powers currently don't use hooks. Adding automated validation, like checking Terraform syntax before deployment or verifying RBAC configurations, would make the workflow tighter.
What I Learned
Building these powers taught me things that reading documentation wouldn't have:
About Azure: Working with the MCP namespaces forced me to understand how Azure organizes its services. The separation between control plane and data plane operations became obvious when I had to decide which namespaces each power needed. You learn a platform's structure by building tools for it.
About Powers: The format is more accessible than I expected.
My three Azure powers took a weekend of focused work. The barrier isn't technical complexity - it's knowing what workflows to optimize for.
About Context Efficiency: Before this project, I would have connected every MCP server and hoped for the best. Now I think in terms of focused context. What does this specific task need? What's consuming tokens without adding value?
About Learning Paths: Sometimes building tools is the learning path. The classic route - docs, tutorials, certifications - works when you have time. When you don't, building forces understanding faster. Every decision about what to include in a power required me to understand what Azure actually offers.
The unexpected part: an AWS architect, using an AWS IDE, building Azure tooling. But that's the point of powers. They're platform-agnostic expertise packages. The tool doesn't care which cloud you're learning. It just loads the right context when you need it.
Try It
Repository: github.com/requix/azure-kiro-powers
Each power installs independently. Start with azure-architect - no authentication required.
Building AI-powered development tools? The interesting work happens at the edges, where people try things.
Your move.
Top comments (0)