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

New issue

Closed

opened 2026-09-30 23:43:05 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-09-30 23:43:05 +01:00

Contributor

Make allod skill list the skills of every memory repository the registry marks, so a deployment's private memory skills appear in the same default list as the public ones.

Part of the memory-skills arc (this issue is the arc home):

allod/tools (this issue) — registry-derived default sources (this issue)
allod/memory#CHILD — public skill descriptions get a one-line lead
vnprc/agent-memory#CHILD — private fork adopts the registry flag and the description lead

Primary goals:

Registry-derived defaults — 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; the hardcoded allod/memory default goes away.
Private skills on the list — once a deployment registers its private memory fork with the same flag, its skills show up in bare allod skill and resolve for allod skill <name> with no extra flags.
Registry ids win over relative paths — target resolution consults the registry before treating the argument as a directory, so allod skill run from ~/work lists skills instead of scanning the allod/memory checkout root.
Deterministic output — sources are walked in sorted registry-id order, and a skill name reachable from two sources prints once.

Current state and specifics

cmd/allod/skill.go:99-114 (origin/master): resolveSkillDirs defaults targets to the single registry id allod/memory, and stats each target as a directory before consulting the registry. Run from ~/work, the default id names an existing relative directory, so it is used as the skills directory itself: every checkout-root subdirectory (.git, adapters, skills, …) is named on stderr as lacking a SKILL.md and the command exits 1 with "no skills found". From ~/work/allod the same command works.
cmd/allod/registry.go:10-14: registryEntry lacks the memory field allod/inventory#20 introduced; add Memory bool with the json:"memory" tag. registryEntries (registry.go:60-68) already tolerates a missing or malformed registry.
skillList (skill.go:44-52) prints one line per skill per directory with no cross-source dedupe; skillShow (skill.go:67-87) already dedupes first-seen. Sorted registry-id order makes both deterministic; today allod/memory sorts before a deployment's private fork, so public skills list first. Name collisions: first in that order wins; say so in the usage text.
Default-sweep semantics: a memory-marked checkout missing on disk is skipped silently — vm-specs repos lists govern which machines clone which repos, and allod skill must not fail because one memory repo is not checked out here. Explicit --from behavior is unchanged.
When the registry yields no memory-marked entries (no inventory checkout, standalone use), fall back to the current single-id default so the command still works outside a full deployment.
The deployment's private repo (vnprc/agent-memory, checkout agent-memory) already keeps skills/ with four skills; today they are reachable only as --from agent-memory/skills. Its registry registration is deployment work tracked in the private child issue.
skillUsageText and the README line "Defaults to allod/memory" need updating to describe the registry-derived default.

Scope

In scope: resolveSkillDirs default-source derivation and resolution order, the registryEntry.memory field, deterministic ordering and dedupe in skillList, usage-text and README updates, tests. Out of scope: any change to briefLimit or description content (the child issues own the description shape); CLI-side enforcement of description length; the harness memory-bootstrap transition (allod/archetypes#124, already merged).

Validation

Unit tests: a registry with two memory-marked entries lists both checkouts' skills in sorted order; a missing checkout is skipped; a registry id that also exists as a relative directory still resolves through the registry; a duplicate skill name prints once and allod skill <name> resolves to the first source.
By hand: allod skill from ~/work and from ~/work/allod both list the public skills with no stderr noise; after the private fork is registered, its four skills appear in the same list.

Make `allod skill` list the skills of every memory repository the registry marks, so a deployment's private memory skills appear in the same default list as the public ones. Part of the memory-skills arc (this issue is the arc home): - [ ] allod/tools (this issue) — registry-derived default sources (this issue) - [ ] allod/memory#CHILD — public skill descriptions get a one-line lead - [ ] vnprc/agent-memory#CHILD — private fork adopts the registry flag and the description lead Primary goals: - **Registry-derived defaults** — 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; the hardcoded `allod/memory` default goes away. - **Private skills on the list** — once a deployment registers its private memory fork with the same flag, its skills show up in bare `allod skill` and resolve for `allod skill <name>` with no extra flags. - **Registry ids win over relative paths** — target resolution consults the registry before treating the argument as a directory, so `allod skill` run from `~/work` lists skills instead of scanning the `allod/memory` checkout root. - **Deterministic output** — sources are walked in sorted registry-id order, and a skill name reachable from two sources prints once. ### Current state and specifics - `cmd/allod/skill.go:99-114` (origin/master): `resolveSkillDirs` defaults targets to the single registry id `allod/memory`, and stats each target as a directory before consulting the registry. Run from `~/work`, the default id names an existing relative directory, so it is used as the skills directory itself: every checkout-root subdirectory (`.git`, `adapters`, `skills`, …) is named on stderr as lacking a SKILL.md and the command exits 1 with "no skills found". From `~/work/allod` the same command works. - `cmd/allod/registry.go:10-14`: `registryEntry` lacks the `memory` field allod/inventory#20 introduced; add `Memory bool` with the `json:"memory"` tag. `registryEntries` (`registry.go:60-68`) already tolerates a missing or malformed registry. - `skillList` (`skill.go:44-52`) prints one line per skill per directory with no cross-source dedupe; `skillShow` (`skill.go:67-87`) already dedupes first-seen. Sorted registry-id order makes both deterministic; today `allod/memory` sorts before a deployment's private fork, so public skills list first. Name collisions: first in that order wins; say so in the usage text. - Default-sweep semantics: a memory-marked checkout missing on disk is skipped silently — vm-specs `repos` lists govern which machines clone which repos, and `allod skill` must not fail because one memory repo is not checked out here. Explicit `--from` behavior is unchanged. - When the registry yields no memory-marked entries (no inventory checkout, standalone use), fall back to the current single-id default so the command still works outside a full deployment. - The deployment's private repo (`vnprc/agent-memory`, checkout `agent-memory`) already keeps `skills/` with four skills; today they are reachable only as `--from agent-memory/skills`. Its registry registration is deployment work tracked in the private child issue. - `skillUsageText` and the README line "Defaults to `allod/memory`" need updating to describe the registry-derived default. ### Scope In scope: `resolveSkillDirs` default-source derivation and resolution order, the `registryEntry.memory` field, deterministic ordering and dedupe in `skillList`, usage-text and README updates, tests. Out of scope: any change to `briefLimit` or description content (the child issues own the description shape); CLI-side enforcement of description length; the harness memory-bootstrap transition (allod/archetypes#124, already merged). ### Validation - Unit tests: a registry with two memory-marked entries lists both checkouts' skills in sorted order; a missing checkout is skipped; a registry id that also exists as a relative directory still resolves through the registry; a duplicate skill name prints once and `allod skill <name>` resolves to the first source. - By hand: `allod skill` from `~/work` and from `~/work/allod` both list the public skills with no stderr noise; after the private fork is registered, its four skills appear in the same list.

vnprc-agent referenced this issue from allod/memory

2026-09-30 23:43:30 +01:00

Give every skill description a one-line lead the skill list can show in full #76

vnprc-agent commented

2026-09-30 23:44:07 +01:00

Author

Contributor

Arc task list (filling in the child numbers):

allod/tools#259 — registry-derived default sources (this issue)
allod/memory#76 — public skill descriptions get a one-line lead
vnprc/agent-memory#31 — private fork adopts the registry flag and the description lead

Arc task list (filling in the child numbers): - [ ] allod/tools#259 — registry-derived default sources (this issue) - [ ] allod/memory#76 — public skill descriptions get a one-line lead - [ ] vnprc/agent-memory#31 — private fork adopts the registry flag and the description lead