| 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
- Clarify the research question:
- what decision will this inform
- what environment (cloud, region, k8s distro, versions)
- Identify constraints and evaluation criteria.
- 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
- Extract facts:
- version-specific behavior
- limits/quotas
- security implications
- operational impacts
- Compare options and produce a recommendation.
- 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
