René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Design source canonicalization for multi-skill standalone repo adds","articleBody":"## Problem\nStandalone skill URLs now install correctly, but adding multiple skills from the same repository can leave config in an ambiguous state.\n\nExample starting point:\n```yaml\nplugins:\n  - source: https://github.com/NousResearch/hermes-agent/tree/main/skills/research/llm-wiki\n    skills:\n      - llm-wiki\n```\n\nIf a later command adds another skill from the same repo, the system currently has no clear canonicalization strategy for whether the source should remain the deep skill URL or be promoted to a broader container path.\n\n## Goal\nDefine and implement canonical source promotion for repeated skill adds from the same repo, without expanding the config schema.\n\n## Desired behavior\nWhen multiple skills are added from the same repo, rewrite the stored `source` to the smallest shared container that can express all enabled skills. For example:\n- if all enabled skills are under `skills/research/`, promote to `.../tree/main/skills/research`\n- otherwise, if all are under `skills/`, promote to `.../tree/main/skills`\n- otherwise, promote to the smallest valid plugin/repo root needed\n\nThe resulting config should continue to use the existing model:\n- `plugins[].source`\n- `plugins[].skills` allowlist\n\n## Constraints\n- Do not add new config fields if avoidable\n- Preserve existing plugin and marketplace behavior\n- Avoid duplicate plugin entries for the same GitHub repo identity\n- Keep `skill add`, `skill remove`, `skill list`, and sync behavior coherent after promotion\n\n## Areas to inspect\n- `src/cli/commands/plugin-skills.ts`\n- `src/core/workspace-modify.ts`\n- `src/core/skills.ts`\n- config dedupe / plugin identity logic\n\n## Suggested acceptance criteria\n1. Starting from a deep standalone skill URL, adding a sibling skill from the same subtree rewrites `source` to the shared subtree path\n2. Adding a skill from a different subtree in the same repo rewrites `source` to the next valid shared container\n3. No duplicate plugin entries are created for the same repo identity\n4. Existing follow-up operations continue to work after promotion\n5. Add unit and E2E coverage for canonicalization/promotion cases\n\n## Context\nPR #406 intentionally fixed standalone skill URL installation only. The canonicalization/promotion behavior was left for follow-up because it is a design change, not just a bug fix.","author":{"url":"https://github.com/christso","@type":"Person","name":"christso"},"datePublished":"2026-05-19T10:17:41.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/407/allagents/issues/407"}