How do I install the Darwin Microservice Patterns skill?

Run npx skillmds@latest add tomevault-io/darwin-microservice-patterns in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Darwin Microservice Patterns safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Darwin Microservice Patterns?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Darwin Microservice Patterns free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Darwin Microservice Patterns?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Darwin Microservice Patterns by tomevault-io

Name: Darwin Microservice Patterns
Author: tomevault-io

Darwin Microservice Patterns

Microservice technical patterns for infrastructure and API design. Use when planning service changes, reviewing API contracts, or evaluating deployment strategies. Use when this capability is needed.

tomevault-io f468915 2 files · 2.7 KB Updated Sep 17, 2026

File contents

Microservice Technical Patterns

Deployment & Independence

Independently deployable: Each service MUST deploy without coordinating with others. If a plan requires simultaneous deployment, redesign with backward-compatible contracts first.
Feature flags over deploy coordination: Use feature flags for progressive enablement rather than synchronized rollouts.

API & Data Contracts

Backward-compatible API changes: Always additive. New fields are optional. Old fields never removed in the same release.
API versioning: If breaking changes are unavoidable, version the API (/v1/, /v2/).
API contracts first: Specify the contract (REST endpoint, event schema) before implementation details.
Database schema independence: Each service owns its data store. No shared databases. Migrations must be backward-compatible.

Resilience

Circuit breakers: Any inter-service call should have timeout + retry + fallback. Flag plans missing resilience patterns.
Idempotency: Any state-modifying operation must be safe to retry. Specify how duplicate calls are handled.
Health endpoints: Every service must expose /health (liveness) and /ready (readiness) with meaningful checks.

Operational Hygiene

Observability: Plans must include how changes will be monitored (metrics, logs, alerts).
Configuration via environment: No hardcoded URLs, credentials, or feature flags in code. Everything via env vars or ConfigMaps.
Stateless services: Flag any in-process state that breaks horizontal scaling (caches without TTL, sessions, in-memory queues). Externalize to Redis/DB.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.

---name: darwin-microservice-patternsdescription: Microservice technical patterns for infrastructure and API design. Use when planning service changes, reviewing API contracts, or evaluating deployment strategies. Use when this capability is needed.---# Microservice Technical Patterns## Deployment & Independence- **Independently deployable**: Each service MUST deploy without coordinating with others. If a plan requires simultaneous deployment, redesign with backward-compatible contracts first.- **Feature flags over deploy coordination**: Use feature flags for progressive enablement rather than synchronized rollouts.## API & Data Contracts- **Backward-compatible API changes**: Always additive. New fields are optional. Old fields never removed in the same release.- **API versioning**: If breaking changes are unavoidable, version the API (`/v1/`, `/v2/`).- **API contracts first**: Specify the contract (REST endpoint, event schema) before implementation details.- **Database schema independence**: Each service owns its data store. No shared databases. Migrations must be backward-compatible.## Resilience- **Circuit breakers**: Any inter-service call should have timeout + retry + fallback. Flag plans missing resilience patterns.- **Idempotency**: Any state-modifying operation must be safe to retry. Specify how duplicate calls are handled.- **Health endpoints**: Every service must expose `/health` (liveness) and `/ready` (readiness) with meaningful checks.## Operational Hygiene- **Observability**: Plans must include how changes will be monitored (metrics, logs, alerts).- **Configuration via environment**: No hardcoded URLs, credentials, or feature flags in code. Everything via env vars or ConfigMaps.- **Stateless services**: Flag any in-process state that breaks horizontal scaling (caches without TTL, sessions, in-memory queues). Externalize to Redis/DB.---> Converted and distributed by [TomeVault](https://tomevault.io/claim/the-darwin-project) — claim your Tome and manage your conversions.

Frequently asked questions