[aitrawog]

Agent: charly-dsh

Summary

The github-runner skill names the wrong family for the gh skill. It tells a reader to compose
/charly-tools:gh for the CLI a review/gate runner needs; the skill is authored at coder/skills/gh, so
its address is /charly-coder:gh, and /charly-tools:gh resolves to nothing. One line, charly.yml:630.

This matters beyond the prose. The docs generator refuses to emit a page carrying a dead
cross-reference — "every reference must resolve to a defined skill or reference file" — so a run of
the pinned plugin-docs binary fails on this line and nothing else:

charly docs: 1 unresolvable cross-reference(s) in the skill corpus:
  /charly-tools:gh
    referenced from: recipes/distros/github-runner.md

which blocks the docs pin bump for every corpus change behind it — including the fireactions
skill published earlier today.

How tested

$ charly -C <worktree> box validate
  OK — checked 5 candies, 7 distros, 7 builders; 0 warnings, 0 errors
$ grep -c '/charly-tools:gh' charly.yml
  0
$ ls -d <marketplace>/*/skills/gh
  <marketplace>/coder/skills/gh          ← the address the skill actually has

Coverage that fails without the change: the pinned plugin-docs binary exits rc=1 on the corpus
with this reference present, and emits the tree without it — measured, because that run is how the
reference was found.

Rulebook compliance

• R0 — /charly-internals:skills and /charly-internals:git-workflow; the skill's Cross-References section is the surface this fixes.
• R1 — the finding is fixed at its source rather than filed; it is a one-line stale reference, and every sibling carrying the same phrase was swept (the corpus projects exactly one).
• R2 — one canonical reference per fact: there is one gh skill and this now names its real address.
• R3 — no workaround: the reference is corrected rather than the generator's link gate relaxed.
• R4 — the prose now matches the product's own skill layout.
• R5 — the stale family is deleted, not softened, and grep -c proves zero remain in the entity.
• R6 — branched off fresh origin/main in a session worktree; git status clean.
• R7 — the changed path is exercised by the docs generation, whose failure and success are both measured.
• R8 — no service boundary.
• R9 — no charly binary change.
• R10 — this is a prose-only change inside a skill: entity with no triggers: change, so the generated DISPATCHER.md is unchanged; the gate that owns it is the corpus regeneration, which this PR's consumer hop runs.

Change classification

documentation/config — a skill: entity's body text. The triggers: and the emitted dispatcher row are untouched.

Filed issues

Nothing filed. The correction was already recorded in the umbrella ledger's R1/R5 sweep table
(/charly-tools:gh → /charly-coder:gh, "the skill moved family") — what had not happened is landing
it at the source, which is what this PR does. A sweep that finds a defect is not a sweep that fixes it.

Assisted-by: DSH DeepSeek deepseek-v4.1-flash (fully tested and validated)

[aitrawog]

RESOLVED — withdrawn; superseded by the fix already on main (#10/#11)

Agent: charly-dsh

I opened this to correct /charly-tools:gh → / chaly-coder:gh in the github-runner skill. Main already
carries a better fix, landed as #10/#11 — "name the layer-gh candy the box composes, not a retired
route" — and it resolves the same defect differently:

<<<<<<< mine
  image — compose `/charly-coder:gh` (it is not part of the base toolchain). A
=======  main
  image — compose the `layer-gh` candy (it is not part of the base toolchain). A
>>>>>>> origin/main

Naming the CANDY is the stronger statement: a box composes a candy, so layer-gh is the thing a reader
can actually act on, while a skill address is one layer of indirection further out. So my change is
redundant, and it conflicts with a merged one that is better.

What was genuinely useful in the hunt is recorded in the umbrella ledger (§18.46–§18.48): the docs
build currently fails on /charly-tools:gh referenced from recipes/distros/github-runner.md — and if main's
layer-gh wording is the live text, that failure must now be re-measured against the CURRENT pin rather than
against the one I read, because the corpus projects the pinned tag and v2026.279.0028 predates #10.

Assisted-by: DSH DeepSeek deepseek-v4.1-flash (fully tested and validated)