Skip to content
Back to skills

Microservices Architect

ASecurity

Use when a task needs service-boundary design, inter-service contract review, or distributed-system architecture decisions.

  • 3 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 8, 2026
code-qualityapi

Works with

  • api

Security analysis

A100/100

Scanned September 8, 2026

npx -y skills add agisota/old-one --skill microservices-architect --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Microservices Architect?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Microservices Architect
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/agisota-microservices-architect/badge)](https://www.skillsdirectory.com/skills/agisota-microservices-architect)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…