cladding-init
Use only when the user explicitly names Cladding and asks to initialize, adopt, or refresh it; never use for an ordinary project creation or implementation…
Validate the active spec.yaml against the Ironclad schema and refresh the inventory. Rarely needed manually — clad_create_feature already auto-syncs the inventory and clad check / clad done self-validate the spec, so do NOT run it as a reflexive pre-flight before those. Use it
$ npx -y skills add qwerfunch/cladding --skill sync --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/syncContext preview
The summary Claude sees to decide when to auto-load this skill.
Validate the active spec.yaml against the Ironclad schema and refresh the inventory. Rarely needed manually — clad_create_feature already auto-syncs the inventory and clad check / clad done self-validate the spec, so do NOT run it as a reflexive pre-flight before those. Use it
description: Validate the active spec.yaml against the Ironclad schema and refresh the inventory. Rarely needed manually — clad_create_feature already auto-syncs the inventory and clad check / clad done self-validate the spec, so do NOT run it as a reflexive pre-flight before those. Use it only after you have directly hand-edited a shard file (spec/features/*.yaml or spec.yaml). Activate only when the connected project contains spec.yaml or the user explicitly names Cladding; ignore ordinary requests in uninitialized projects.
Run `clad sync` from the project root. The command:
Spec must be valid before `clad check` or any stage runner produces meaningful output. If `sync` fails, fix the reported issues first.
clad sync
You rarely need to run this MANUALLY — and a reflexive "just-in-case" sync after every operation is wasted work (in an A/B measurement, 28 of 30 manual `clad sync` calls found nothing to fix). The inventory + validation are already maintained for you:
malformed AC at creation), so you don't need to sync after creating features.
to pre-sync before them — a real drift surfaces in that gate anyway.
Run `clad sync` only when you have **hand-edited a shard file directly** (`Edit`/`Write` on `spec/features/*.yaml` or `spec.yaml`), to refresh the inventory and re-validate that edit. Prefer `clad_create_feature` over hand-editing in the first place — then even this is unneeded.
For an organization to trust AI with its code, three things must hold — trust, traceability, and stability at scale. cladding wraps your AI coding agent: your intent goes in before it writes, and the result is verified against your spec after, so those three are earned, not assumed. First L4 implementation of the Ironclad standard.
Repo: qwerfunch/cladding
Use only when the user explicitly names Cladding and asks to initialize, adopt, or refresh it; never use for an ordinary project creation or implementation…
Impl-blind test/oracle author — writes conformance tests from a spec-only brief. Tool-restricted by definition (no Read/Grep/Glob/Edit), so "authored blind" is…
Render release notes / a changelog from the cladding spec. Use when the user asks for release notes, a changelog, 릴리즈 노트, 변경 이력, or "what changed (since…
Run every Iron Law stage and the drift detector suite. Use when the user wants the full project health snapshot, a CI gate, or to verify nothing regressed…
Record a feature checkpoint event pinning the current git HEAD plus a spec digest, so a later rollback can restore the exact pre-change state. Use before a…
Advance Cladding onboarding after the user answers a pending product question. Use the MCP prepare/apply flow, preserve the answer verbatim, and never invent…