agentsclimarketplace

Infra kit.workflow

Skill huyngopt1994/infras-kit/infras-kit-plugin/skills/infra-kit.workflow

Infras Kit Provide a Kit For All Infras Working

Install
npx -y skills add huyngopt1994/infras-kit --skill infra-kit.workflow

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Turn an infra ticket into a lightweight spec, implementation plan, task list, and implementation notes (with optional Confluence-ready output).

SKILL.md

4.6 KB, as published. Nobody here has run it

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

  1. 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>"
  1. Fill in ticket.md, then generate plan.md and tasks.md.
  2. 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.

  1. 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
  2. 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
  3. 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
  4. 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?
  5. Implement (implementation-notes.md)
    • record what changed, gotchas, and final verification outputs
  6. 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:

  1. State the single best next step (one action, not a menu).
  2. 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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.