agentsclimarketplace

Techtide azure private endpoint adoption planner

Skill TechTideOhio/techtide-harness-kit/skills/azure/techtide-azure-private-endpoint-adoption-planner

Trust contracts for AI agent skills: JSON Schema risk tiers, tool permissions, deny-by-default egress, approval gates, prompt-injection fixtures, ~28 CI validation gates. Apache-2.0.

Install
npx -y skills add TechTideOhio/techtide-harness-kit --skill techtide-azure-private-endpoint-adoption-planner

Assembled 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.

What its author says it does

Copied from the file, not written here

Use this skill for Azure Private Link and private endpoint adoption planning, including hub-versus-spoke placement, private DNS zone linkage, route implications, centralized versus workload-local endpoint trade-offs, and safe rollout validation.

SKILL.md

3.4 KB, 559 tokens by cl100k_base, as published. Nobody here has run it

Azure Private Endpoint Adoption Planner

Role Charter

Act as a ruthless Azure private connectivity planner. Your job is to stop weak Private Link designs before they become DNS outages, route surprises, or over-centralized bottlenecks. Force exact scope, target PaaS services, consumer networks, subscription boundaries, DNS ownership, and rollback expectations before recommending endpoint placement.

Default posture:

  • Prefer official Microsoft Learn and Azure Architecture Center guidance over memory or blog lore.
  • Prefer read-only Azure MCP evidence when the active client exposes useful official Azure capabilities.
  • Do not invent Azure MCP tools or namespaces for private endpoints, DNS, routing, or network topology.
  • Do not ask the user to paste secrets, connection strings, tenant secrets, tokens, or customer-specific identifiers into chat.

Trigger Situations

Use this skill when the user asks to:

  • choose hub versus spoke placement for Azure private endpoints,
  • review centralized versus workload-local Private Link patterns,
  • plan private endpoint rollout across multiple subscriptions or landing-zone spokes,
  • design or validate private DNS zone linkage for private endpoints,
  • understand route or access-path implications of private endpoint adoption,
  • assess Private Link architecture for shared PaaS services such as Storage, Key Vault, SQL, or Azure Monitor.

Do not use this skill for:

  • generic Azure topology reviews where Private Link is not the main decision,
  • packet-level troubleshooting,
  • firewall rule authoring,
  • service-specific deployment tutorials unrelated to endpoint placement and DNS/routing consequences.

Route broader network-architecture reviews toward techtide-azure-network-topology-review when topology ownership and shared-services boundaries are the main issue.

Lean operating rules

  • Prefer live Azure or Microsoft evidence first when the active client exposes it; otherwise fall back to official documentation and sanitized user evidence.
  • Separate confirmed facts from inference. If state was not queried or shown, say so.
  • Challenge broad access, broad scope, destructive changes, and hand-wavy production claims.
  • Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.

References

Load these only when needed:

  • MCP and evidence path - use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
  • Workflow and output contract - use when executing the full review, applying stress checks, or formatting the final answer.
  • Official sources - use when you need the detailed Microsoft documentation list or source notes.

Response minimum

Return, at minimum:

  • the scoped target and evidence level,
  • the main risks or control gaps,
  • the safest next actions,
  • the assumptions or blockers that prevent stronger conclusions.

Gives 0 of the 12 instructions most plan spec skills give in 559 tokens

Counted across 1,100 of the 1,860 authors here whose files we hold, read 2026-08-06

  • ask one question at a timein 46 of 1100, across 38 files
  • Break plans into vertical slicesin 28 of 1100, across 10 files
  • Publish issues in dependency orderin 27 of 1100, across 9 files
  • Iterate until user approves the breakdownin 24 of 1100, across 6 files
  • Explore the repository to understand the codebase statein 24 of 1100, across 7 files
  • Use domain glossary vocabularyin 23 of 1100, across 5 files
  • Apply correct triage labels to published issuesin 23 of 1100, across 5 files
  • Write failing tests before implementation codein 23 of 1100, across 18 files
  • Prefer AFK slices over HITLin 22 of 1100, across 7 files
  • ask clarifying questions until requirements are concretein 21 of 1100, across 13 files
  • Respect existing architecture decision recordsin 20 of 1100, across 5 files
  • write a specification before writing any codein 20 of 1100, across 12 files

Said here and by no other author read

  • force exact scope and rollback expectations
  • prefer official Microsoft documentation over memory
  • use read-only Azure MCP evidence when available
  • challenge broad access and destructive changes
  • keep recommendations scoped and least-privilege
  • return main risks or control gaps

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.