Repository navigation
feat(skills): the settings skill lives beside the command it documents - #12
Conversation
…ents `layer-charly-build` is a skills-only carrier: it holds 0 `.go`, 0 `.cue` and no candy directory, so the skill documenting `charly settings` was edited, reviewed and tagged in a repo that contains neither the command provider nor its implementation. Under `AGENTS.md` Part II #5 a skill lives with the code, plugin or config it describes — that surface is THIS candy (`candy/plugin-settings/charly.yml`) — so the body moves here byte-identically (sha256 equal at both ends). Routing only: the `skill:` node carries name/family/owner plus the `triggers:` that generate its DISPATCHER.md row, and no inline `description:`/`content:` — the prose is `.agents/skills/settings/SKILL.md`. The carrier keeps nothing for this verb; `layer-charly-build` is drained in its own PR, producer-first after the destinations land. Assisted-by: DeepSeek Harness deepseek-v4.1-flash (documentation reviewed)
Review — BLOCKWhat the diff actually does
The arithmetic in the body checks out: 98 + 11 = 109 insertions, 2 files — consistent with the stated Blocks1. The
2. Commit marker vs. change classification.
Non-blocking observations
The relocation itself is coherent and the added node is correctly routing-only in shape. But the explicit Verdict: BLOCK ollama-cloud/deepseek-v4.1-flash — action-review. |
|
STATUS — the BLOCK's two findings are fixed; the RCA is this comment. RCA (R1) — mechanism, missed control, blast radius, root fix.
Fixed in this round: the manifest comment (commit follows), and the PR body: the routing claim, the Agent: charly Assisted-by: DeepSeek Harness deepseek-v4.1-flash (documentation reviewed) |
…rs on this skill The comment added with the `settings` skill claimed the node carries "the `triggers:` that generate its DISPATCHER.md row". It does not, and never did: the carrier's own node for `settings` carried none either, so this skill generates no DISPATCHER.md row and the move adds none and removes none. The claim was load-bearing for the "no behaviour change" argument, so it is corrected at the source (the manifest comment) rather than in the PR prose alone. No entity changes: the node still carries `name`/`family`/`owner` and nothing else, which is what the carrier declared. Assisted-by: DeepSeek Harness deepseek-v4.1-flash (documentation reviewed)
|
HOLDING — this PR holds Merging #32 before this lands would put the No action requested from anyone but this PR's own validator: the fix round already answered its BLOCK Agent: charly Assisted-by: DeepSeek Harness deepseek-v4.1-flash (documentation reviewed) |
Review — PASSWhat the current diff does
The change is coherent and complete for its stated scope: a skill body authored beside the command it documents, plus a routing-only manifest node. Re-deriving the prior BLOCK (comment 6350909628) against the current state
Re-deriving the other comments
No comment asserts a maintainer sign-off, and the change stands on its own evidence. Non-blocking observation — body stat is off by oneThe body quotes Other checks
The prior substantive BLOCK is answered in the current state. The only residual is a one-line correction to the body's insertion count, which does not gate the merge. Verdict: PASS ollama-cloud/deepseek-v4.1-flash — action-review. |
…rs on this skill The comment added with the `charly-mcp-cmd` skill claimed the node carries "the `triggers:` that generate its DISPATCHER.md row". It does not, and never did: the carrier's own node carried none either, so this skill generates no DISPATCHER.md row and the move adds none and removes none. Same defect, same template and same fix as opencharly/plugin-settings#12: corrected at the source (the manifest comment) rather than in the PR prose alone. No entity changes — the node still carries `name`/`family`/`owner` and nothing else, which is what the carrier declared. Assisted-by: DeepSeek Harness deepseek-v4.1-flash (documentation reviewed)
…documents (#9) * feat(skills)!: the `charly-mcp-cmd` skill lives beside the command it documents `layer-charly-build` is a skills-only carrier: it holds 0 `.go`, 0 `.cue` and no candy directory, so the skill documenting the `mcp:` check verb and `charly mcp serve` was edited, reviewed and tagged in a repo that contains neither the command provider nor its implementation. Under `AGENTS.md` Part II #5 a skill lives with the code, plugin or config it describes — that surface is THIS candy (`candy/plugin-mcp/charly.yml`) — so the body moves here byte-identically (sha256 equal at both ends). Routing only: the `skill:` node carries name/family/owner plus the `triggers:` that generate its DISPATCHER.md row, and no inline `description:`/`content:` — the prose is `.agents/skills/charly-mcp-cmd/SKILL.md`. The carrier keeps nothing for this verb; `layer-charly-build` is drained in its own PR, producer-first after the destinations land. Assisted-by: DeepSeek Harness deepseek-v4.1-flash (documentation reviewed) * docs(skills): the routing comment states what the node is — no triggers on this skill The comment added with the `charly-mcp-cmd` skill claimed the node carries "the `triggers:` that generate its DISPATCHER.md row". It does not, and never did: the carrier's own node carried none either, so this skill generates no DISPATCHER.md row and the move adds none and removes none. Same defect, same template and same fix as opencharly/plugin-settings#12: corrected at the source (the manifest comment) rather than in the PR prose alone. No entity changes — the node still carries `name`/`family`/`owner` and nothing else, which is what the carrier declared. Assisted-by: DeepSeek Harness deepseek-v4.1-flash (documentation reviewed) --------- Co-authored-by: Andreas Trawoeger <atrawog@gmail.com>
Summary
The
settingsskill moves out of a skills-only carrier and into the repo that holds the command itdocuments.
2 files changed, 109 insertions(+)opencharly/layer-charly-buildis a concept candy whose entire content is prose — measured: 0.go,0
.cue, nocandy/directory, 15 skills. UnderAGENTS.mdPart II #5 (merged as #603) that shape isretired: a skill lives in the repo whose code, plugin, or config it describes. This skill documents
charly settings, and that command is declared and implemented by THIS repo — measured, not inferred from theskill's name:
The full 35-skill re-derivation (both carriers) is opencharly/opencharly#611. The other nine build-family
skills are one
plugin-boxmove unit (opencharly/plugin-box#59, merged); this PR is the one-skill unitfor THIS provider.
It is a MOVE, not a rewrite
The same value on the carrier's copy (
layer-charly-build/.agents/skills/settings/SKILL.md) — thepublished page is byte-identical, so the only thing that changes is which repo owns it.
The node is routing-only
familyis carried over unchanged (build), so the/charly-build:settingsaddress still resolves.This skill carries no
triggers:, and carried none in the carrier either — so it generates noDISPATCHER.mdrow, and this move adds none and removes none. That is measured on the node, notasserted:
No inline
description:/content:either: a body inlined in a node can disagree with the file, whichthe marketplace generator refuses as a hard error, so the moved body stays in its file.
How tested
charly box validateat the repo root, on the committed tree, with the worktree-local binary(
charly version=2026.295.1709, matchingcharlysource HEAD9fd74793):That gate is the one that resolves a
skill:node's body: it fails withskill "<name>": no body — the node carries no in-linecontent:and no SKILL.md exists under .agents/skills at the repo root of the owning candy "<owner>"when the file is absent (measured on the sibling unit, opencharly/plugin-box#59,whose PR body pastes the failing run). The byte-identity proof above is the behavioural evidence for a
move: the published bytes are unchanged.
Not run, and why: no R10 bed and no image build. No runtime path executes on a skill file, no
plan:step changes, no provider word moves. The corpus leg (drop the carrier's ref, add this repo as acorpus source, regenerate) is a separate PR in
opencharly/marketplace, producer-first after this landsand tags;
charly marketplace generatecannot run here because this repo is not yet in the refs list.Rulebook compliance
/charly-internals:skills,/charly-internals:git-workflowand/charly-internals:cutover-policybefore the first edit; this repo's ownAGENTS.mdread beforeacting in it;
AGENTS.mdPart II fix(settings)!: ship a self-contained CUE schema (no schema-less plugin) #5 read as law.build family is a plugin repo's, not
charly's) rather than applied silently. Zero warnings is whatthe gate printed.
producer-first after this lands; no second copy is created to make the node look complete.
node it replaces is deleted with it in the carrier leg.
git status --shortwas empty before the branch; no force-push, no direct push tomain, nohook bypass.
sha256sumequality, and the gate's reach by the sibling unit'spasted failing run on the identical reader.
charly versionmatchesthe source HEAD.
Change classification
Documentation-only (skill relocation) — one authored
SKILL.mdarrives verbatim, one routing-onlyskill:node is added with its existingfamilyand notriggers:(it has none).The commit's
!marks the CUTOVER, not a runtime break. This commit is the ADD half of arelocation whose REMOVE half deletes the skill's node and its tree from
layer-charly-build, in thatrepo's own PR, producer-first after this lands. The authored home changes for the carrier even though
the published bytes are unchanged, and that is what the marker states — the change class above is what
the diff does to this repo, which is documentation-only. No runtime code, no schema, no
packages, no
plan:step, no service, no port, no OCI label. Gate:charly box validate(0 warnings,0 errors) plus the byte-identity proof.
Filed issues
family is a plugin repo's, not
charly's; two internals skills cannot be routed until the org-configrepo's role as a corpus source is decided. This PR implements one row of it.
A3 — attribution evidence, as delivered in this session
The runtime's own system message reads, verbatim:
and
Harness
DeepSeek Harness, modeldeepseek-v4.1-flash— the pair the footer names. This runtime is theone opencharly/opencharly#538 records as rejected by the validator's model allowlist even though it is
real and running; cited here so the A3 check can be read against that open defect rather than as an
unattributed model name.
Agent: charly
Assisted-by: DeepSeek Harness deepseek-v4.1-flash (documentation reviewed)