Infra Kit
Use this skill to run a repeatable workflow from an incoming ticket (Jira/GitHub/Slack/Email) to:
- a clear problem statement and acceptance criteria
- an implementation plan with rollout/rollback and verification
- an executable task list
- implementation notes and a copy/paste Confluence summary
This framework focuses on infra delivery artifacts that are easy to review and operate.
For the end-to-end mapping across skills, see docs/infras-kit/flow.md.
Output Rules
- Write the deliverables to Markdown files in the repo (not only chat output).
- Prefer
docs/infras-kit/work-items/<id>-<slug>/.
- Keep docs skimmable. Push deep details into
implementation-notes.md.
Quick Start
- Create a work-item directory and starter files:
bash infras-kit-plugin/skills/infra-kit.workflow/scripts/new-work-item.sh "<short title>" \
--id "<TICKET-ID>" \
--link "<ticket url>"
- Fill in
ticket.md, then generate plan.md and tasks.md.
- Execute tasks, using domain skills for the actual work:
- use
infra-kit.domain.iac for Terraform/Terragrunt changes
- use
infra-kit.domain.helm for chart work
- use
infra-kit.domain.k8s-doctor for runtime debugging
- use
infra-kit.domain.github for repo and CI/CD changes
- use
infra-kit.workflow.verify to record verification evidence and “definition of done”
- use
infra-kit.workflow.review to prepare PRs and handle review feedback
- use
infra-kit.workflow.audit to review before merge/release
Note: skill names were renamed. Use infra-kit.workflow.* for workflow skills and infra-kit.domain.* for domain skills.
Workflow
This workflow is intentionally iterative. If you discover new unknowns mid-way, add them as
[NEEDS CLARIFICATION: ...], loop back, and update the upstream artifact instead of guessing.
- Intake (ticket.md)
- restate the problem and intended outcome
- list acceptance criteria and explicit non-goals
- capture constraints (cloud, regions, compliance, timelines)
- label unknowns as
[NEEDS CLARIFICATION: ...]
- gate:
- if any
[NEEDS CLARIFICATION] remain, ask targeted questions and stop
- Spec (spec.md)
- translate ticket into an infra-focused spec: desired behavior, SLO/SLA impact, security boundaries
- define “done” in testable terms
- carry forward unknowns; do not “resolve” by guessing
- gate:
- if any
[NEEDS CLARIFICATION] remain, ask targeted questions and stop
- Plan (plan.md)
- approach, risks, dependencies
- rollout steps and explicit rollback
- verification commands and expected signals
- operational ownership: alerts/runbooks, cost notes
- gate:
- if any
[NEEDS CLARIFICATION] remain, ask targeted questions and stop
- Tasks (tasks.md)
- produce a checklist with small steps
- tag each task with the intended skill (e.g.,
[infra-kit.domain.iac], [infra-kit.domain.helm])
- mark parallelizable tasks with
[P]
- include a short readiness check:
- are tasks unblocked, verifiable, and do they map back to acceptance criteria?
- Implement (implementation-notes.md)
- record what changed, gotchas, and final verification outputs
- Report (confluence.md)
- write a concise update suitable for Confluence/Jira comment
Interaction Pattern (Make It Less Step-By-Step)
At the end of each phase, always do these two things in chat:
- State the single best next step (one action, not a menu).
- List what input is required to proceed (questions or required confirmations).
If the user explicitly wants an exploratory spike, allow proceeding with labeled assumptions:
- Mark them as
[ASSUMPTION: ...] and keep them in the doc so they can be revisited.
- Still prefer the smallest test to validate assumptions early.
Guardrails
- Don’t invent requirements. Ask when unknown.
- Don’t propose destructive rollouts without a rollback.
- Keep “plan” separate from “implementation”; avoid code dumps in
plan.md.
- If you must proceed with uncertainty, label it as
[ASSUMPTION: ...].
- Don’t stage/commit generated docs unless the user explicitly asks.
Template Locations
docs/infras-kit/work-items/<id>-<slug>/ticket.md
docs/infras-kit/work-items/<id>-<slug>/spec.md
docs/infras-kit/work-items/<id>-<slug>/plan.md
docs/infras-kit/work-items/<id>-<slug>/tasks.md
docs/infras-kit/work-items/<id>-<slug>/implementation-notes.md
docs/infras-kit/work-items/<id>-<slug>/confluence.md
1---2name: infra-kit-workflow3description: Turn an infra ticket into a lightweight spec, implementation plan, task list, and implementation notes (with optional Confluence-ready output).4---56# Infra Kit78Use this skill to run a repeatable workflow from an incoming ticket (Jira/GitHub/Slack/Email) to:910- a clear problem statement and acceptance criteria11- an implementation plan with rollout/rollback and verification12- an executable task list13- implementation notes and a copy/paste Confluence summary1415This framework focuses on infra delivery artifacts that are easy to review and operate.1617For the end-to-end mapping across skills, see `docs/infras-kit/flow.md`.1819## Output Rules2021- Write the deliverables to Markdown files in the repo (not only chat output).22- Prefer `docs/infras-kit/work-items/<id>-<slug>/`.23- Keep docs skimmable. Push deep details into `implementation-notes.md`.2425## Quick Start26271. Create a work-item directory and starter files:2829```bash30bash infras-kit-plugin/skills/infra-kit.workflow/scripts/new-work-item.sh "<short title>" \31 --id "<TICKET-ID>" \32 --link "<ticket url>"33```34352. Fill in `ticket.md`, then generate `plan.md` and `tasks.md`.363. Execute tasks, using domain skills for the actual work:3738- use `infra-kit.domain.iac` for Terraform/Terragrunt changes39- use `infra-kit.domain.helm` for chart work40- use `infra-kit.domain.k8s-doctor` for runtime debugging41- use `infra-kit.domain.github` for repo and CI/CD changes42- use `infra-kit.workflow.verify` to record verification evidence and “definition of done”43- use `infra-kit.workflow.review` to prepare PRs and handle review feedback44- use `infra-kit.workflow.audit` to review before merge/release4546Note: skill names were renamed. Use `infra-kit.workflow.*` for workflow skills and `infra-kit.domain.*` for domain skills.4748## Workflow4950This workflow is intentionally iterative. If you discover new unknowns mid-way, add them as51`[NEEDS CLARIFICATION: ...]`, loop back, and update the upstream artifact instead of guessing.52531. **Intake (ticket.md)**54 - restate the problem and intended outcome55 - list acceptance criteria and explicit non-goals56 - capture constraints (cloud, regions, compliance, timelines)57 - label unknowns as `[NEEDS CLARIFICATION: ...]`58 - gate:59 - if any `[NEEDS CLARIFICATION]` remain, ask targeted questions and stop602. **Spec (spec.md)**61 - translate ticket into an infra-focused spec: desired behavior, SLO/SLA impact, security boundaries62 - define “done” in testable terms63 - carry forward unknowns; do not “resolve” by guessing64 - gate:65 - if any `[NEEDS CLARIFICATION]` remain, ask targeted questions and stop663. **Plan (plan.md)**67 - approach, risks, dependencies68 - rollout steps and explicit rollback69 - verification commands and expected signals70 - operational ownership: alerts/runbooks, cost notes71 - gate:72 - if any `[NEEDS CLARIFICATION]` remain, ask targeted questions and stop734. **Tasks (tasks.md)**74 - produce a checklist with small steps75 - tag each task with the intended skill (e.g., `[infra-kit.domain.iac]`, `[infra-kit.domain.helm]`)76 - mark parallelizable tasks with `[P]`77 - include a short readiness check:78 - are tasks unblocked, verifiable, and do they map back to acceptance criteria?795. **Implement (implementation-notes.md)**80 - record what changed, gotchas, and final verification outputs816. **Report (confluence.md)**82 - write a concise update suitable for Confluence/Jira comment8384## Interaction Pattern (Make It Less Step-By-Step)8586At the end of each phase, always do these two things in chat:87881. **State the single best next step** (one action, not a menu).892. **List what input is required** to proceed (questions or required confirmations).9091If the user explicitly wants an exploratory spike, allow proceeding with labeled assumptions:9293- Mark them as `[ASSUMPTION: ...]` and keep them in the doc so they can be revisited.94- Still prefer the smallest test to validate assumptions early.9596## Guardrails9798- Don’t invent requirements. Ask when unknown.99- Don’t propose destructive rollouts without a rollback.100- Keep “plan” separate from “implementation”; avoid code dumps in `plan.md`.101 - If you must proceed with uncertainty, label it as `[ASSUMPTION: ...]`.102 - Don’t stage/commit generated docs unless the user explicitly asks.103104## Template Locations105106- `docs/infras-kit/work-items/<id>-<slug>/ticket.md`107- `docs/infras-kit/work-items/<id>-<slug>/spec.md`108- `docs/infras-kit/work-items/<id>-<slug>/plan.md`109- `docs/infras-kit/work-items/<id>-<slug>/tasks.md`110- `docs/infras-kit/work-items/<id>-<slug>/implementation-notes.md`111- `docs/infras-kit/work-items/<id>-<slug>/confluence.md`