Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix skills tap add accepts custom git repos that search/install cannot actually use [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#14290•Fetched 2026-04-23 07:45:45
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
0
Author
ma-ponyma-pony
Participants
ma-ponyma-pony
Timeline (top)
labeled ×4cross-referenced ×2

Error Message

hermes skills tap add [email protected]:crawl/spider-skills.git hermes skills search spider-kit

No skills found matching your query.

hermes skills inspect [email protected]:crawl/spider-skills.git/skills/spider-kit

Error: Could not find ... in any source.

Root Cause

From the current implementation in tools/skills_hub.py:

  • TapsManager.add() stores arbitrary {repo, path} values in taps.json
  • but GitHubSource later assumes taps are GitHub repos in owner/repo form
  • search/listing uses https://api.github.com/repos/{repo}/contents/{path}
  • inspect/fetch identifiers are parsed as owner/repo/path/to/skill-dir

So tap add currently accepts a broader input surface than the backend actually supports.

Fix Action

Fixed

PR fix notes

PR #14299: fix(skills): reject unsupported tap repositories

Description (problem / solution / changelog)

Summary

  • validate custom tap repos before saving them to taps.json
  • normalize supported github.com URL and SSH forms to owner/repo slugs
  • reject unsupported non-GitHub repos with a clear CLI error instead of accepting unusable taps

Testing

  • python3 -m pytest -o addopts='' tests/tools/test_skills_hub.py tests/hermes_cli/test_skills_hub.py

Fixes #14290

Changed files

  • hermes_cli/skills_hub.py (modified, +6/-1)
  • tests/hermes_cli/test_skills_hub.py (modified, +11/-1)
  • tests/tools/test_skills_hub.py (modified, +12/-0)
  • tools/skills_hub.py (modified, +33/-0)

PR #14416: fix(skills): reject unsupported custom taps

Description (problem / solution / changelog)

Summary

Fixes #14290.

This prevents hermes skills tap add from accepting custom git repositories that the current skills hub backend cannot actually search, inspect, or install from.

Root cause

TapsManager.add() persisted arbitrary repo strings, but GitHubSource later treats taps as owner/repo GitHub repositories and resolves them through the GitHub Contents API. A self-hosted SSH git URL could therefore be accepted successfully, then silently produce no results during skills search / inspect / install.

Fix

  • Normalize supported GitHub tap inputs to owner/repo.
  • Accept owner/repo, https://github.com/owner/repo(.git), and [email protected]:owner/repo.git.
  • Reject generic or self-hosted git URLs with an actionable error explaining that generic git taps are not supported yet.
  • Have the CLI print that validation error instead of writing an unusable tap entry.

This is intentionally the minimal compatibility fix. Generic git tap support would need a separate clone/cache/index implementation rather than the current GitHub API-backed source adapter.

Validation

  • /Users/stephenyu/Documents/hermes-agent/.venv/bin/python -m pytest tests/tools/test_skills_hub.py::TestTapsManager::test_normalize_github_tap_repo_accepts_owner_repo tests/tools/test_skills_hub.py::TestTapsManager::test_normalize_github_tap_repo_accepts_github_urls tests/tools/test_skills_hub.py::TestTapsManager::test_normalize_github_tap_repo_rejects_self_hosted_git tests/tools/test_skills_hub.py::TestTapsManager::test_add_new_tap tests/tools/test_skills_hub.py::TestTapsManager::test_add_normalizes_github_url tests/hermes_cli/test_skills_hub.py::test_do_tap_add_rejects_self_hosted_git_repo -q --tb=short
  • /Users/stephenyu/Documents/hermes-agent/.venv/bin/python -m pytest tests/tools/test_skills_hub.py -k 'TapsManager or CreateSourceRouter or UnifiedSearchDedup' -q --tb=short
  • /Users/stephenyu/Documents/hermes-agent/.venv/bin/python -m pytest tests/hermes_cli/test_skills_hub.py -k 'tap or do_install_scans_with_resolved_identifier or do_list or do_check or do_update' -q --tb=short
  • git diff --check

Changed files

  • hermes_cli/skills_hub.py (modified, +6/-1)
  • tests/hermes_cli/test_skills_hub.py (modified, +15/-1)
  • tests/tools/test_skills_hub.py (modified, +17/-0)
  • tools/skills_hub.py (modified, +37/-0)

Code Example

hermes skills tap add git@git.rccchina.com:crawl/spider-skills.git
hermes skills search spider-kit
# No skills found matching your query.

hermes skills inspect git@git.rccchina.com:crawl/spider-skills.git/skills/spider-kit
# Error: Could not find ... in any source.
RAW_BUFFERClick to expand / collapse

Problem

hermes skills tap add <repo> is documented as a way to add a custom repository as a skill source, but the current implementation only works for GitHub repos addressable through the GitHub Contents API.

In practice, adding a non-GitHub custom Git repository (for example a private/self-hosted Git server over SSH) is accepted by tap add, but skills search, skills inspect, and skills install cannot resolve anything from that tap.

Reproduction

Repository used:

The repository is reachable over SSH and contains valid skill directories such as:

  • skills/spider-kit/SKILL.md
  • skills/crawl-config/SKILL.md
  • skills/crawl-troubleshoot/SKILL.md

However:

hermes skills tap add [email protected]:crawl/spider-skills.git
hermes skills search spider-kit
# No skills found matching your query.

hermes skills inspect [email protected]:crawl/spider-skills.git/skills/spider-kit
# Error: Could not find ... in any source.

Root cause

From the current implementation in tools/skills_hub.py:

  • TapsManager.add() stores arbitrary {repo, path} values in taps.json
  • but GitHubSource later assumes taps are GitHub repos in owner/repo form
  • search/listing uses https://api.github.com/repos/{repo}/contents/{path}
  • inspect/fetch identifiers are parsed as owner/repo/path/to/skill-dir

So tap add currently accepts a broader input surface than the backend actually supports.

Expected behavior

One of these should happen:

  1. Minimal fix:

    • validate tap add input and clearly restrict it to GitHub/GitHub Enterprise repos that the backend can actually resolve
    • document that self-hosted/non-GitHub Git repos are not supported

  2. Better fix:

    • support generic git-based taps, including SSH/private repositories
    • allow search/inspect/install by cloning or updating a local cache and scanning skills/*/SKILL.md
    • make tap/search/install work consistently for custom git repositories, not only GitHub API-backed repos

Why this matters

The current UX is misleading: tap add succeeds, but the tap is unusable unless the repo happens to match GitHub API assumptions.

This makes Hermes difficult to adopt in internal/company environments where skills are stored in private Git servers rather than public GitHub repos.

extent analysis

TL;DR

To fix the issue, restrict tap add input to GitHub/GitHub Enterprise repos or extend support for generic git-based taps, including SSH/private repositories.

Guidance

  • Validate tap add input to ensure it only accepts GitHub/GitHub Enterprise repos that the backend can resolve, and document the limitation.
  • Consider extending the TapsManager to support generic git-based taps by cloning or updating a local cache and scanning skills/*/SKILL.md.
  • Update the GitHubSource to handle non-GitHub repos by using git commands instead of relying on the GitHub API.
  • Test the changes with a private Git server over SSH to ensure the fix works as expected.

Example

# Example of how to validate tap add input
def validate_tap_add_input(repo_url):
    # Check if the repo_url is a valid GitHub/GitHub Enterprise repo
    if not repo_url.startswith("https://github.com/") and not repo_url.startswith("https://github.enterprise.com/"):
        raise ValueError("Only GitHub/GitHub Enterprise repos are supported")

Notes

The current implementation has a limitation that only GitHub/GitHub Enterprise repos are supported. Extending the support for generic git-based taps would require significant changes to the TapsManager and GitHubSource.

Recommendation

Apply a workaround by restricting tap add input to GitHub/GitHub Enterprise repos, as this is the most straightforward fix. This will prevent users from adding unsupported repos and provide a clear error message instead of a misleading success message.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

One of these should happen:

  1. Minimal fix:

    • validate tap add input and clearly restrict it to GitHub/GitHub Enterprise repos that the backend can actually resolve
    • document that self-hosted/non-GitHub Git repos are not supported

  2. Better fix:

    • support generic git-based taps, including SSH/private repositories
    • allow search/inspect/install by cloning or updating a local cache and scanning skills/*/SKILL.md
    • make tap/search/install work consistently for custom git repositories, not only GitHub API-backed repos
#api#model compatibility#GPU setup#container setup#orchestration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING