Support custom skill roots and update React import in tests#925
Conversation
|
Thanks for the work — but I think this PR is solving a different problem than #870 actually asks for. The issue requests auto-loading from two known paths ( What's here is ~880 lines across CLI subcommands + Web UI text field + dashboard + new scope + tests — exactly the friction the issue author wanted to avoid. It also doesn't actually solve the stated problem: existing Two cleaner paths from here:
The React-import lint fix in |
I don't think we should directly index ~/.agents/skills, as I found that when using skills.sh, there isn't a ~/.agents/skills option. It's more common to have a skills directory unique to the CLI tool. I believe when users work with multiple CLIs, they might assign corresponding skills based on the performance of each CLI, and these skills are mostly located in the proprietary directories of the CLI tools. |
Users should have their own path selection, rather than fixed ~/.agents/skills |
|
Fair pushback — I'll grant that That said, I still don't want this PR's full shape. The surface — What I'd merge is a much smaller version:
That's roughly 30–50 lines total. Covers both #870's zero-friction case AND your "point me at my Claude skills" case, without the friction (or the UI surface) you and the issue author both flagged. Want to slim this PR down to that shape, or open a separate issue first so we can settle the scope before more work? The React-import fix in |
|
On reflection — let's just ship this. Your point about variance across agent CLIs is valid, tests are thorough, and the surface I was pushing back on is genuinely useful for the multi-CLI setup case. Thanks for pushing back, it was the right call. Merging now. I'll follow up with a tiny PR appending |
…870) (#932) * feat(skills): auto-discover .agents/skills as a default root Closes #870. The configurable-paths system from #925 lets users point at any directory, but a user with existing skills already sitting in `~/.agents/skills` or `<project>/.agents/skills` still has to find that setting and configure it — which is exactly the friction the original issue asked us to avoid. Append `.agents/skills` to the default discovery list in `SkillStore.roots()` at both project and global scope, alongside the existing `.reasonix/skills` entries. Anything sitting in the skills.sh-style convention now just works on first launch. * test(settings): make skillPaths absolute-path assertion platform-agnostic The combined-POST test from #925 asserts `resolved: "/opt/skills"` for an input of `/opt/skills`, which only holds on POSIX. On Windows `/opt/skills` isn't an absolute path — `path.resolve` rebases it against the current drive and returns `F:\opt\skills` (or whatever `CWD`'s drive is). Same behavior as the production code, just the test forgot to mirror it. Wrap the expected `resolved` in `resolve(absolute)` so both the production resolver and the test compute the value through the same function. Linux output unchanged. (This would have been caught by the matrix CI from #926, but #925's PR build ran a few minutes before that landed.) --------- Co-authored-by: reasonix <reasonix@deepseek.com>
…#925) * feat(skills): support custom skill roots * chore(tests): use type-only react import
…sengine#870) (esengine#932) * feat(skills): auto-discover .agents/skills as a default root Closes esengine#870. The configurable-paths system from esengine#925 lets users point at any directory, but a user with existing skills already sitting in `~/.agents/skills` or `<project>/.agents/skills` still has to find that setting and configure it — which is exactly the friction the original issue asked us to avoid. Append `.agents/skills` to the default discovery list in `SkillStore.roots()` at both project and global scope, alongside the existing `.reasonix/skills` entries. Anything sitting in the skills.sh-style convention now just works on first launch. * test(settings): make skillPaths absolute-path assertion platform-agnostic The combined-POST test from esengine#925 asserts `resolved: "/opt/skills"` for an input of `/opt/skills`, which only holds on POSIX. On Windows `/opt/skills` isn't an absolute path — `path.resolve` rebases it against the current drive and returns `F:\opt\skills` (or whatever `CWD`'s drive is). Same behavior as the production code, just the test forgot to mirror it. Wrap the expected `resolved` in `resolve(absolute)` so both the production resolver and the test compute the value through the same function. Linux output unchanged. (This would have been caught by the matrix CI from esengine#926, but esengine#925's PR build ran a few minutes before that landed.) --------- Co-authored-by: reasonix <reasonix@deepseek.com>
What
Adds configurable custom skill roots for Reasonix. Users can add, list, and remove custom skill paths from the CLI, configure the same paths from the Web UI settings page, and have those paths participate in skill discovery alongside project, global, and built-in skills. The implementation keeps the user-entered path text as the saved/displayed value while resolving paths internally for discovery, status checks, and deduplication.
Why
Fixes the workflow requested in issue #870: users need to reuse skills stored outside the built-in/project/global skill directories and manage those locations consistently across CLI and Web UI. This also fixes follow-up path handling issues so CLI-saved paths appear in Web UI settings, ~/... is resolved correctly for runtime use, and relative paths are not rewritten in the saved configuration.
How to verify
Run npm run verify.
In the CLI, run /skill paths add ~/.agents/skills/find-skills, then /skill paths and confirm the configured value remains ~/.agents/skills/find-skills while the resolved/status information points at the home directory.
Open the Web UI settings page and confirm the same skill path appears in the skills paths field.
Save comma-separated paths from the Web UI, then confirm /skill paths shows the same configured values in the CLI.
Confirm custom skills from those paths appear in /skill list, the Web UI skills panel, and are usable through the skill runner.
Checklist
npm run verifypasses locally (lint + typecheck + tests + comment-policy gate)Co-Authored-By: Claudetrailer in commitsCHANGELOG.md— release notes are maintainer-written at release time