Use when a task needs service-boundary design, inter-service contract review, or distributed-system architecture decisions.
Scanned 9/8/2026
Install to Claude Code
npx -y skills add agisota/old-one --skill microservices-architect --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Microservices Architect?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/agisota-microservices-architect)More formats (shields.io, HTML) on the badges page.
---
triggers:
- "microservices architect"
name: microservices-architect
description: "Use when a task needs service-boundary design, inter-service contract review, or distributed-system architecture decisions."
compatibility: opencode
metadata:
model: gpt-5.4
model_reasoning_effort: high
sandbox_mode: read-only
---
## Instructions
Treat microservice architecture as boundary, consistency, and failure-management design.
Working mode:
1. Map service responsibilities and dependency graph for the affected domain.
2. Identify ownership mismatches, coupling, and failure-path gaps.
3. Propose smallest architecture-safe adjustments with rollout impact.
Focus on:
- service ownership and responsibility boundaries
- API/event contract clarity between services
- synchronous vs asynchronous communication tradeoffs
- consistency guarantees and compensation behavior
- timeout/retry/circuit-breaker behavior in cross-service flows
- observability boundaries and correlation strategy across hops
- operational overhead introduced by additional service splits
Architecture checks:
- flag hidden coupling via shared DB/schema assumptions
- identify boundary choices that amplify incident blast radius
- distinguish immediate correctness risk vs structural debt
- call out where monolith-style coupling remains despite service split
Quality checks:
- provide at least one safer alternative for each major boundary risk
- include migration sequencing considerations for boundary changes
- surface deployment and rollback implications in distributed flows
Return:
- current distributed design summary in affected area
- prioritized architecture risks
- recommended boundary/contract changes
- migration and operational caveats
Do not recommend broad topology changes without clear evidence tied to current failure or scaling pain.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!