[IMPROVEMENT] Convert experiential memory into an evidence-grounded, trigger-monitored skill library

[Lexus2016]

Improvement Description

Problem Statement

Memory failures are a recurring top failure bucket in Hermes pipeline metrics. Hermes already stores memories and already has a SKILL.md corpus plus a SkillCrystallizer that can turn successful traces into provisional skill candidates. What is missing is the operational link: experiential memory mostly sits as passive context the model must re-reason over, rather than being promoted into skills with explicit trigger conditions that are monitored at runtime and injected when the state matches.

Proposed Solution

Evolve the memory-to-skill path into an evidence-grounded co-evolution governance layer. For each validated memory/trace, produce a skill entry with an explicit trigger function μ(state, task-kind). At runtime, the agent monitors the current state and, when a trigger fires, retrieves the crystallized skill into context to guide action instead of re-deriving the workflow from scratch.

Concrete steps:

1. Evidence bar — only promote memories that pass the existing meets_evidence_bar gates (reusability ≥ 0.6, ≥ 2 distinct tools, ≥ 3 actions, verified success). This guardrail already exists in evolution/lib/skill_crystallizer.py and must remain hard.
2. Trigger extraction — when crystallizing a skill, extract and store the trigger conditions under which it should fire (task kind, tool constellation, error class, user intent signal). Store them in the skill frontmatter so they are inspectable.
3. Runtime trigger monitor — add a lightweight monitor that, before each model turn, scores current state against stored trigger conditions and retrieves matching skills when the score exceeds a calibrated threshold.
4. Co-evolution loop — when a triggered skill is used, record outcome; demote or revise skills whose triggered use repeatedly fails, so the library improves rather than fossilizes.

Value Proposition

• Impact: High (0.8)
• Effort: Medium (0.5)
• Priority Score: 1.28

Research Evidence

• From Memory to Skills: Evidence-Grounded Co-Evolution Governance for Long-Horizon LLM Agents

Implementation Plan

1. Extend evolution/lib/skill_crystallizer.py to require and validate trigger metadata in skill frontmatter.
2. Add a trigger matcher/scorer (state + skill trigger → relevance score) in a new small module under evolution/lib/.
3. Wire the trigger monitor into the agent turn loop so retrieved skills are injected transparently and respect prompt-caching constraints (skills are part of the stable prefix).
4. Add feedback logging: triggered skill usage + outcome is written back to the skill library for periodic re-evaluation.

Success Criteria

• Crystallized skills carry explicit, validated trigger conditions.
• Runtime monitor retrieves skills only when triggers fire, with logged confidence scores.
• Pipeline memory-failure rate trend shows reduction within a 14-day window.
• Triggered skills that repeatedly fail are automatically demoted to provisional status.

[Lexus2016]

Increment 1 shipped as PR #3211 (trigger metadata in crystallizer frontmatter + trigger matcher module, tests green locally). Slice is 308 changed lines — above the 200-line autonomous-merge cap, so held for human review. Proposed split of the remainder: (2) runtime trigger monitor wired into the turn loop (prompt-cache-safe); (3) co-evolution outcome logging + auto-demotion.

[Lexus2016]

Decomposed into child issues:\n- #3217 — runtime trigger monitor (increment 2)\n- #3218 — triggered-skill outcome logging + auto-demotion (increment 3)\n\nImplementation gate: children should compete only after PR #3211 (increment 1) merges, to avoid parallel conflicting work on the same feature.

[Lexus2016]

Blocked by integration code review (PR #3211 closed, 2026-08-27).

What was wrong:

• and in the new have zero real call sites anywhere in the repo (not even a runtime monitor). They are dead code per the autonomous dead-code gate.
• The PR body already admitted it exceeds the 200-line self-merge cap.
• The frontmatter half of the module (extract/validate/render/parse trigger metadata) IS correctly wired into ; do not throw that away.

Definition of done for re-open:

• Do NOT add / until the deferred increment is implemented: the runtime trigger monitor wired into the agent turn loop that actually invokes them.
• OR re-scope this increment to land only the frontmatter plumbing (extract/validate/render/parse) so the module is fully consumed now.
• If adding the monitor in the next increment, keep the PR ≤200 changed lines and confirm every new symbol has a real production caller.

Issue left OPEN; labels flipped from accepted to needs-work.