fix(skills): align skills API with TUI command multi-directory discovery

[gaord]

Summary

The /v1/skills API endpoint only searched a single directory (resolve_skills_dir), while the TUI's /skills command uses discover_for_workspace_and_dir() to search multiple directories (workspace-local + global). This means the API would miss skills installed in ~/.claude/skills, ~/.agents/skills, workspace .agents/skills, etc.

Changes

• Use discover_for_workspace_and_dir() in both list_skills and set_skill_enabled handlers, matching the TUI /skills command behavior
• Add is_bundled field to SkillEntry — identifies built-in skills via is_bundled_skill_name(), allowing clients to distinguish user skills from bundled skills
• Add directories field to SkillsResponse — returns all searched directories so clients know where skills come from
• Use skill.path instead of constructing path from skills_dir + name, since skills may come from different directories
• Remove unused SkillRegistry import

Before

{
  "directory": "/Users/user/.codewhale/skills",
  "warnings": [],
  "skills": [
    { "name": "delegate", "description": "...", "path": "/Users/user/.codewhale/skills/delegate/SKILL.md", "enabled": true }
  ]
}

Only skills under ~/.codewhale/skills were discoverable.

After

{
  "directory": "/Users/user/.codewhale/skills",
  "directories": [
    "/Users/user/project/.agents/skills",
    "/Users/user/.agents/skills",
    "/Users/user/.claude/skills",
    "/Users/user/.codewhale/skills",
    "/Users/user/.deepseek/skills"
  ],
  "warnings": [],
  "skills": [
    { "name": "delegate", "description": "...", "path": "/Users/user/.codewhale/skills/delegate/SKILL.md", "enabled": true, "is_bundled": true },
    { "name": "my-custom-skill", "description": "...", "path": "/Users/user/.claude/skills/my-custom-skill/SKILL.md", "enabled": true, "is_bundled": false }
  ]
}

Skills from all configured directories are now discoverable, matching TUI behavior.

Test plan

• Verify /v1/skills returns skills from ~/.claude/skills, ~/.agents/skills, etc.
• Verify is_bundled is true for built-in skills (delegate, documents, pdf, etc.)
• Verify directories lists all existing skill directories
• Verify set_skill_enabled works for skills from any directory
• Verify set_skill_enabled returns 404 for non-existent skills

Greptile Summary

This PR aligns the /v1/skills API with the TUI /skills command by switching from single-directory discovery (SkillRegistry::discover) to multi-directory discovery (discover_for_workspace_and_dir), and enriches the response with an is_bundled field per skill entry and a directories field listing all searched paths.

• list_skills and set_skill_enabled both adopt discover_for_workspace_and_dir, so the API and TUI now share the same multi-directory search logic.
• SkillEntry gains is_bundled (via is_bundled_skill_name), and SkillsResponse gains directories (via skills_directories), but directories is computed independently and does not include the custom configured skills_dir when it falls outside the standard hierarchy — meaning skills from a non-standard configured path can appear in the response while that path is missing from directories.

Confidence Score: 3/5

The change is largely correct and improves parity with the TUI, but the directories response field can silently omit the custom configured skills directory while still surfacing skills from it, leaving clients with an inconsistent picture of where skills come from.

The core discovery logic (discover_for_workspace_and_dir, is_bundled_skill_name) is sound and well-tested elsewhere. The mismatch between discover_for_workspace_and_dir's actual search set and the directories field produced by the independent skills_directories() call is a present defect: in any deployment where config.skills_dir() resolves to a path outside the standard hierarchy, the API response will contain skills whose origin directory is absent from directories, which is the new field's sole purpose.

crates/tui/src/runtime_api.rs — specifically the list_skills handler where directories is built independently of the actual search path set used by discover_for_workspace_and_dir.

Important Files Changed

Filename	Overview
crates/tui/src/runtime_api.rs	Switches skills discovery in list_skills and set_skill_enabled to discover_for_workspace_and_dir, adds is_bundled per entry and directories to the response, but directories is computed from skills_directories alone and will omit any custom skills_dir that is outside the standard hierarchy — creating a mismatch between the advertised directory list and the actual search paths used.

Sequence Diagram

sequenceDiagram
    participant Client
    participant API as /v1/skills (list_skills)
    participant RSD as resolve_skills_dir()
    participant DWD as discover_for_workspace_and_dir()
    participant SD as skills_directories()
    participant SS as skill_state (lock)

    Client->>API: GET /v1/skills
    API->>RSD: config + workspace
    RSD-->>API: skills_dir (workspace-local or config default)
    API->>DWD: workspace + skills_dir
    DWD->>SD: workspace → standard dirs
    SD-->>DWD: [.agents/skills, .claude/skills, ~/.codewhale/skills, ...]
    DWD->>DWD: append skills_dir if not in standard dirs
    DWD-->>API: merged SkillRegistry
    API->>SS: lock()
    API->>SD: workspace → standard dirs only (⚠ missing custom skills_dir)
    SD-->>API: directories list (may be incomplete)
    API-->>Client: "SkillsResponse { directory, directories, skills[{is_bundled,...}], warnings }"

Loading

_{Reviews (1): Last reviewed commit: "fix(skills): align skills API with TUI c..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

[gemini-code-assist]

Code Review

This pull request updates the runtime API to support multiple skill directories and bundled skills. It adds a directories field and an is_bundled flag to the skills response, and updates skill discovery to search across the workspace. A review comment points out that the directories list returned in the API response might omit a custom skills_dir if it is not already part of the default workspace directories, and suggests appending it to ensure consistency with the actual search paths.

[gemini-code-assist]

The directories list returned in SkillsResponse is populated using crate::skills::skills_directories(&state.workspace). However, discover_for_workspace_and_dir also searches skills_dir (the primary configured/resolved skills directory) and appends it to the search paths if it is not already present.

If a user has configured a custom skills_dir that is not in the default workspace/global candidate list, it will be searched for skills, but it will be missing from the directories field in the API response.

To ensure the returned directories list accurately reflects all directories that were actually searched, we should append skills_dir to directories if it is a valid directory and not already present, matching the behavior of discover_for_workspace_and_dir.

    let mut directories = crate::skills::skills_directories(&state.workspace);
    if skills_dir.is_dir() && !directories.contains(&skills_dir) {
        directories.push(skills_dir.clone());
    }

[greptile-apps]

directories omits the custom skills_dir

skills_directories(&state.workspace) returns only the standard workspace/global candidate directories, but discover_for_workspace_and_dir internally appends skills_dir when it is not already in that set (see discover_for_workspace_dirs_and_dir). When a user has configured a non-standard config.skills_dir() (e.g. a path outside the well-known ~/.codewhale/skills, ~/.agents/skills, etc. hierarchy), the registry will contain skills from that directory but directories will not list it. Clients relying on the directories field to know where a skill came from will have an incomplete picture, and the advertised contract ("returns all searched directories") will silently be broken.

A straightforward fix is to mirror the same append logic used in discover_for_workspace_dirs_and_dir when building the directories list:

let mut directories = crate::skills::skills_directories(&state.workspace);
if skills_dir.is_dir() && !directories.iter().any(|p| p == &skills_dir) {
    directories.push(skills_dir.clone());
}

[greptile-apps]

404 message loses search-path context

The previous error text included the directory being searched ("skill '{name}' not found under {skills_dir}"), which was directly useful for debugging misconfigurations. Now that skills come from multiple directories, the directory context is even more valuable (the user can't know which of the several searched paths was checked). The simplified "skill '{name}' not found" message gives clients no actionable context.