doctor reports false 'unverifiable (no metadata)' warnings for skills excluded by .skillignore

[ipruning]

Summary

skillshare doctor appears to scan source skills using a discovery path that does not respect .skillignore.

As a result, directories that are intentionally excluded from discovery can still be treated as skills during doctor, which leads to false warnings such as:

Skill integrity: 1 skill(s) unverifiable (no metadata)

In my case, this happened because a vendored skill under a tracked repo's .venv/ directory was discovered by doctor, even though the repo root contains a .skillignore entry for .venv.

Reproduction

Example layout:

skills/
  _team-skills/
    .git/
    .skillignore   # contains: .venv
    .venv/
      lib/python3.13/site-packages/fastapi/.agents/skills/fastapi/SKILL.md

Run:

skillshare doctor

Observed output includes:

Skill integrity: 1 skill(s) unverifiable (no metadata)

Expected behavior

If a path is excluded by .skillignore, it should not be discovered as a source skill by doctor.

That means excluded directories should not contribute to:

• source skill counts
• integrity verification
• duplicate checks
• other diagnostics that operate on discovered source skills

Actual behavior

doctor still discovers SKILL.md files under ignored paths and then warns that they are "unverifiable (no metadata)".

This creates noise for repos that contain vendored/package-provided skills under ignored directories such as .venv.

Likely cause

There seems to be a mismatch between the two discovery implementations:

• install-side discovery applies .skillignore
• sync/doctor discovery does not

Relevant code paths:

• doctor uses sync.DiscoverSourceSkills(...)
• internal/sync/sync.go only skips .git
• .skillignore handling exists in internal/install/install_discovery.go

So .skillignore works for install discovery, but not for doctor/status/possibly other source-scanning commands.

Suggested fix

Make sync.DiscoverSourceSkills (and DiscoverSourceSkillsLite) respect .skillignore, ideally using shared discovery/filtering logic so install-time and runtime diagnostics stay consistent.

A regression test covering an ignored .venv/.../SKILL.md path would help prevent this from resurfacing.

Environment

• skillshare version: 0.17.3
• global source repo contains a tracked repo with .skillignore
• ignored path contains a non-skillshare-managed SKILL.md

[runkids]

Thanks for the report! I'll look into it.