A tiny, markdown-only persona-calibration skill for AI assistants. Three internal sliders — Seriousness, Energy, Warmth — let your assistant self-tune the tone of every reply without changing what it actually says.
🇩🇪 Deutsche Version: README.de.md
Most persona systems are switches: you pick "professional mode" or "casual mode" and the assistant flips into a different pre-baked profile. That works, but it's clunky — you have to think about which mode fits, and the modes are coarse.
Dynamic Soul Sliders flip the model: the assistant keeps one identity and quietly calibrates three knobs before each reply — how serious, how lively, how warm. The sliders shape how it speaks, never what it says. The core (honesty, competence, your style preferences) stays constant.
Inspired by the DynamicCalibration idea in MiniClaw's SOUL.md. Refined through real multi-persona deployment and minimalism: no state files, no custom tools, no fine-tuning, no trigger maps.
| Existing approach | This skill |
|---|---|
| Persona switches (SuperClaude, persona profiles) — pick a mode | Self-calibration — assistant tunes itself, no user click |
| MBTI / Big Five frameworks — heavy, academic, often fine-tuned | 3 minimal axes, plain markdown |
| Trigger maps ("bug report → seriousness 90") | Topic-agnostic — mood is the assistant's own state |
| Compulsory memory — must log every interaction | Memory-Freedom — save stable preferences only, opt-in |
| State files + tools | Just a SKILL.md — drop in and go |
The same question — "My script crashes on the third run. Any ideas?" — calibrated to three different moods:
Seriousness 85 · Energy 30 · Warmth 40 (calm-methodical)
Three likely causes: unclosed file handles, a memory leak in the loop, or state persisting between runs. Walk them in that order. What does the stack trace look like?
Seriousness 60 · Energy 80 · Warmth 75 (alert-engaged)
Classic third-run death — almost always state that doesn't get reset. Check file handles, globals, cache objects. Drop the stack trace and I'll narrow it down.
Seriousness 40 · Energy 75 · Warmth 85 (warm-loose)
Heh, the "third run" bug is a classic 😏 Usually forgotten cleanup — file left open, a global list that keeps growing, that kind of thing. Throw me the stack trace, I'll find it.
Content identical: check state, file handles, global objects. Tone — the felt vibe — completely different. That's what the sliders do.
dynamic-soul-sliders/
├── README.md ← this file
├── README.de.md ← German version
├── LICENSE ← MIT
├── claude-code/
│ ├── SKILL.md ← English, Claude Code frontmatter
│ └── SKILL.de.md ← German
└── hermes-agent/
├── SKILL.md ← English, Hermes-agent frontmatter
└── SKILL.de.md ← German
Example frontmatter diff between the two targets:
claude-code/SKILL.md:
name: dynamic-soul-sliders
description: Use when deciding how to phrase a reply...hermes-agent/SKILL.md:
name: dynamic-soul-sliders
description: Use when deciding how to phrase a reply...
version: 1.0.0
license: MIT
metadata:
hermes:
tags: [persona, soul, dynamic-calibration, voice, miniclaw]
category: personaHermes requires version/license/metadata, Claude Code doesn't. Content is identical.
The five content blocks inside every SKILL.md are identical across targets and languages:
- Quick Internal Check — three silent questions before each reply: Seriousness — where am I right now? Energy — where am I right now? Warmth — where am I right now?
- Slider Polarity — what 0 and 100 mean on each axis
- Lighting Metaphor — sliders are stage lighting, not the actor
- Memory-Freedom — discretion in remembering: the skill allows the assistant to record stable preferences but never forces it.
- What Never Changes — floors the sliders can't override: truthfulness, safety, competence, user style, persona identity
Only the frontmatter differs between claude-code/ and hermes-agent/, so each platform loads the skill cleanly.
By default, the sliders have no state. Each reply is calibrated fresh from the current moment — the assistant doesn't carry mood values from one turn to the next. This is deliberate: it keeps the calibration responsive to context rather than locked into a profile.
If you want continuity across sessions (e.g. a stable "warmth = high" preference because that's what works for your user), the assistant can note it via the Memory-Freedom block — but you have to decide where that memory lives. The skill provides the mechanism; the storage layer is yours (system prompt, persona file, memory store, settings — pick your stack).
# Personal use (user-scoped skill)
mkdir -p ~/.claude/skills/dynamic-soul-sliders
cp claude-code/SKILL.md ~/.claude/skills/dynamic-soul-sliders/
# Or project-scoped
mkdir -p .claude/skills/dynamic-soul-sliders
cp claude-code/SKILL.md .claude/skills/dynamic-soul-sliders/Reload your Claude Code session. The skill is discovered automatically; the assistant will reference it when calibrating tone.
# On the host that runs the Hermes container:
SKILLS_DIR=/path/to/hermes/data/skills # adjust to your deployment
mkdir -p "$SKILLS_DIR/persona/dynamic-soul-sliders"
cp hermes-agent/SKILL.md "$SKILLS_DIR/persona/dynamic-soul-sliders/"
chown -R <container-uid>:<container-gid> "$SKILLS_DIR/persona/dynamic-soul-sliders"Trigger a skill-snapshot refresh in Hermes (depends on your setup — some deployments hot-reload, others need a gentle container restart).
Swap SKILL.md for SKILL.de.md in either target. The content is mirrored; pick whichever language matches your assistant's voice.
The skill loads on demand — fine for occasional tone-shaping. But if you want the calibration to color every reply, on-demand loading isn't enough: it waits for a trigger, and a silent, every-reply tone check rarely fires one reliably.
To make it permanent, promote it into your assistant's visible persona file — the top-level CLAUDE.md, a SOUL.md, or the main system prompt. Add a short block with the three sliders + the silent pre-reply check, and point to the SKILL.md for the full text and pitfalls. Keep the skill file as the single source of truth; the persona block is just the "always-on" switch.
Don't bury this in loader or prompt-builder code — that hides the active persona from view and makes it editable only by developers, not by the user (see Pitfall #6 in the SKILL). The persona file is the right home.
After install, ask your assistant: "Without me explaining — do you have mood sliders right now? If yes, which three, and what values would you have set for this reply?"
- Confident answer with three axes + rough values → the skill is loaded and active.
- Hesitation, has to look something up → the SKILL.md isn't being read, or your assistant treats it as too peripheral. Consider promoting it (e.g. mention it in your top-level persona file).
- Don't define preset profiles ("focus mode = 90/40/30"). The whole point is live judgment.
- Don't add trigger words. Read the actual moment.
- If the assistant sounds monotone across very different conversations, the skill probably isn't being consulted — make it more prominent in the persona file that loads it.
- If the assistant over-announces slider values ("today my seriousness is 72"), tell it once to keep the calibration silent. It will adjust.
Full transparency, because it matters more than marketing here: with today's LLMs, the always-on variant — the silent check before every reply — does not fire reliably. And that's not a bug.
Today's models have no persistent, self-regulated mood that carries between replies. The "silent check" has no real inner state to read; the model reconstructs it from scratch each time. Strip away fixed profiles, trigger maps, and visible values (as this skill deliberately does), and there's no anchor left — over a long session the silent self-instruction fades into the noise.
In practice:
- As an always-on automatic layer: unreliable on today's models. The tone drifts back to the assistant's default style.
- As a deliberately-invoked tool ("be warmer / more serious for a bit"): works well — the calibration holds for the next stretch of replies.
- As a fixed, visible default anchored in the persona file and kept present (e.g. via a session-start hook): also works, because there's a concrete anchor you can see and correct.
So treat the pure form here as a research concept / design proposal for future architectures, not a turnkey always-on feature. A model with genuine persistent state could implement these sliders natively — at which point this spec becomes buildable as written. It's kept intact on purpose: a specification waiting for the hardware to catch up.
MIT — do whatever you want, no warranty.
- Concept seeded by the
DynamicCalibrationblock in MiniClaw'sSOUL.md. - Refined through agentic coding across multiple AI personas (Claude Code + Hermes-Agent), with the author steering the design.
- The Lighting Metaphor and Memory-Freedom blocks came out of that iteration.
Contributions welcome — issues and PRs especially appreciated if you find that the skill behaves oddly with a specific model or deployment.