Infrastructure Research

Use this skill when the user asks for recommendations that depend on external documentation or evolving ecosystems: cloud features, Kubernetes APIs, Gateway/Ingress behaviors, Terraform provider attributes, security controls, or industry practices.

The output should be a short, cited research brief plus an experiment/validation plan.

Output Rules

• Always write deliverables to one or more Markdown files in the repo (do not only respond in chat).
• If the research is large, split it into multiple files (e.g., 00-context.md, 01-options.md, 02-recommendation.md, 03-validation-plan.md).
• Prefer a stable location such as docs/infra-research/<topic>/.

Outcomes

• Produce a recommendation with explicit trade-offs and constraints
• Cite primary sources (vendor docs, upstream project docs, RFC/KEP) and record versions/dates
• Identify what is unknown and propose the smallest test to answer it

Where This Fits In The Flow

• Use when the right decision depends on versions, vendor defaults, quotas, or subtle behavior.
• Use to de-risk infra-kit.workflow planning by producing a cited recommendation plus a validation plan.

Workflow

1. Clarify the research question:

• what decision will this inform
• what environment (cloud, region, k8s distro, versions)

1. Identify constraints and evaluation criteria.
2. Gather sources (prefer in this order):

• official vendor documentation
• upstream project docs / release notes
• standards (RFCs) / Kubernetes KEPs when relevant
• high-quality third-party writeups only for context, not as authority

1. Extract facts:

• version-specific behavior
• limits/quotas
• security implications
• operational impacts

1. Compare options and produce a recommendation.
2. Provide a validation plan:

• how to test (PoC steps)
• what success looks like
• what would falsify the recommendation

Source Quality Rules

• Prefer sources that match the user's version and provider.
• Always include links and (when available) the doc version or last-updated date.
• If sources conflict, say so and propose how to resolve (test, issue tracker, release notes).

Hallucination Guardrails

• Do not guess provider/resource arguments or defaults; cite docs.
• Do not present third-party blog content as official behavior.
• If sources cannot be fetched, say so and limit output to what is known.

Research Brief Format

• Question:
• Context (versions, environment):
• Recommendation:
• Key evidence (links):
• Trade-offs:
• Risks:
• Validation plan:
• Open questions:

References