Summary
Workflow-skills from a plugin's defaults/workflow-skills/ and from an agent package's workflow-skills/ are projected to the same flat, global path — ~/.bakin/workflows/skills/<name>.md — keyed only by skill name. Two sources shipping a same-named skill (e.g. generate-image) collide, with no ownership tracking, no namespacing, and no drift detection.
How it bites (real)
~/.bakin/workflows/skills/generate-image.md is shipped by both:
- the core
images plugin (plugins/images/defaults/workflow-skills/generate-image.md), and
- the
pixel agent package (agents/pixel/workflow-skills/generate-image.md, in bakin-bits).
On this machine the slot was held by a stale third version from March (image_path/alt_text schema — neither current). It survived every server restart and was not refreshed by either source, because:
- Projection is seed-if-missing — the loader won't overwrite an existing file, so the first writer wins and a stale file persists indefinitely.
- These files carry no
.installedBy marker (unlike agent-package projections), so nothing tracks ownership or detects that the on-disk content has drifted from its source.
Net effect: the image-generation workflow can silently run an outdated/foreign generate-image skill, and updating either source doesn't fix it. (Had to hand-replace the file to recover.)
Desired
- Namespace workflow-skills by owner so two sources can't shadow each other — e.g.
~/.bakin/workflows/skills/<plugin-or-package-id>/<name>.md, or store the owner in the filename/frontmatter and resolve by (owner, name).
- Ownership + drift tracking (a
.installedBy-style marker, as agent-package projections already use) so the loader can: refresh on update, detect drift, and avoid clobbering genuine user edits.
- A precedence rule when a workflow references a skill name available from multiple owners (e.g. the workflow's own plugin wins; agent-package skills are agent-scoped, not global overrides).
- Stop seed-if-missing from silently preserving stale/foreign content for an owned skill.
Acceptance
- Two sources can ship a
generate-image skill without colliding.
- Updating a plugin/agent-package re-projects its workflow-skills (or flags drift) instead of leaving a stale file.
- A workflow deterministically resolves which
generate-image it runs.
Related: #384 (agent-package workspace templates have the same seed-once / no-reproject problem).
Summary
Workflow-skills from a plugin's
defaults/workflow-skills/and from an agent package'sworkflow-skills/are projected to the same flat, global path —~/.bakin/workflows/skills/<name>.md— keyed only by skill name. Two sources shipping a same-named skill (e.g.generate-image) collide, with no ownership tracking, no namespacing, and no drift detection.How it bites (real)
~/.bakin/workflows/skills/generate-image.mdis shipped by both:imagesplugin (plugins/images/defaults/workflow-skills/generate-image.md), andpixelagent package (agents/pixel/workflow-skills/generate-image.md, in bakin-bits).On this machine the slot was held by a stale third version from March (
image_path/alt_textschema — neither current). It survived every server restart and was not refreshed by either source, because:.installedBymarker (unlike agent-package projections), so nothing tracks ownership or detects that the on-disk content has drifted from its source.Net effect: the image-generation workflow can silently run an outdated/foreign
generate-imageskill, and updating either source doesn't fix it. (Had to hand-replace the file to recover.)Desired
~/.bakin/workflows/skills/<plugin-or-package-id>/<name>.md, or store the owner in the filename/frontmatter and resolve by(owner, name)..installedBy-style marker, as agent-package projections already use) so the loader can: refresh on update, detect drift, and avoid clobbering genuine user edits.Acceptance
generate-imageskill without colliding.generate-imageit runs.Related: #384 (agent-package workspace templates have the same seed-once / no-reproject problem).