add-team-source
Register a git URL as a team-profile source so nyann can periodically sync and expose its profiles under a namespace. TRIGGER when the user says "add a team…
Actually APPLY an Infrastructure-as-Code change — the highest-stakes mutator in nyann; it can mutate real cloud infrastructure. Re-runs the plan, shows it, confirms with the user, then invokes `bin/iac-apply.sh --apply` (adding `--confirm-destroy` only when the user explicitly
$ npx -y skills add thettwe/nyann --skill iac-apply --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/iac-applyContext preview
The summary Claude sees to decide when to auto-load this skill.
Actually APPLY an Infrastructure-as-Code change — the highest-stakes mutator in nyann; it can mutate real cloud infrastructure. Re-runs the plan, shows it, confirms with the user, then invokes `bin/iac-apply.sh --apply` (adding `--confirm-destroy` only when the user explicitly
name: iac-apply description: > Actually APPLY an Infrastructure-as-Code change — the highest-stakes mutator in nyann; it can mutate real cloud infrastructure. Re-runs the plan, shows it, confirms with the user, then invokes `bin/iac-apply.sh --apply` (adding `--confirm-destroy` only when the user explicitly confirms a destructive change). UNMISTAKABLY opt-in: apply is never the default, destructive applies need a second explicit confirmation. TRIGGER when the user says "terraform apply", "apply the infra change", "deploy this infrastructure", "tofu apply", "cdk deploy", "pulumi up", "helm upgrade", "kubectl apply", "apply the plan", "run the apply now", "yes apply it" (in an IaC context), "ship the infra change", "provision this", "/nyann:apply". DISAMBIGUATION — fire ONLY for IaC apply intent on a detected infra repo. Do NOT trigger on the generic word "apply": NOT "apply this code patch", NOT "apply the suggestion", NOT "apply formatting", NOT "apply a migration" (DB migrations are out of scope), NOT "apply for X". An infra signal is REQUIRED — a tool name (terraform/tofu/cdk/pulumi/ helm/kubectl/kustomize/ansible), OR the word "infra"/"infrastructure"/ "deploy"/"provision", OR a detected `iac.tool` in the stack descriptor. With no infra signal, do NOT trigger. To only PREVIEW (no apply), that's `/nyann:plan` (the iac-plan skill) — iac-apply always previews first internally, but its purpose is the mutation.
Wraps `bin/iac-apply.sh`. **This is the highest-stakes mutator in nyann** — it can change real cloud infrastructure. Read this end to end before invoking. The gate ladder below is enforced in the script, not just prose; your job is to drive the flags in the right order and never shortcut a confirmation.
The script mirrors `bin/undo.sh`'s preview-before-mutate contract: **apply is never the default.** Without `--apply` it previews and exits 0. `--dry-run` always wins over `--apply`. A destructive plan needs a second explicit confirmation on top of `--apply`. The output is a JSON object on stdout (`status: preview|applied|skipped|refused`, plus `tool`, `unit`, `summary`, `destructive`, optional `record_path`, `exit_code`, `message`).
Never invoke an apply because a plan looked ready. Only proceed when the user has clearly asked to apply/deploy/provision on an infra repo (see DISAMBIGUATION). If they only wanted to see the diff, route to `/nyann:plan`. Confirm there's an infra signal (a tool name, an "infra"/"deploy" intent, or a detected `.iac.tool`) before doing anything.
Always obtain an **IacPlan** before applying — `iac-apply.sh` computes one internally (or reads `--plan <iacplan.json>` if you already ran `/nyann:plan` and saved it). Either way, run a preview pass first and **show the add/change/destroy summary to the user**:
bin/iac-apply.sh --target <cwd> [--unit <repo-rel-path>] # no --apply → preview
This emits `status:"preview"`, exits 0, and mutates nothing. Render `.summary` (e.g. **"+3 add, ~1 change, -2 destroy"**), `.destructive`, and `.destructive_known` exactly as the iac-plan skill does. If the preview's plan came back `status:"skipped"` (CLI/backend/creds absent), the apply emits `status:"skipped"` exit 0 — surface `.message`, and stop: there is nothing to apply. If the plan was `status:"refused"` (unknown tool / `--unit` traversal), apply emits `status:"refused"` exit 1 — relay `.message` and fix the input.
This is the human gate. How you confirm depends on whether the plan is destructive:
Only possible for a structured tool with `destroy == 0`. Show the add/change counts and ask a plain yes/no: *"Apply this change? (+N add, ~M change, no destroys)"*. Proceed only on an explicit yes. Skip this only if the user already said "just apply it, don't ask".
This covers any structured plan with `destroy > 0` **and every advisory plan** (helm/kubernetes/kustomize/ansible — `destructive_known:false`, where destruction can't be ruled out from a text diff). **You MUST call the `AskUserQuestion` tool** (not plain text) and get an explicit go-ahead before adding `--confirm-destroy`:
{
"questions": [
{
"question": "This apply is DESTRUCTIVE — it will destroy or replace real infrastructure. Confirm?",
"header": "Confirm destroy",
"multiSelect": false,
"options": [
{ "label": "No, stop (Recommended)", "description": "Do not apply. Nothing is mutated. Re-review the plan first." },
{ "label": "Yes, apply the destroy", "description": "Proceed. Resources WILL be destroyed/replaced — this is not reversible by nyann." }
]
}
]
}For an **advisory** destructive plan, add that the destroy count is unknown (`destructive_known:false`): the tool gave only a text diff, so nyann treats it as potentially destructive. Strongly recommend reading the raw diff (the plan's `raw_path`) before confirming.
Pass `--confirm-destroy` **only** after the user picks "Yes". Pass `--confirmed true` explicitly to record that a human confirmed (the CLI defaults `--confirmed` to the `--confirm-destroy` value for headless parity, but this skill should always pass it explicitly after the AskUserQuestion).
bin/iac-apply.sh \ --target <cwd> \ [--unit <repo-rel-path>] \ [--plan <iacplan.json>] \ --apply \ [--confirm-destroy --confirmed] # ONLY after the user confirms a destroy
The script walks this exact gate ladder — drive the flags to match it:
1. **Plan obtained first.** `skipped` plan → `status:"skipped"` exit 0 (no apply). `refused` plan → `status:"refused"` exit 1. 2. **Gate 1 — preview by default.** No `--apply` (or any `--dry-run`)
ငြမ်း is Burmese for scaffolding. Nyann is the Claude Code plugin that picks expert git defaults for your stack — branching, working hooks (Husky / pre-commit.com / lefthook), commits, releases, CI, docs — then keeps the repo on those rails through every PR
Repo: thettwe/nyann
Register a git URL as a team-profile source so nyann can periodically sync and expose its profiles under a namespace. TRIGGER when the user says "add a team…
Bootstrap a fresh or existing repo with nyann. TRIGGER when the user says "set up this project", "initialize git workflow", "bootstrap this repo", "scaffold…
Survey the machine and report which nyann features are usable right now. TRIGGER when the user says "is my machine ready for nyann", "what do I need to…
Prune local branches whose work is already merged into the base. TRIGGER when the user says "clean up branches", "delete merged branches", "prune local…
Generate a Conventional Commits message from the staged diff and create the commit after user confirmation. TRIGGER when the user says "commit these changes",…
Bundle a redacted, support-grade snapshot of the current nyann state for inclusion in a bug report or support request. Combines explain-state + doctor + git…