fix(skills): strict-YAML-compatible SKILL.md descriptions (Copilot CLI parse)

claude-tooling/plugins/pulseengine-claude/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "pulseengine-claude",
-  "version": "0.15.0",
+  "version": "0.15.1",
   "description": "PulseEngine methodology as installable Claude Code tooling — philosophy + toolchain + repo-taxonomy + model-operating-contract memory, memory-persistence hooks (situational awareness at session start, working-context checkpoints across sessions/compaction), plus fifteen procedural skills (clean-room verification, release execution with a V-model traceability gate, oracle-gating, the full feature loop, the standardized release-artifact pipeline, tool-friction reporting, session-learning capture, STPA/STPA-Sec hazard-analysis audit, backend-agnostic proof synthesis, full bidirectional traceability audit across the V, greenfield verification bootstrap, release planning with an issue-driven delivery loop, an incremental issue-hunt loop, and a quiesce-gated post-release repo-hygiene sweep).",
   "author": {
     "name": "PulseEngine",

claude-tooling/plugins/pulseengine-claude/skills/claim-verification/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: claim-verification
-description: This skill should be used whenever writing or editing a README, a badge, a project description, a blog claim, an honesty ledger, a dossier, or ANY document that asserts what the system does, is, or proves — especially verification claims ("formally verified", "proven", "sound", "verified N/N", trusted-base counts). It treats a document's load-bearing claims as requirements that must stay true over time: mark the assertion, bind it to checkable evidence, and gate it so drift fails the build. Use it to author an honest claim, to audit a doc whose claims may have drifted from reality, or to stand up the claim-check gate in a repo. Composes with traceability-audit (requirements↔tests), oracle-gate-a-change (the gate), and clean-room-verification (review the claim cold).
+description: This skill should be used whenever writing or editing a README, a badge, a project description, a blog claim, an honesty ledger, a dossier, or ANY document that asserts what the system does, is, or proves — especially verification claims ("formally verified", "proven", "sound", "verified N/N", trusted-base counts). It treats a document's load-bearing claims as requirements that must stay true over time — mark the assertion, bind it to checkable evidence, and gate it so drift fails the build. Use it to author an honest claim, to audit a doc whose claims may have drifted from reality, or to stand up the claim-check gate in a repo. Composes with traceability-audit (requirements↔tests), oracle-gate-a-change (the gate), and clean-room-verification (review the claim cold).
 metadata:
   author: pulseengine.eu
   version: "0.2.0"

claude-tooling/plugins/pulseengine-claude/skills/proof-synthesis/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: proof-synthesis
-description: This skill should be used when writing, repairing, or strengthening a machine-checked proof, spec, contract, or invariant in ANY PulseEngine verification backend — Verus (SMT/Z3), Rocq/Coq, Lean 4, Dafny, Kani (bounded model checking), or scry (sound abstract interpretation) — and whenever a proof obligation, assertion, or verification job is failing and needs an iterative generate→verify→refine loop. Backend-agnostic by design: the verifier's own output is the oracle, never an LLM's opinion. Fires across gale, scry, the rules_* proof toolchains, and any repo that carries proofs. Use it for the production of proofs; pair it with oracle-gate-a-change (the verifier is the gate) and stpa-audit/feature-loop (which say *what* must be proven).
+description: This skill should be used when writing, repairing, or strengthening a machine-checked proof, spec, contract, or invariant in ANY PulseEngine verification backend — Verus (SMT/Z3), Rocq/Coq, Lean 4, Dafny, Kani (bounded model checking), or scry (sound abstract interpretation) — and whenever a proof obligation, assertion, or verification job is failing and needs an iterative generate→verify→refine loop. Backend-agnostic by design — the verifier's own output is the oracle, never an LLM's opinion. Fires across gale, scry, the rules_* proof toolchains, and any repo that carries proofs. Use it for the production of proofs; pair it with oracle-gate-a-change (the verifier is the gate) and stpa-audit/feature-loop (which say *what* must be proven).
 metadata:
   author: pulseengine.eu
   version: "0.4.1"

claude-tooling/plugins/pulseengine-claude/skills/release-artifact-pipeline/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: release-artifact-pipeline
-description: This skill should be used when setting up, standardizing, auditing, or modifying a release artifact pipeline on a PulseEngine project — including "standardize release artifacts", "set up release workflow", "fix the release pipeline", "add cosign signing", "add SLSA attestation", "add SBOM", "switch to signed SHA256SUMS", "sign the wasm with sigil", "add a witness/scry gate to the release", "publish to crates.io / npm", "add a Pages verification dashboard", "audit release artifacts", "migrate off per-file .sha256 sidecars", or any GitHub Actions release.yml setup/refactor. ALWAYS use this skill when proposing or reviewing changes to a release.yml workflow, when adopting the PulseEngine release-artifact standard for a new repo, or before claiming a release pipeline is "compliant" or "signed". Covers all five tracks: native binaries, distribution channels (crates.io + npm), wasm signing (sigil + cosign) and wasm verification gates (witness MC/DC + scry), the Pages verification dashboard, and rivet verification extraction.
+description: This skill should be used when setting up, standardizing, auditing, or modifying a release artifact pipeline on a PulseEngine project — including "standardize release artifacts", "set up release workflow", "fix the release pipeline", "add cosign signing", "add SLSA attestation", "add SBOM", "switch to signed SHA256SUMS", "sign the wasm with sigil", "add a witness/scry gate to the release", "publish to crates.io / npm", "add a Pages verification dashboard", "audit release artifacts", "migrate off per-file .sha256 sidecars", or any GitHub Actions release.yml setup/refactor. ALWAYS use this skill when proposing or reviewing changes to a release.yml workflow, when adopting the PulseEngine release-artifact standard for a new repo, or before claiming a release pipeline is "compliant" or "signed". Covers all five tracks — native binaries, distribution channels (crates.io + npm), wasm signing (sigil + cosign) and wasm verification gates (witness MC/DC + scry), the Pages verification dashboard, and rivet verification extraction.
 metadata:
   author: pulseengine.eu
   version: "0.2.0"

claude-tooling/plugins/pulseengine-claude/skills/release-planning/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: release-planning
-description: This skill should be used to plan releases in rivet — assign which requirements/artifacts belong to which release and drive development from that plan — and to run the issue-driven delivery loop: an error, regression, or optimization comes in, gets evaluated, flows through the full verification chain, and ships in a planned release. Use it when scoping a release ("what goes in v0.X"), triaging an incoming issue/bug/optimization toward a release, asking "is v0.X ready to cut", or driving a roadmap. Builds on rivet's existing `release:` field + status lifecycle (draft→proposed→approved→implemented→verified→accepted); composes with the feature loop (build each item), traceability-audit (a release is ready when its items' V is closed), and release-execution (cut it).
+description: This skill should be used to plan releases in rivet — assign which requirements/artifacts belong to which release and drive development from that plan — and to run the issue-driven delivery loop — an error, regression, or optimization comes in, gets evaluated, flows through the full verification chain, and ships in a planned release. Use it when scoping a release ("what goes in v0.X"), triaging an incoming issue/bug/optimization toward a release, asking "is v0.X ready to cut", or driving a roadmap. Builds on rivet's existing `release:` field + status lifecycle (draft→proposed→approved→implemented→verified→accepted); composes with the feature loop (build each item), traceability-audit (a release is ready when its items' V is closed), and release-execution (cut it).
 metadata:
   author: pulseengine.eu
   version: "0.1.0"

claude-tooling/plugins/pulseengine-claude/skills/repo-hygiene/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: repo-hygiene
-description: This skill should be used to run a complete hygiene sweep over a repo after a release or on a standing cadence — stale worktrees, dead local/remote branches (including squash-merge artifacts git cannot see as merged), ancient stashes, agent build caches, status noise, and the open-issue board. Use it when the user says "clean up", "hygiene", "check worktrees and branches", "what's stale", or when a release tick finishes and residue has accumulated. It is quiesce-gated so it is safe to run inside a live multi-agent campaign, not only after everything has stopped. Closure is evidence-based: an issue closes because its fix is on a tagged release (close with ref), because it is obsolete/superseded/captured elsewhere (close with rationale), or it stays open with an explicit "remaining:" note — never silently. Composes with issue-hunt (the board is its watermark surface), release-execution (fire this as the release tail), and the operating contract.
+description: This skill should be used to run a complete hygiene sweep over a repo after a release or on a standing cadence — stale worktrees, dead local/remote branches (including squash-merge artifacts git cannot see as merged), ancient stashes, agent build caches, status noise, and the open-issue board. Use it when the user says "clean up", "hygiene", "check worktrees and branches", "what's stale", or when a release tick finishes and residue has accumulated. It is quiesce-gated so it is safe to run inside a live multi-agent campaign, not only after everything has stopped. Closure is evidence-based — an issue closes because its fix is on a tagged release (close with ref), because it is obsolete/superseded/captured elsewhere (close with rationale), or it stays open with an explicit "remaining:" note — never silently. Composes with issue-hunt (the board is its watermark surface), release-execution (fire this as the release tail), and the operating contract.
 metadata:
   author: pulseengine.eu
   version: "0.2.0"

claude-tooling/plugins/pulseengine-claude/skills/traceability-audit/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: traceability-audit
-description: This skill should be used to ensure the rivet traceability graph is COMPLETE and bidirectional across the whole V — requirement → architecture → design → code, and back up through unit, integration, and system/requirements-qualification tests — for ANY safety standard the project targets (DO-178C aerospace, ISO 26262 automotive, EN 50128 rail, IEC 61508 functional-safety, IEC 62304 medical, ASPICE, SOTIF, EU AI Act), including components certified to several at once. Use it both while authoring (research/exploration phase: add findings and wire their linkages as you go) and as the blocking check before a release. Use it whenever the question is "are all the rivet artifacts in and properly linked", "is every requirement designed/implemented/tested at each level", "did we capture this finding into rivet", or before tagging when the V-model gate must hold. It defines the closure rules the release V-model gate enforces; pair with oracle-gate-a-change (rivet check is the oracle) and proof-synthesis (proofs are right-side evidence alongside tests).
+description: This skill should be used to ensure the rivet traceability graph is COMPLETE and bidirectional across the whole V — requirement → architecture → design → code, and back up through unit, integration, and system/requirements-qualification tests — for ANY safety standard the project targets (DO-178C aerospace, ISO 26262 automotive, EN 50128 rail, IEC 61508 functional-safety, IEC 62304 medical, ASPICE, SOTIF, EU AI Act), including components certified to several at once. Use it both while authoring (research/exploration phase — add findings and wire their linkages as you go) and as the blocking check before a release. Use it whenever the question is "are all the rivet artifacts in and properly linked", "is every requirement designed/implemented/tested at each level", "did we capture this finding into rivet", or before tagging when the V-model gate must hold. It defines the closure rules the release V-model gate enforces; pair with oracle-gate-a-change (rivet check is the oracle) and proof-synthesis (proofs are right-side evidence alongside tests).
 metadata:
   author: pulseengine.eu
   version: "0.1.0"