v0.29.0 — the infra plugin: multi-cloud infrastructure design, implementation and review

A fourth plugin: infra. It brings the multi-cloud infrastructure agent — and its knowledge bundle — into the toolkit from the standalone infra-design plugin, translated to the repository's conventions and wired into the contract tests. 99 slash commands → 103.

The plugin

Command	Model	What it does
/infra:start	sonnet	Triage: resolve the bundle, check freshness, fix the target environment and cloud, route to a mode
/infra:design	opus	Decide the configuration; emit the design document, environment matrix and ADRs
/infra:implement	sonnet	Write Terraform / manifests / Helm values / Kustomize overlays / CI into a real infrastructure repository
/infra:review	opus	Assess existing code or a design document; emit severity-ranked findings

The router settles four things — bundle, freshness, environment, cloud — and passes them down, so the mode skill never re-asks. Design → user confirmation → implement: a compound request is split deliberately, and implementation never proceeds on an unagreed design.

What it enforces rather than suggests

• Multi-cloud is the default premise. No answer assumes one cloud. L1 stays cloud-specific with aligned output names; L2–L4 carry no cloud branch at all. When three or more differences cannot be expressed in common, the answer is separation, not abstraction.
• Four environments. Base, chart and image digest stay identical everywhere; differences are value differences in an overlay or in values. if env == "production" never enters a base.
• One resource, one owner. A resource managed by two or more of Terraform / Argo CD / CI / manual operation is the highest-priority finding the review has — and the ownership map is built before anything else, because without it the other findings cannot be ranked.
• The bundle is the source. Claims carry a [foundation/terraform.md]-style citation; what the bundle does not cover is said to be uncovered.

The environment rule carries the asymmetry that keeps the plugin honest: local is absent from the bundle entirely and production has no observed implementation, so neither is presented with the confidence that test and staging earn. Production is designed as staging plus approval, protection and sync windows — recorded as an ADR, not written as if it were already true.

The knowledge bundle

knowledge/okf-k8s-tf/ — 23 OKF v0.2 documents covering Terraform, Kubernetes, Helm, Kustomize, Argo CD, GitLab CI/CD, Docker+Cosign, Vault, External Secrets, Prometheus/Grafana and Kyverno.

It is vendored rather than a submodule because its origin repository was deleted: there is no remote, and the copy here is the source of record. knowledge/OKF-K8S-TF-PROVENANCE.md records the chain of custody and the two commits the bundle's "observed implementation" tier is scoped to — outside those repositories that tier is evidence, not authority.

tools/update-okf-bundle.sh status --bundle=k8s-tf

/architect:update-knowledge gains --bundle=<name> to reach either bundle. --latest on k8s-tf reports that there is no remote rather than failing or silently doing nothing.

Contracts

• skills/infra/infra-contract.test.py (35 checks) — the rule's resolution order equals what update-okf-bundle.sh implements; every document the topic map names exists and every bundle document is reachable from it; stale_after parses on all 23 with security/kyverno.md still the earliest (Kyverno v1.20 plans to remove kyverno.io/v1 ClusterPolicy); the four skills' models match the router's Model Policy table; each named template carries its frontmatter block.
• tools/docs_consistency.test.py partitions nine groups, not eight. A whole plugin is one group; without the row the partition would have silently lost four commands.

Where it meets the architect pipeline

The infra skills are not a pipeline — no manifest, not run by /architect:pipeline, absent from the status dashboard. They overlap three architect skills on purpose, and the boundary is what keeps two systems from writing the same artifact:

Architect	Infra	Boundary
/architect:design-infrastructure	/infra:design	Logical vs. concrete
/architect:generate-infra-code → generated/	/infra:implement	Scaffolding vs. merge-bound code in the real infrastructure repository
/architect:review-operations	/infra:review	Design documents vs. Terraform, manifests and CI

Notes

Source material was Japanese throughout. SKILL.md files, rules and templates are translated to English per the repository convention; the bundle itself is not translated — it is a vendored external source, and rewriting it would make it something other than the source it cites.

Full detail: CHANGELOG.md · 日本語 · Guide