[aitrawog]

Summary

pod-charly-automation is a skills-only carrier — measured: 0 .go, 0 .cue, 0 candy
directories. The openclaw-deploy skill documents the openclaw gateway candy this repo declares (the family's candies and their composition), which is the openclaw candy
this repo declares; under AGENTS.md Part II #5 a skill lives with the code, plugin or
config it describes, so the body moves here byte-identically.

The gate (opencharly#606): the entity comes from the skill's own prose, never from its
name; then where that entity exists; then the negative control.

skill	the entity its own prose names	where it exists (measured)
openclaw-deploy	the openclaw gateway candy this repo declares (the family's candies and their composition)	layer-openclaw/charly.yml → the openclaw candy node

What is in this diff (2 files changed, 468 insertions(+))

• The skill body, byte-identical to the carrier's (full sha256sum output below).
• A routing-only skill: node in charly.yml — name/family/owner, no inline
  description:/content: (an inline body that disagrees with its file is a hard error
  in the marketplace generator).
• family: automation is kept unchanged, so the existing
  /charly-automation:openclaw-deploy address and every external reference to it still
  resolves; owner: becomes openclaw, so the body is read from
  <repo root>/.agents/skills/openclaw-deploy/SKILL.md.
• No documentation file changed: nothing in this repo's AGENTS.md/README.md
  claimed the skill lived elsewhere (checked with a grep for the carrier name and for a
  "no skill: entity" claim).

Producer-first. No carrier loses a node here: those removals and retirements belong to
the session that claimed the carriers (opencharly/opencharly#600), and the marketplace
refs switchover is the leg that proves the relocation end to end.

How tested

Change class: documentation + candy-config (skill prose and one skill: routing node;
no Go, no schema, no runtime path). The gate that owns it is charly box validate, which
reads the skill files through the same CollectSkills path the ai.opencharly.skill OCI
label and the marketplace corpus use.

# head 97ad5bda0f9d2050dd5941a25f2023b793dd2609  (git rev-parse HEAD)
$ git rev-parse HEAD && git rev-parse HEAD^{tree}
97ad5bda0f9d2050dd5941a25f2023b793dd2609
0cd0b33c465de6dcba61e8f026848dc4afe5b015

$ sha256sum <carrier copy>; sha256sum <this tree>
9f2a5eb8fb53eccc98c4bc07290e9d7687ea761e4e3c787b0236ed9a8c42532a  pod-charly-automation/.agents/skills/openclaw-deploy/SKILL.md
9f2a5eb8fb53eccc98c4bc07290e9d7687ea761e4e3c787b0236ed9a8c42532a  .agents/skills/openclaw-deploy/SKILL.md

$ diff -r <carrier>/.agents/skills/openclaw-deploy .agents/skills/openclaw-deploy
(no output — exit 0: the bytes are equal)

$ charly box validate
charly box validate: OK — checked 490 candies, 38 boxes, 1 deploy, 7 distros, 7 builders; 0 warnings, 0 errors
rc=0

The gate CAN fail — negative control on this exact tree, with the moved body removed:

$ rm .agents/skills/openclaw-deploy/SKILL.md && charly box validate
charly: error: command "validate": validation error: skills: skill "openclaw-deploy": no body — the node carries no in-line `content:` and no SKILL.md exists under .agents/skills at the repo root of the owning candy "openclaw"
rc=1

No R10 disposable bed: the diff changes no runtime path (no Go, no schema, no service, no
build step), so a bed would prove something this diff cannot break. The binary is the
worktree-local build (charly version = 2026.295.1709, equal to charly/charly's HEAD
stamp).

Rulebook compliance

• R0 — /charly-internals:skills, :git-workflow, :cutover-policy loaded first;
  opencharly#611/#606/#600 read in full first.
• R1 — charly box validate green with zero warnings; the negative control proves the
  green is not vacuous.
• R2 — routing only in the node; the body stays the single file.
• R3 — no workaround: no inline body, no hand-written corpus entry.
• R4/R5 — no stale claim needed correcting in this repo (no file named the carrier or denied owning
  the skill); the moved body's own cross-references still resolve because the family is unchanged.
• R6 — branch off origin/main, one commit, one push, no force-push, no bypass.
• R7 — the proof is a gate that fails without the change.
• R9 — worktree-local binary, version equal to the source stamp; no Go changed.
• R10 — the change-class gate ran on the committed tree.
• A3 — the attribution tier this footer claims is justified by the gate above. The
  delivered system message reads, verbatim,
  You are a coding agent powered by the deepseek-v4.1-flash model. — harness
  DeepSeek Harness, model deepseek-v4.1-flash — cited with
  The pr-validator's model allowlist rejects a real runtime: deepseek-v4.1-flash via ollama-cloud opencharly#538.

Change classification

feat(skills)! — documentation + candy-config, documentation reviewed. No runtime
behaviour, no schema, no Go, no pins.

Filed issues

None — the destination was measured, and no claim this change falsifies survives.

Assisted-by: DeepSeek Harness deepseek-v4.1-flash (documentation reviewed)

[github-actions]

Review — PASS

What the diff actually contains

.agents/skills/openclaw-deploy/SKILL.md (added, +446) — a self-contained skill body. It is internally coherent with the repo it now lives in: it describes the openclaw candy (candy/openclaw/, supervisord program, port 18789, data volume), names opencharly/layer-openclaw as the owner of box/openclaw, and its cross-references are family-qualified (/charly-core:*, /charly-check:cdp, /charly-check:vnc, /charly-automation:tmux, /charly-automation:alias). No secrets are present — only placeholders (BOT_TOKEN, <KEY>, <image>, <repo root>). The kill -9 $(ss …) line is documented operator guidance, not executed code. No injection or unsafe-handling concern in a prose artifact.

charly.yml (modified, +22) — the appended block is valid YAML and is exactly what the body says it is: a routing-only node carrying name/family/owner plus triggers:, with no inline description:/content:. family: automation preserves the /charly-automation:openclaw-deploy address; owner: openclaw points the body at <repo root>/.agents/skills/openclaw-deploy/SKILL.md. The negative control quoted in the body is the right shape for this generator: remove the file and the node has no body, so the gate fails — i.e. the green is not vacuous.

Honesty of the body vs. the diff

• "2 files changed, 468 insertions(+)" — matches: 446 + 22 = 468, two files. ✓
• "routing-only skill: node … no inline description:/content:" — matches the hunk exactly. ✓
• "family: automation kept unchanged" — the node does set family: automation, consistent with the stated address preservation. ✓
• "no Go, no schema, no runtime path" — the diff touches one Markdown file and one config node. ✓
• "No documentation file changed" — true in the sense meant (no AGENTS.md/README.md edit); the only doc added is the skill itself. Slightly loose wording, not a contradiction.
• The sha256/diff -r/charly box validate transcript and the "490 candies / 38 boxes" figure are not reproducible from the message (the carrier tree and the tool are not here). They are plausible for a docs+config change and nothing in the diff contradicts them; I do not treat them as proof, but they are not a basis for blocking either.

Tests

The change class is documentation + candy-config. The relevant gate is charly box validate via CollectSkills, and the body supplies a negative control on the same tree that fails with a specific, on-point error. That is proportionate coverage for a change with no runtime path. Requiring a disposable bed here would prove nothing the diff can break.

Scope and cleanliness

• One commit, one push, no force-push, branch off main — consistent with the single listed commit.
• The node is additive; the source node in pod-charly-automation is deliberately not removed here, with the removal attributed to Policy: a skill lives with the code it describes — retire the skills-only repo class (22 repos / 94 skills measured) opencharly#600. That leaves the skill body duplicated across the two repos in the interim. This is the one real risk in the PR: if the marketplace corpus keys skills by family + name, two live automation/openclaw-deploy nodes would collide until the carrier leg lands. The body is explicit that this is a producer-first cutover with the switchover leg proving the relocation, so it is a disclosed sequencing risk, not a hidden defect — worth confirming in #600, but not grounds to block this leg.
• Minor, non-blocking wording nits: the section comment calls these "the verb/schema skills this repo's own candy owns", while openclaw-deploy is a deploy/config skill (and the skill itself states there is no charly openclaw command); and the ! breaking-change marker on feat(skills)! is stronger than the change — since family is preserved, no address actually breaks. Neither affects behaviour.

Comments

The thread is empty (0 comments), so there is nothing to disposition and no maintainer sign-off to weigh. The change therefore stands on its own evidence, and that evidence — a coherent 446-line prose file plus a well-formed routing node whose claims are reproduced by the diff — is sufficient for a docs+config change of this size.

Verdict: PASS

---

ollama-cloud/deepseek-v4.1-flash — action-review.

View action run