Source: code-review of #31; nice-to-have, deferred at merge.
install.sh copies resources/<slug>/RESOURCE.md into <host>/hornero-resources/<slug>/RESOURCE.md and claims (in the install_resource_cards function comment) that this is "so installed skills can resolve relative cross-refs even when the repo checkout isn't on disk".
That claim doesn't hold. Skills reference resources via relative paths from their own location:
roles/product-manager/skills/hubspot-pipeline-readout/SKILL.md uses ../../../../resources/hubspot/RESOURCE.mdskills/query-warehouse/SKILL.md uses ../../resources/bigquery/RESOURCE.md
When installed, skills live at <host>/skills/<name>/SKILL.md. The resource cards live at <host>/hornero-resources/<slug>/RESOURCE.md — a sibling of <host>/skills/, not at the path the relative refs would resolve to. So the copy is decorative for cross-ref resolution; skill reading agents either have the repo or have broken relative links.
Three options, in increasing effort:
-
Accept the decoration: rewrite the function comment to say "the cards are for human browsing, not skill auto-resolution; skills bundle their own absolute pointer-paths". Cheapest fix.
-
Symlink-or-copy the cards into a path the skills' relative refs would resolve to: e.g. <host>/skills/_resources/<slug>/ (sibling of installed skills). Skill refs would still be wrong, but a build step could rewrite them at install time.
-
Migrate to a host-relative convention: introduce a placeholder like {{HORNERO_RESOURCES}}/linear/RESOURCE.md in skill prose; resolve at install time. Most work, cleanest result.
Files:
install.sh (the install_resource_cards function)- All skill SKILL.md files with
../../resources/ or ../../../../resources/ refs (about 6 today)
Risk: low — current behaviour works for repo-checkout use; only matters when someone installs the plugin and then loses access to the repo path. Defer until that's a real use case.
Source: code-review of #31; nice-to-have, deferred at merge.
install.shcopiesresources/<slug>/RESOURCE.mdinto<host>/hornero-resources/<slug>/RESOURCE.mdand claims (in theinstall_resource_cardsfunction comment) that this is "so installed skills can resolve relative cross-refs even when the repo checkout isn't on disk".That claim doesn't hold. Skills reference resources via relative paths from their own location:
roles/product-manager/skills/hubspot-pipeline-readout/SKILL.mduses../../../../resources/hubspot/RESOURCE.mdskills/query-warehouse/SKILL.mduses../../resources/bigquery/RESOURCE.mdWhen installed, skills live at
<host>/skills/<name>/SKILL.md. The resource cards live at<host>/hornero-resources/<slug>/RESOURCE.md— a sibling of<host>/skills/, not at the path the relative refs would resolve to. So the copy is decorative for cross-ref resolution; skill reading agents either have the repo or have broken relative links.Three options, in increasing effort:
Accept the decoration: rewrite the function comment to say "the cards are for human browsing, not skill auto-resolution; skills bundle their own absolute pointer-paths". Cheapest fix.
Symlink-or-copy the cards into a path the skills' relative refs would resolve to: e.g.
<host>/skills/_resources/<slug>/(sibling of installed skills). Skill refs would still be wrong, but a build step could rewrite them at install time.Migrate to a host-relative convention: introduce a placeholder like
{{HORNERO_RESOURCES}}/linear/RESOURCE.mdin skill prose; resolve at install time. Most work, cleanest result.Files:
install.sh(theinstall_resource_cardsfunction)../../resources/or../../../../resources/refs (about 6 today)Risk: low — current behaviour works for repo-checkout use; only matters when someone installs the plugin and then loses access to the repo path. Defer until that's a real use case.