sxsphinxstack

Skills / Starter / Document a service dependency

Starter Code skill

Document a service dependency

Document a service dependency's contract, ownership, limits, failure behavior, observability, and recovery path.

Make the dependency visible enough to design, operate, and recover the calling service honestly.

Procedure

  1. Name the consumer outcome, provider, owner, criticality, and environments.
  2. Record endpoints, authentication, data classes, versions, quotas, and supported operations.
  3. Define latency, availability, consistency, ordering, and freshness assumptions.
  4. Describe timeout, retry, idempotency, circuit, cache, and fallback behavior.
  5. Map monitoring, status, support, escalation, maintenance, and change-notice channels.
  6. Record geographic, security, privacy, compliance, cost, and concentration constraints.
  7. Rehearse slow, unavailable, incorrect, stale, and partially recovered states.
  8. Publish a dependency record with review date, evidence links, and exit owner.

Guardrails

  • Do not copy credentials or sensitive contract terms into broad documentation.
  • Provider uptime does not prove the consumer journey works.
  • Avoid a fallback that silently returns incorrect or unsafe data.

Related skills

  • Define alert severity — Define alert severity from user impact, urgency, scope, reversibility, and required authority.
  • Document an environment variable — Document an environment variable as a configuration contract with purpose, type, default, scope, secrecy, validation, and failure behavior.
  • Decode a jwt safely — Decode a JWT without confusing readable claims with verified identity or authorization.