[BUG] Skills directory does not work with symbolic linked files.

[EmBeaux]

Problem (one or two sentences)

I have my skills in a github repository and shared with my team. I sym linked those skills from the local instance of my repo to my .roo/skills folder. This resulted in all sym linked skills not being registered by roo.

Context (who is affected and when)

All developers who attempt to use sym link to register their skills.

Reproduction steps

1. Mac OS on VS Code
2. navigate to root
3. mkdir -p REPO/skills
4. touch REPO/skills/SKILL-TEST.md
5. set up SKILL-TEST.md to skill standards
6. cd .roo/skills
7. ln -s ../../REPO/skills
8. ls .roo/skills
9. You should see the sym linked skill SKILL-TEST.md
10. go to vs code > roo settings > skills

Expected result

SKILL-TEST is a skill

Actual result

No skills are present

Variations tried (optional)

I have fixed this by manually copying the file and putting them in the skills folder. I would like sym linking to work. Sym linking does work for rules.

App Version

3.47.3

API Provider (optional)

OpenAI

Model Used (optional)

N/A

Roo Code Task Links (optional)

https://app.roocode.com/share/c3d03812-84a9-4de4-bf3d-1ed430f9d496

Relevant logs or errors (optional)

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root cause analysis:

The reproduction steps show creating a symlink like cd .roo/skills && ln -s ../../REPO/skills, which creates .roo/skills/skills -> ../../REPO/skills. This results in an extra level of nesting that the skills scanner doesn't handle. The scanner (scanSkillsDirectory in src/services/skills/SkillsManager.ts) only looks one level deep: it reads entries in .roo/skills/, checks if each entry is a directory, and looks for SKILL.md inside it. When a symlinked entry is itself a container of multiple skill directories (rather than a single skill directory), the scanner misses them.

In contrast, the rules system (readTextFilesFromDirectory in src/core/prompts/sections/custom-instructions.ts) uses readdir with withFileTypes: true and has dedicated resolveSymLink/resolveDirectoryEntry helpers that recursively resolve symlinked directories. This is why "sym linking does work for rules" as the issue author notes.

Proposed changes:

1. Modify scanSkillsDirectory in src/services/skills/SkillsManager.ts: When a directory entry inside the skills directory does NOT contain SKILL.md, recursively scan it as a potential container of skill subdirectories (with depth limiting to prevent circular symlink issues). This handles the common pattern of symlinking a directory of skills into .roo/skills/.

2. Switch readdir to use withFileTypes: true for explicit symlink detection, similar to how the rules system works. Use lstat where appropriate to differentiate between symlinks and regular directories.

3. Add depth-limited recursion (max 3-5 levels) to handle nested symlinks while preventing infinite loops from circular symlinks.

4. Add tests for the new scenarios:

   • Symlinked directory containing multiple skill subdirectories
   • Nested symlinks with depth limiting
   • Broken symlinks (graceful handling)

This approach aligns the skills symlink handling with the proven rules system while maintaining backward compatibility with existing skill directory structures.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.