allod skill: derive the default skill sources from the registry's memory flag #262

Merged

vnprc merged 3 commits from agent/skill-registry-default-sources into master

2026-10-01 00:47:23 +01:00

allod-agent commented

2026-10-01 00:30:19 +01:00

Member

Closes allod/tools#259
Refs allod/memory#76

What

allod skill now derives its default sources from the registry instead of the hardcoded allod/memory id:

With no --from, the CLI lists skills from every scripts/repositories.json entry carrying "memory": true (allod/inventory#20) whose checkout exists under the work directory, walked in sorted registry-id order. Once a deployment registers its private memory fork with the same flag, its skills appear in the bare list and resolve for allod skill <name> with no extra flags.
A memory-marked checkout missing on disk is skipped silently — vm-specs repos lists govern which machines clone which repos.
When the registry yields no memory-marked entries (no inventory checkout, standalone use), the single allod/memory default remains: the id maps to its own checkout's skills/ directory.
Target resolution consults the registry before treating an argument as a directory, so bare allod skill run from ~/work lists skills instead of scanning the allod/memory checkout root (the old failure: every checkout-root subdirectory named on stderr, exit 1).
A skill name reachable from several sources lists once, from the first source in resolved order; skillShow already resolved that way, and sorted registry-id order makes both deterministic.
Usage text and the README line updated; registryEntry gains Memory bool.

Explicit --from semantics are unchanged.

Risk

The fallback refusal changed shape: a registry that marks no memory repos with no skills on disk now exits 1 with "no skills found" instead of naming allod/memory. The old TestSkillDefaultRefusesWhenRegistryLacksMemoryRepo assertion was updated accordingly.
An explicit --from <registry-id> whose checkout is missing on disk now fails later, in readSkills ("cannot read skills directory …") rather than at resolution ("unknown skills target …") — same exit path, different message.
Description shape is not enforced here; a description without a sub-100-character lead still truncates with an ellipsis until allod/memory#76 lands (its branch already shows the new leads, so the two PRs together produce full lines).

Validation

go test ./cmd/allod/ green, go vet clean, gofmt clean. New tests: two memory-marked entries list in sorted registry-id order with silent stderr; a missing checkout is skipped; a registry id that also exists as a relative directory resolves through the registry (t.Chdir replica of the ~/work case); no memory-marked entries falls back to allod/memory; no skills on disk fails with the no-skills refusal; a duplicate name lists once and allod skill <name> resolves to the first source.
By hand (fresh build): bare allod skill from ~/work and ~/work/allod lists the six public skills with empty stderr; with a fixture registry marking a private fork memory: true, its skill appears in the same list and allod skill <name> prints it. Ellipses remain until allod/memory#76 lands and checkouts pull.

Closes allod/tools#259 Refs allod/memory#76 ## What `allod skill` now derives its default sources from the registry instead of the hardcoded `allod/memory` id: - With no `--from`, the CLI lists skills from every `scripts/repositories.json` entry carrying `"memory": true` (allod/inventory#20) whose checkout exists under the work directory, walked in sorted registry-id order. Once a deployment registers its private memory fork with the same flag, its skills appear in the bare list and resolve for `allod skill <name>` with no extra flags. - A memory-marked checkout missing on disk is skipped silently — vm-specs `repos` lists govern which machines clone which repos. - When the registry yields no memory-marked entries (no inventory checkout, standalone use), the single `allod/memory` default remains: the id maps to its own checkout's `skills/` directory. - Target resolution consults the registry before treating an argument as a directory, so bare `allod skill` run from `~/work` lists skills instead of scanning the `allod/memory` checkout root (the old failure: every checkout-root subdirectory named on stderr, exit 1). - A skill name reachable from several sources lists once, from the first source in resolved order; `skillShow` already resolved that way, and sorted registry-id order makes both deterministic. - Usage text and the README line updated; `registryEntry` gains `Memory bool`. Explicit `--from` semantics are unchanged. ## Risk - The fallback refusal changed shape: a registry that marks no memory repos with no skills on disk now exits 1 with "no skills found" instead of naming `allod/memory`. The old `TestSkillDefaultRefusesWhenRegistryLacksMemoryRepo` assertion was updated accordingly. - An explicit `--from <registry-id>` whose checkout is missing on disk now fails later, in `readSkills` ("cannot read skills directory …") rather than at resolution ("unknown skills target …") — same exit path, different message. - Description shape is not enforced here; a description without a sub-100-character lead still truncates with an ellipsis until allod/memory#76 lands (its branch already shows the new leads, so the two PRs together produce full lines). ## Validation - `go test ./cmd/allod/` green, `go vet` clean, `gofmt` clean. New tests: two memory-marked entries list in sorted registry-id order with silent stderr; a missing checkout is skipped; a registry id that also exists as a relative directory resolves through the registry (`t.Chdir` replica of the `~/work` case); no memory-marked entries falls back to `allod/memory`; no skills on disk fails with the no-skills refusal; a duplicate name lists once and `allod skill <name>` resolves to the first source. - By hand (fresh build): bare `allod skill` from `~/work` and `~/work/allod` lists the six public skills with empty stderr; with a fixture registry marking a private fork `memory: true`, its skill appears in the same list and `allod skill <name>` prints it. Ellipses remain until allod/memory#76 lands and checkouts pull.

allod-agent added 1 commit

2026-10-01 00:30:19 +01:00

skill: derive the default sources from the registry's memory flag 0e3317c10c

With no --from, the CLI now lists skills from every repositories.json
entry carrying "memory": true whose checkout exists under the work
directory, in sorted registry-id order; the hardcoded allod/memory default
remains only as the fallback for standalone use with no memory-marked
entries. A memory-marked checkout missing on disk is skipped silently.

Target resolution consults the registry before treating an argument as a
directory, so bare allod skill run from ~/work lists skills instead of
scanning the allod/memory checkout root. A skill name reachable from
several sources now lists once, from the first source in resolved order,
which skillShow already resolved the same way.

allod-agent added 2 commits

2026-10-01 00:44:19 +01:00

skill: derive the default sources from the registry's memory flag 0df9b47e29

With no --from, the CLI now lists skills from every repositories.json
entry carrying "memory": true whose checkout exists under the work
directory, in sorted registry-id order; the hardcoded allod/memory default
remains only as the fallback for standalone use with no memory-marked
entries. A memory-marked checkout missing on disk is skipped silently.

Target resolution consults the registry before treating an argument as a
directory, so bare allod skill run from ~/work lists skills instead of
scanning the allod/memory checkout root. A skill name reachable from
several sources now lists once, from the first source in resolved order,
which skillShow already resolved the same way.

Merge origin/agent/skill-registry-default-sources after rebasing onto master c0e49e26d4

The branch was rebased onto origin/master (master's comment cuts touched
the same skill.go regions), but the forge refuses force-pushes on agent/*
branches, so the rebased history cannot replace the pushed one. The rebased
tree already contains both sides' changes, so this merge records the history
graft while keeping the rebased tree exactly.