Architecture microservices
Skill planifest/planifest-framework/planifest-framework/external-skills/architecture-microservices
Microservices architecture workflow for service boundary design, independent deployability, and distributed operational safety. Use when domain and team structure justify independent service evolution; do not use as a default scaling strategy for all systems.From its SKILL.md
npx -y skills add planifest/planifest-framework --skill architecture-microservicesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.3 KB, 356 tokens by cl100k_base, as published. Nobody here has run it
Architecture Microservices
Overview
Use this skill to design microservice architectures that trade monolithic simplicity for bounded autonomy intentionally.
Scope Boundaries
- Different domain areas change at different speeds and require independent release cadence.
- Team autonomy and ownership boundaries are blocked by shared code/runtime coupling.
- Operational platform maturity exists to absorb distributed-system overhead.
Core Judgments
- Service boundary: domain capability, data ownership, and team ownership alignment.
- Integration model: synchronous calls, events, or hybrid by invariant type.
- Consistency strategy: local transactions plus saga/compensation where needed.
- Operational budget: observability, incident response, platform engineering capacity.
Practitioner Heuristics
- Split services by business capability and change cadence, not by technical layer.
- One service owns its data model; cross-service joins in request path are a smell.
- Start with fewer coarse services, then split where pain is observed.
- Define service contracts with explicit schema types; avoid generic untyped payloads that drive cast-heavy consumers.
Workflow
- Identify candidate service boundaries from domain and ownership signals.
- Evaluate coupling and consistency needs across candidate boundaries.
- Choose integration patterns per interaction type.
- Define contract and data ownership rules, including versioning strategy.
- Estimate operational overhead and staffing implications.
- Document migration path from current architecture.
Common Failure Modes
- Premature decomposition creates chatty synchronous dependencies.
- Shared utility libraries become hidden coupling channel.
- Service count grows faster than team ownership maturity.
Failure Conditions
- Stop when service boundaries cannot be mapped to stable ownership.
- Stop when end-to-end reliability depends on fragile RPC chains.
- Escalate when platform and operations readiness is insufficient for distributed complexity.
What ships with it: 1 file
11.3 KB alongside SKILL.md
- attribution.txt11.3 KB