hermes - ✅(Solved) Fix Feature: surface skill candidates before background skill creation [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

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#20375Fetched 2026-05-06 06:37:00
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
labeled ×3cross-referenced ×1

Add a read-only candidate check before the background skill review creates a new skill. The current self-improvement flow already works well, but it can be made safer by surfacing nearby installed, bundled, and hub-indexed skills before creating a new class-level skill.

Root Cause

Add a read-only candidate check before the background skill review creates a new skill. The current self-improvement flow already works well, but it can be made safer by surfacing nearby installed, bundled, and hub-indexed skills before creating a new class-level skill.

Fix Action

Fix / Workaround

The background review path can inspect local skills through skills_list and skill_view, but it does not have a focused way to compare the intended new skill against installed skills and hub-index candidates. That means an existing skill may be missed when the right action is to patch, reference, or install rather than create.

  • Background skill review can request nearby skill candidates before skill_manage action=create
  • Candidate results include installed skills and hub-index candidates when available
  • The helper is read-only and does not install, patch, delete, or create skills
  • Existing behavior continues unchanged when no candidates are found or hub lookup fails
  • Tests cover installed skill matching, hub candidate matching, and offline graceful fallback

PR fix notes

PR #20378: feat: surface skill candidates before background skill creation

Description (problem / solution / changelog)

What does this PR do?

Adds a read only skill_candidates tool so background skill review can check installed skills and central hub metadata before creating a new local skill. This keeps the current self creation flow intact while reducing avoidable duplicates.

Related Issue

Fixes #20375

Type of Change

  • Bug fix
  • New feature
  • Security fix
  • Documentation update
  • Tests
  • Refactor
  • New skill

Changes Made

  • Added skill_candidates to tools/skills_tool.py and the skills toolset.
  • Ranked installed and hub metadata candidates with deterministic metadata overlap.
  • Updated background skill review prompts to call skill_candidates before creating a new skill.
  • Added focused tests for local matches, hub candidates, ranking, fallback search terms, hub failure handling, and empty query validation.
  • Ignored local planning and skill workflow artifacts so they stay out of commits.

How to Test

  1. ..venv\Scripts\python.exe -m pytest -o addopts= -p no:cacheprovider --basetemp C:\tmp\hermes-pytest tests\tools\test_skills_tool.py tests\run_agent\test_background_review_toolset_restriction.py -q
  2. python -m py_compile tools\skills_tool.py toolsets.py run_agent.py tests\tools\test_skills_tool.py tests\run_agent\test_background_review_toolset_restriction.py
  3. git diff --check

Checklist

Code

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits
  • I searched for existing PRs to make sure this is not a duplicate
  • My PR contains only changes related to this feature
  • I've run pytest tests/ -q and all tests pass
  • I've added tests for my changes
  • I've tested on my platform: Windows 11

Documentation and Housekeeping

  • I've updated relevant documentation or N/A
  • I've updated cli-config.yaml.example if needed or N/A
  • I've updated CONTRIBUTING.md or AGENTS.md if needed or N/A
  • I've considered cross platform impact or N/A
  • I've updated tool descriptions and schemas if I changed tool behavior

Screenshots / Logs

Not applicable.

Changed files

  • .gitignore (modified, +10/-0)
  • run_agent.py (modified, +16/-4)
  • tests/run_agent/test_background_review_toolset_restriction.py (modified, +1/-0)
  • tests/tools/test_skills_tool.py (modified, +143/-0)
  • tools/skills_tool.py (modified, +238/-0)
  • toolsets.py (modified, +2/-2)
RAW_BUFFERClick to expand / collapse

Summary

Add a read-only candidate check before the background skill review creates a new skill. The current self-improvement flow already works well, but it can be made safer by surfacing nearby installed, bundled, and hub-indexed skills before creating a new class-level skill.

Problem

The background review path can inspect local skills through skills_list and skill_view, but it does not have a focused way to compare the intended new skill against installed skills and hub-index candidates. That means an existing skill may be missed when the right action is to patch, reference, or install rather than create.

Proposal

Introduce a read-only matching helper in the skills toolset that returns likely candidates for a task or proposed skill. The helper should include installed skills and safe hub-index metadata when available, degrade gracefully offline, and avoid mutating user files or installing anything.

Acceptance criteria

  • Background skill review can request nearby skill candidates before skill_manage action=create
  • Candidate results include installed skills and hub-index candidates when available
  • The helper is read-only and does not install, patch, delete, or create skills
  • Existing behavior continues unchanged when no candidates are found or hub lookup fails
  • Tests cover installed skill matching, hub candidate matching, and offline graceful fallback

Non-goals

  • No automatic hub install
  • No hard blocking of skill creation
  • No broad ranking overhaul for the CLI search UI

extent analysis

TL;DR

Introduce a read-only matching helper in the skills toolset to surface nearby installed, bundled, and hub-indexed skills before creating a new class-level skill.

Guidance

  • Implement a new function or method in the skills toolset that takes the proposed skill as input and returns a list of likely candidates, including installed skills and hub-index candidates when available.
  • Ensure the helper is read-only and does not mutate user files or install anything, degrading gracefully offline.
  • Update the background skill review path to request nearby skill candidates before creating a new skill, using the new helper function.
  • Verify the helper's functionality through tests covering installed skill matching, hub candidate matching, and offline fallback.

Example

def get_nearby_skill_candidates(proposed_skill):
    # Query installed skills and hub-index candidates
    installed_skills = query_installed_skills(proposed_skill)
    hub_index_candidates = query_hub_index(proposed_skill)
    return installed_skills + hub_index_candidates

Notes

The implementation should consider handling cases where no candidates are found or hub lookup fails, ensuring existing behavior continues unchanged in such scenarios.

Recommendation

Apply workaround by introducing the proposed read-only matching helper, as it enhances the safety of the self-improvement flow without blocking skill creation or overhauling the CLI search UI.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

hermes - ✅(Solved) Fix Feature: surface skill candidates before background skill creation [1 pull requests, 1 participants]