SkillVaultskills Browse all 500 skills

Infrastructure · Version 1.5.0 · Reviewed 2026-08-02

Service Mesh Adoption Advisor

Review and harden adoption decision and mTLS rollout with evidence, explicit trade-offs, and a verification plan.

4 method steps 4 documented failure modes 4 diagnostic checks 7 quality gates

Decides whether a mesh is justified and sequences adoption around mTLS, traffic policy, and observability.

₹99 one-time

Get this skill archive

What this skill helps you do

  • Adoption decision
  • mTLS rollout
  • Traffic policy design

How Service Mesh Adoption Advisor works

You provide

Manifests, plans, and current runtime topology

It inspects

Reversibility and blast radius for adoption decision

It decides

A mTLS rollout change staged by risk

You verify

Platform-native health check after each stage

What it checks first

Service Mesh Adoption Advisor decides whether a mesh is justified and sequences adoption around mTLS, traffic policy, and observability. Use it when the work involves Adoption decision, mTLS rollout, Traffic policy design.

  1. Whether a change is reversible, and specifically whether it replaces or mutates a stateful resource.
  2. Blast radius: the number of environments, regions, and workloads a change touches at once.
  3. Identity and permission scope of the executing principal.
  4. Drift between declared and actual state.

Failure modes it recognizes

  • An immutable-attribute change forcing replacement of a stateful resource.
  • A change applied to all environments simultaneously with no canary.
  • Over-broad permissions granted to make a deployment succeed and never narrowed.
  • Manual changes creating drift that the next apply silently reverts.

Answers it will reject

  • Approving a plan from summary counts rather than reading the replacement lines.
  • Suppressing drift detection to silence noise, which disables reconciliation.
  • Granting administrative rights as a debugging shortcut.

Decision rules it applies

  • Any stateful replacement requires a tested backup and restore path before approval.
  • Roll out by blast radius: one non-critical target, then one zone, then the fleet.
  • Grant the narrowest permission that completes the task, with an expiry.

Evidence it asks for

  • Diff the plan in machine-readable form and classify every action.
  • Verify the rollback path by executing it in a non-production environment.
  • Confirm post-change health with a platform-native check, not an assumption.

The method inside

  1. Map the artifact, actors, boundaries, and invariants relevant to adoption decision.
  2. Trace concrete failure or abuse paths for mTLS rollout; do not report checklist items without a mechanism.
  3. Prioritize traffic policy design findings by impact, likelihood, confidence, and cost of correction.
  4. Recommend the smallest defensible change, then define how an independent reviewer can verify it.

Deliverables

  • Adoption decision assessment
  • mTLS rollout decision and action plan
  • Traffic policy design verification checklist

Evidence requirements

  • Infrastructure code or configuration
  • Runtime topology and environment constraints
  • Plan, events, policies, and failure symptoms

Quality gates

  • Every material claim traces to supplied evidence or is labeled as a hypothesis.
  • The response follows the declared deliverable contract.
  • No execution, access, measurement, or verification is invented.
  • Secrets and personal data are redacted rather than repeated.
  • The user receives a concrete independent verification step.
  • The relevant failure modes in this domain were considered rather than only the reported symptom.
  • No listed anti-pattern was recommended as a solution.

Example task

Input

Leadership wants a service mesh. We have 12 services and our main problem is inconsistent retry behavior.

Expected output

Twelve services with a retry problem does not justify a mesh, which adds a sidecar, a control plane, and a new failure domain. Standardize retry and timeout policy in a shared client library first, and revisit a mesh when mTLS or per-service policy becomes the binding requirement...

Boundaries and compatibility

Ideal for

  • Adoption decision: produce a decision or artifact grounded in supplied evidence.
  • mTLS rollout: produce a decision or artifact grounded in supplied evidence.
  • Traffic policy design: produce a decision or artifact grounded in supplied evidence.

Out of scope

  • Applying infrastructure changes without approval
  • Assuming cloud access or live resource visibility

Agent compatibility

  • GitHub Copilot custom agents
  • Claude Agent Skills / SKILL.md
  • Any instruction-following chat model

Tool policy: Advisory by default. No tools are assumed. If the host provides tools, use read-only evidence gathering unless the user explicitly approves a scoped write or execution action.