Skip to content

Autonomous Skill-Management Ecosystem (AI for AI Framework#240

Closed
adanaleycio wants to merge 2 commits into
NousResearch:mainfrom
adanaleycio:main
Closed

Autonomous Skill-Management Ecosystem (AI for AI Framework#240
adanaleycio wants to merge 2 commits into
NousResearch:mainfrom
adanaleycio:main

Conversation

@adanaleycio

Copy link
Copy Markdown
Contributor

Hello everyone,this is my 2st Cont about Hermes-Nous Research
Most contributors focus on teaching Hermes a static, single-purpose skill. However, I realized that the true potential lies in creating a self sufficient architecturean ▶️ "AI for AI" system. My goal was to build a framework where the agent doesn't just learn a task, but autonomously handles its own "education," directory structuring, and code validation.

Evolution from Previous Work:
In my previous PR (the manual crypto-tool), I struggled to make Hermes truly "recognize" and integrate the skill. With this new Autonomous Skill Ecosystem, Hermes now instantly identifies and adopts the newly generated capabilities.

How It Works:
By using the skills.py engine on my server (and yours), you can teach the AI a concept, and it will autonomously transform that into a modular, persistent, and production-ready tool. Once created, these skills are globally accessible to anyone using the Hermes interface.

Key Components & Technical Implementation:
Validate.py: Ensures the integrity of the agent's "self-taught" code using syntax checking.

Registry.py: Manages the library of autonomous skills, acting as the agent’s long-term memory for tools.

Intelligent Encapsulation & Optimization: You will notice "Error" logs in the screenshots. These are intentional: the system is designed to recognize existing files and refuses to redundanty re-generate them. This prevents system fatigue, optimizes DB/Storage usage, and enforces a strict encapsulation logic.

Technical Proof:
The attached videos and terminal logs demonstrate the transition from a blank state to a fully structured, autonomous environment.
Pls check my Discord message for more details and videos:
https://discord.com/channels/1053877538025386074/1365353266505842840/1477538447609696370
otonom1
otonom1 2

otonom1 3
otonom1 4
otonom1 5
skillcreated
otonomerror

@teknium1

teknium1 commented Mar 5, 2026

Copy link
Copy Markdown
Contributor

Thanks for the contribution and the enthusiasm, @adanaleycio! The idea of making skills more robust is a good instinct.

However, we can't merge this PR as-is for several reasons:

  • 4 empty filesskill_maker/README.md, __init__.py, config.py, and requirements.txt are all 0 bytes.
  • Broken symlinkskills_output is a symlink to /root/.hermes/skills, an absolute path on your machine that won't work for anyone else.
  • Wrong directory structure — Files are placed at the repo root under skill_maker/ and skills/, but Hermes skills live in ~/.hermes/skills/ at runtime. These files don't integrate with the existing codebase.
  • No integration with existing architecture — The code doesn't hook into agent/skill_tools.py, model_tools.py, or toolsets.py. Nothing in the codebase calls or imports these files.
  • Duplicates existing functionality — Hermes already has a complete skill system (skill_manage, skills_list, skill_view) with YAML frontmatter, categories, linked files, etc. This reimplements a subset of that without connecting to it.
  • Non-English comments — The project is English-language, but the code contains Turkish strings.

That said, the skill validation concept — using ast.parse() to automatically check Python files in skill directories — is a genuinely useful idea. We've opened #416 to track adding lightweight validation and linting to the existing skill system, inspired by your validate_skill approach. If you'd like to contribute to that issue, we'd welcome a PR that integrates validation into agent/skill_tools.py directly!

Closing this PR, but thanks for the idea — it led to a real improvement being tracked.

@teknium1 teknium1 closed this Mar 5, 2026
@adanaleycio

adanaleycio commented Mar 5, 2026 via email

Copy link
Copy Markdown
Contributor Author

PowerCreek added a commit to TechDevGroup/hermes-agent that referenced this pull request May 25, 2026
…vances #89 Direction A) (#98)

Operator-supplied intent override (Option A3 from #97). When
``HERMES_INTENT_OVERRIDE=code`` is set, the system prompt's
``stable`` layer narrows for tool-call-heavy traffic — addresses
#89's prompt-saturation symptom on mid-tier coding models.

## What narrows under code intent

| Block | Action | Why |
|---|---|---|
| SOUL.md | Skip | Largest single contributor; falls back to short DEFAULT_AGENT_IDENTITY floor |
| HERMES_AGENT_HELP_GUIDANCE | Skip | Off-topic for tool-call traffic |
| SKILLS_GUIDANCE | Skip | Per-tool block, off-topic for code |
| KANBAN_GUIDANCE | Skip | Worker-lifecycle, off-topic for code |
| SESSION_SEARCH_GUIDANCE | Skip | Off-topic for code |
| skills_prompt (the big one) | Skip | Biggest contributor when many skills loaded |
| MEMORY_GUIDANCE | **Keep** | Small + sometimes useful even for code |
| TOOL_USE_ENFORCEMENT_GUIDANCE | **Keep** | Critical for tool emission |
| Per-model operational guidance | **Keep** | Model-quality-specific |
| Env / platform hints | **Keep** | Execution-environment essentials |
| nous-subscription + computer-use + alibaba | **Keep** | Operational invariants |
| ``context`` + ``volatile`` layers | **Untouched** | Out of scope per #97 |

Other intents (``confer`` / ``planning`` / ``exploration`` /
``refinement`` / ``generic``) are recognized as valid but pass
through without narrowing in v1 (keeps the door open for per-
intent shape later).

## Intent vocabulary

Matches devagentic#240's ``intent_classifier`` 6-key enum exactly,
so the same operator-side classifier that's wired into devagentic's
R5 dispatch hook can also drive hermes-side prompt narrowing
without a second vocabulary.

## Doctor probe

New ``_check_intent_override_env`` probe surfaces the active
override at ``hermes doctor`` time — silent when unset, check_ok
when valid (with a narrowing-active note for ``code``), check_warn
with the full valid-keys list when typo'd. Mirrors the silent-
when-irrelevant pattern from PR #95 / #96.

## Tests

- 22 new prompt-narrowing tests in
  ``tests/agent/test_system_prompt_intent_override.py``: resolver
  enum + normalization (5), per-section drops under code (7),
  pass-through for non-code intents (5), typo falls back (1),
  byte-count regression (1), default-still-includes counter-case (1),
  case-insensitive (1), runtime-vs-doctor-config sanity (1).
- 6 new doctor-probe tests in
  ``tests/hermes_cli/test_doctor_intent_override_probe.py``:
  silent-when-unset / silent-when-empty / code-ok-with-narrowing-note /
  non-code-valid-pass-through / typo-warn-with-valid-sample /
  case-insensitive.
- 258 total green across affected suites (system-prompt + prompt-
  builder + restore + doctor + provider-env + tools-subset). No
  regression in the existing prompt-shape pins.

## Composition note

Option A1 (port classifier) + A2 (devagentic GraphQL surface) are
deferred per the #97 sequencing — A3 unblocks deployment-specific
narrowing immediately; A1/A2 only matter when dynamic per-turn
classification is needed on the hermes side. The classifier output
on the devagentic side (NousResearch#240) drives R5 dispatch decisions there.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants