Part of epic #391 (skill import + skill-aware Builder). Split out for separate
tracking. Applies to skills created any way — imported, pasted, or authored live in
the Builder chat — and to the onboarding offer (#396), where imported skills especially
must not be frozen.
Summary
However a skill was created, its content must stay viewable and editable afterwards,
through one consistent editor, everywhere a skill appears. Today that is only partly true.
This issue captures the gaps and proposes the missing functions and UI.
This is a concept, not an implementation plan.
Why
A skill is long-lived: it gets refined, corrected, and reused across agents. If a user can
create a skill but not later open and change it — or can only edit some skills, in one
place — the skill stops being a durable, trustable asset. This holds for every creation
path in epic #391 (import, paste, live authoring) and for the onboarding import offer
(#396).
Current state (verified gaps)
- The admin node-graph Builder already has a per-node inspector that edits a skill's
name and body — but it covers only host-authored skills. An imported
(source: file) skill is read-only there and cannot be edited.
- There is no central place to manage skills: no screen to list every skill, read its
frontmatter + body, see which agents use it, edit, delete, or export. Skills are only
reachable as nodes on a canvas.
- The conversational (spec/slot) Builder — the surface where the size pain happens —
has no skill view/edit affordance at all. A skill just authored or attached there
cannot be inspected without switching to the node-graph builder.
Proposed
- One skill content editor (frontmatter + body) reused everywhere a skill appears — the
node-graph inspector, the conversational Builder, and a central registry view — so editing
behaves identically regardless of how the skill was created. One editor, not several.
- Editing works for imported skills too.
source: file skills must not be frozen:
editing forks the import into an editable host copy while preserving provenance
(source / source_path).
- A skills management view — the registry as a first-class screen: list, search,
open-to-edit, "used by N agents", delete, and export back to SKILL.md for
portability.
- Re-version on change with content-hash identity (cf. Kemia's content-addressed
Profile-Bundle), so edits and re-imports converge instead of duplicating.
Principles
- Editable in every scenario — created however you like, edited the same way.
- One editor, not two — the same content editor wherever a skill is shown.
- Provenance preserved — editing an imported skill keeps its origin recorded.
- No size / slot vocabulary — same invisible-size posture as the rest of the epic.
Feasibility anchors in omadia
- The skills registry already stores name, description, body, frontmatter,
source
and source_path, and the API already supports update/patch — so editing is an existing
capability to extend, not invent.
- The admin builder's node inspector already implements a skill name/body editor — the
shared editor can grow from it. The work is mainly (a) lifting it into a reusable surface,
(b) removing the imported-skill read-only limitation via fork-to-host-copy, and (c) adding
a central management screen.
Non-goals
Open questions
- Edit semantics for imported skills: edit in place, or fork to an editable host copy
that preserves provenance — and what happens to the link when the upstream file changes?
- Where the management view lives: admin, operator, or both — and how it relates to the
existing node-graph inspector so there is one editor, not two.
- Versioning: is content-hash re-versioning enough, or do skills need explicit version
history / rollback?
Related
Summary
However a skill was created, its content must stay viewable and editable afterwards,
through one consistent editor, everywhere a skill appears. Today that is only partly true.
This issue captures the gaps and proposes the missing functions and UI.
This is a concept, not an implementation plan.
Why
A skill is long-lived: it gets refined, corrected, and reused across agents. If a user can
create a skill but not later open and change it — or can only edit some skills, in one
place — the skill stops being a durable, trustable asset. This holds for every creation
path in epic #391 (import, paste, live authoring) and for the onboarding import offer
(#396).
Current state (verified gaps)
name and body — but it covers only host-authored skills. An imported
(
source: file) skill is read-only there and cannot be edited.frontmatter + body, see which agents use it, edit, delete, or export. Skills are only
reachable as nodes on a canvas.
has no skill view/edit affordance at all. A skill just authored or attached there
cannot be inspected without switching to the node-graph builder.
Proposed
node-graph inspector, the conversational Builder, and a central registry view — so editing
behaves identically regardless of how the skill was created. One editor, not several.
source: fileskills must not be frozen:editing forks the import into an editable host copy while preserving provenance
(
source/source_path).open-to-edit, "used by N agents", delete, and export back to
SKILL.mdforportability.
Profile-Bundle), so edits and re-imports converge instead of duplicating.
Principles
Feasibility anchors in omadia
sourceand
source_path, and the API already supports update/patch — so editing is an existingcapability to extend, not invent.
shared editor can grow from it. The work is mainly (a) lifting it into a reusable surface,
(b) removing the imported-skill read-only limitation via fork-to-host-copy, and (c) adding
a central management screen.
Non-goals
Open questions
that preserves provenance — and what happens to the link when the upstream file changes?
existing node-graph inspector so there is one editor, not two.
history / rollback?
Related