infra-kit-workflow-research

name	infra-kit.workflow.research
description	Research infrastructure topics with source quality, version awareness, and actionable recommendations backed by citations.

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