Infra Kit.workflow.research

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)
2. Identify constraints and evaluation criteria.
3. 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
4. Extract facts:
   • version-specific behavior
   • limits/quotas
   • security implications
   • operational impacts
5. Compare options and produce a recommendation.
6. 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