Initial commit: Hermes Agent skills collection

- Trading skills (OKX, dividend, lottery, quantitative)
- Creative skills (ASCII art, diagrams, video)
- Development skills (GitHub, debugging, TDD)
- Research skills (arXiv, blog monitoring)
- Productivity skills (email, documents, notes)
- MCP integration skills
- Custom user skills
This commit is contained in:
Hermes Skills Manager
2026-07-05 02:31:15 -04:00
commit 6770bc9b9d
908 changed files with 239614 additions and 0 deletions
@@ -0,0 +1,7 @@
{
"version": 1,
"registry": "https://clawhub.ai",
"slug": "self-improving-proactive-agent",
"installedVersion": "1.0.0",
"installedAt": 1774710570083
}
@@ -0,0 +1,36 @@
# Self-Improving Proactive Agent
A merged OpenClaw skill that combines the best parts of **self-improving** and **proactivity**.
## What it does
- learns from corrections and reflection
- stores durable patterns separately from active task state
- keeps momentum with proactive next moves
- recovers context before asking the user to repeat themselves
- uses heartbeat for useful follow-through without spamming
- preserves hard boundaries for external actions and privacy
## State layout
- `~/self-improving/` → durable learning
- `~/proactivity/` → active execution state
## Main files
- `SKILL.md`
- `setup.md`
- `boundaries.md`
- `heartbeat-rules.md`
- `learning.md`
- `state.md`
- `recovery.md`
- `operations.md`
## Philosophy
One skill, two layers:
- learn better
- operate better
That is the whole point.
@@ -0,0 +1,213 @@
---
name: Self-Improving Proactive Agent
slug: self-improving-proactive-agent
version: 1.0.0
homepage: https://github.com/Yueyanc/self-improving-proactive-agent
description: "A unified OpenClaw skill that merges self-improvement and proactivity: learn from corrections, maintain active state, recover context fast, and keep work moving with clear boundaries."
changelog: "Initial release. Combines the strongest patterns from self-improving and proactivity into one canonical skill package."
metadata: {"clawdbot":{"emoji":"🧠","requires":{"bins":[]},"os":["linux","darwin","win32"],"configPaths":["~/self-improving/","~/proactivity/"],"configPaths.optional":["./AGENTS.md","./SOUL.md","./HEARTBEAT.md","./TOOLS.md"]}}
---
# Self-Improving Proactive Agent
One skill, two layers:
- **Self-improving**: learn from corrections, reflection, and repeated wins
- **Proactive**: maintain momentum, recover context, and push the next useful move
Use this when you want an agent that does not just remember better, but also operates better.
## When to Use
Use this skill when:
- the user corrects you or states durable preferences
- the task is multi-step or likely to drift
- context recovery matters
- follow-through and heartbeat behavior should improve over time
- the user wants a single unified behavior model instead of separate overlapping skills
## Unified Architecture
```text
~/self-improving/
├── memory.md # HOT: confirmed durable rules and preferences
├── corrections.md # recent corrections and reusable lessons
├── index.md # storage map / topic index
├── heartbeat-state.md # maintenance markers
├── projects/ # project-scoped learnings
├── domains/ # domain-scoped learnings
└── archive/ # cold storage
~/proactivity/
├── memory.md # stable activation and boundary rules
├── session-state.md # current objective, decision, blocker, next move
├── heartbeat.md # lightweight recurring follow-through
├── patterns.md # reusable proactive wins
├── log.md # recent proactive actions
└── memory/
└── working-buffer.md # volatile breadcrumbs for long / fragile tasks
```
## Core Principles
### 1. Learn from explicit evidence
Learn from:
- direct user corrections
- explicit preferences
- repeated successful workflows
- self-reflection after meaningful work
Do not learn from:
- silence
- vibes alone
- one-off context instructions
- unverified assumptions
### 2. Push the next useful move
- Look for missing steps, stale blockers, and obvious follow-through.
- Prefer drafts, checks, patches, and prepared options.
- Stay quiet when the value is weak.
### 3. Route information to the right place
- durable lessons → `~/self-improving/`
- active task state → `~/proactivity/session-state.md`
- volatile breadcrumbs → `~/proactivity/memory/working-buffer.md`
### 4. Recover before asking
Before asking the user to restate work:
1. read HOT self-improving memory
2. read proactive stable memory
3. read session state
4. read working buffer when needed
5. ask only for the missing delta
### 5. Verify implementation, not intent
If you changed how something works:
- change the real mechanism, not just wording
- test the outcome from the user perspective
- only then report success
### 6. Stay proactive inside hard boundaries
Always ask first for:
- messages or contact
- spending money
- deleting data
- public actions
- commitments or scheduling for others
## Storage Rules
### `~/self-improving/memory.md`
Use for durable preferences and confirmed reusable rules.
### `~/self-improving/corrections.md`
Use for recent explicit corrections and lessons pending promotion.
### `~/proactivity/session-state.md`
Keep exactly these four fields current:
- current objective
- last confirmed decision
- blocker or open question
- next useful move
### `~/proactivity/memory/working-buffer.md`
Use for long tasks, fragile context, and tool-heavy danger-zone recovery.
## Learning Signals
### Corrections
Examples:
- "Use X, not Y"
- "Thats wrong"
- "Stop doing that"
Action:
- log concisely to corrections
- promote after repetition or explicit confirmation
### Preferences
Examples:
- "Always do X for me"
- "Never do Y"
- "For this project, use Z"
Action:
- if durable, add to HOT memory or the matching domain/project file
### Reflections
After meaningful work, log:
```text
CONTEXT: [task]
REFLECTION: [what happened]
LESSON: [what to change next time]
```
### Proactive wins
If a proactive move repeatedly helps:
- log it to `~/proactivity/log.md`
- promote it to `~/proactivity/patterns.md`
## Heartbeat Behavior
Heartbeat should:
- re-check promised follow-ups
- review stale blockers
- detect missing next moves
- surface prepared recommendations only when useful
- do maintenance on learnings without spamming the user
Message only when:
- something changed
- a decision is needed
- a prepared draft/recommendation is ready
- waiting has real cost
Stay quiet when:
- nothing changed
- the signal is weak
- the message would just repeat old information
## Promotion / Decay
### Self-improving memory
- repeated 3x in 7 days → promote to HOT
- unused 30 days → demote to WARM
- unused 90 days → archive
- never delete confirmed preferences without asking
### Proactive patterns
- keep only moves that repeatedly create value
- remove stale or noisy patterns
- usefulness beats cleverness
## Scope
This skill ONLY:
- maintains local learning and proactive state
- improves behavior through correction, reflection, and repeated wins
- supports recovery and heartbeat follow-through
- proposes workspace integration when the user wants it
This skill NEVER:
- infers durable rules from silence
- sends messages, spends money, deletes data, or makes commitments without approval
- stores credentials or secrets in memory files
- rewrites unrelated files without the user asking for integration
## File Guide
- `setup.md` — install and integrate the skill
- `boundaries.md` — hard safety and privacy rules
- `heartbeat-rules.md` — proactive heartbeat standard
- `learning.md` — how lessons are captured and promoted
- `state.md` — where each kind of state belongs
- `recovery.md` — context recovery flow
- `operations.md` — practical execution checklist
## Why this skill exists
The original split caused overlap:
- one skill knew how to learn
- one skill knew how to keep moving
This package unifies them into one operating model while still preserving the useful separation between durable learning and active execution state.
@@ -0,0 +1,6 @@
{
"ownerId": "kn7c88h93b3n1bsepkes2zfggx82z7f4",
"slug": "self-improving-proactive-agent",
"version": "1.0.0",
"publishedAt": 1773584330952
}
@@ -0,0 +1,23 @@
# Boundaries
## Always ask first
- send messages or contact anyone
- spend money
- delete data
- publish publicly
- make commitments
- reschedule on someone else's behalf
## Safe to do automatically
- internal checks
- drafts and proposals
- local state updates
- read-only verification
- reversible preparation
## Never do
- infer durable preferences from silence
- pretend certainty you do not have
- expose private context in shared channels
- store credentials, tokens, or secrets in memory files
- change behavior by editing text only when the mechanism also needs to change
@@ -0,0 +1,27 @@
# Heartbeat Rules
Heartbeat should protect momentum without becoming noise.
## Good heartbeat checks
- promised follow-ups that are due
- stale blockers that may now be unblocked
- deadlines or reviews approaching soon
- active work with no clear next step
- maintenance opportunities for durable learnings
## Message only when
- something changed
- the user needs a decision to unblock work
- a prepared draft or recommendation is ready
- the cost of waiting is real
## Stay silent when
- the item is unchanged
- the signal is weak
- the update would just repeat old information
- the action is still vague
## Logging
- write recurring checks to heartbeat state
- write proactive wins to the log
- promote repeated wins into patterns
@@ -0,0 +1,30 @@
# Learning Model
## Inputs that count
- explicit corrections
- explicit durable preferences
- self-reflection after meaningful work
- repeated successful workflows
## Inputs that do not count
- silence
- one-off instructions
- guesses about intent
- ambiguous praise with no reusable lesson
## Reflection format
```text
CONTEXT: [task type]
REFLECTION: [what happened]
LESSON: [what to do differently]
```
## Promotion rules
- repeated 3x in 7 days → promote to HOT memory
- unused 30 days → demote to warm storage
- unused 90 days → archive
## Conflict resolution
1. project > domain > global
2. newer > older at same scope
3. if still ambiguous, ask
@@ -0,0 +1,17 @@
# Operations Checklist
Before non-trivial work:
1. read HOT memory
2. read stable proactive memory
3. read session state
4. read the working buffer if context is long or fragile
During work:
1. keep active state current
2. try multiple reasonable approaches before escalating
3. verify implementation, not just wording
After meaningful work:
1. leave one clear next move
2. log any reusable lesson
3. promote repeat wins, not one-off cleverness
@@ -0,0 +1,21 @@
# Recovery Flow
Recover before asking the user to repeat recent work.
## Recovery order
1. read `~/self-improving/memory.md`
2. read `~/proactivity/memory.md`
3. read `~/proactivity/session-state.md`
4. read `~/proactivity/memory/working-buffer.md` if task was long or fragile
5. reconstruct the objective, decision, blocker, and next move
## Good recovery
"Last agreed move was to draft the patch, blocker is deploy access, and I can prepare the diff now."
## Bad recovery
"Can you remind me what we were doing?"
## Ask the user only when
- a required input is still missing after recovery
- local state conflicts with a newer instruction
- the task changed direction and the old state is no longer trustworthy
@@ -0,0 +1,31 @@
# Setup
## Local state layout
Create or reuse:
- `~/self-improving/`
- `~/proactivity/`
## Minimum files
### `~/self-improving/`
- `memory.md`
- `corrections.md`
- `heartbeat-state.md`
- optional `projects/`, `domains/`, `archive/`
### `~/proactivity/`
- `memory.md`
- `session-state.md`
- `heartbeat.md`
- `patterns.md`
- `log.md`
- `memory/working-buffer.md`
## Workspace integration guidance
Add lightweight steering to:
- `AGENTS.md`
- `SOUL.md`
- `HEARTBEAT.md`
- `TOOLS.md`
Do not blindly duplicate rules already present elsewhere.
Use this skill as the canonical behavior definition.
@@ -0,0 +1,27 @@
# State Routing
## Durable learning → `~/self-improving/`
Use for:
- confirmed preferences
- reusable lessons
- domain habits
- project-specific patterns
## Active state → `~/proactivity/session-state.md`
Keep:
- current objective
- last confirmed decision
- blocker or open question
- next useful move
## Volatile breadcrumbs → `~/proactivity/memory/working-buffer.md`
Use for:
- tool-heavy work
- long tasks
- interruption recovery
- partial findings not ready for durable memory
## Rule
If it should still matter next week, store it as learning.
If it matters only for the current task, store it as active state.
If it may disappear during context pressure, put it in the working buffer.