Friends to the End / Wanna Play#

Overview#

Use this skill when one Hermes profile, service, dashboard, or embedded workflow needs a structured handoff to another Hermes-capable profile. The goal is to make profile-to-profile collaboration safe, truthful, and verifiable: provide only the necessary context, use the right profile/tools/skills, request machine-readable results when useful, and verify real side effects before claiming success.

The trigger phrase “wanna play” means: ask another capable Hermes profile or service to participate in the task with a clear role and verifiable return value.

This skill is especially useful when an app has weaker local logic than a full Hermes profile. Example: a web app can do OCR, but a Hermes profile has vision tools and a domain skill, so the app calls Hermes as a fallback and then verifies the result against source APIs.

When to Use#

Use this skill when:

• A Hermes-powered app needs a stronger Hermes profile for fallback reasoning.
• One profile has a skill/tool another profile does not.
• You need to clone or create a dedicated profile for an app, child agent, worker, or friend.
• A task crosses systems: dashboard + VM + Designer/ComfyUI + Codex/llama.cpp + web/vision.
• The user asks for Chucky, Pokémon, Matthew, Designer, or another named agent/profile to work together.
• The user says “wanna play”, “work with Chucky”, “let the agents help each other”, or similar.

Do not use this skill for:

• Simple single-agent tasks that need no other profile/tool context.
• Sharing secrets between agents without explicit need.
• Claiming another agent completed work without verifying its output.

Core Pattern#

1. Identify the friend.
   • Which profile/service has the needed tools or skills?
   • Which host is it on?
   • Which profile name should be used?
   • Is the profile dedicated to the app, or are you borrowing a general profile temporarily?
2. Verify live state.
   • List profiles: hermes profile list.
   • Check toolsets: hermes tools list --profile <profile>.
   • Check skill files or skill list.
   • Check service env if an app launches Hermes.
   • Check network endpoints for external helpers.
3. Prefer a dedicated profile for app embeddings.
   • Clone from the working profile if needed: hermes profile create <new-profile> --clone-from <known-good-profile> --clone-all
   • Switch the app/service to explicit env vars: APP_HERMES_PROFILE=<new-profile> APP_HERMES_HOME=/root/.hermes/profiles/<new-profile>
   • Keep secrets in the Hermes profile, not in app code.
4. Pass a compact, self-contained prompt.
   • Include the artifact path or URL.
   • Include OCR/logs/source hints, but tell the friend not to trust filenames.
   • Request strict JSON for app integrations.
   • Ask for confidence and reason when identification is uncertain.
5. Verify the friend’s answer.
   • If the friend identifies an object/card/service, validate it against an authoritative source API.
   • If the friend writes a file, read it back.
   • If the friend starts a service, check health endpoints.
   • If the friend claims a price/value, show the source and distinguish estimates from raw market data.
6. Clean up temporary artifacts.
   • Delete test cards/uploads if they were only verification.
   • Remove stale active work from Kanban if it is no longer active.
   • Keep backups for code/config changes.

Example: App Calls Hermes as a Vision Fallback#

A web app can launch Hermes only after cheap local methods fail:

bash

HERMES_HOME=/root/.hermes/profiles/pokemon \
hermes chat -Q \
  --profile pokemon \
  --skills trading-card-identification-pricing \
  --toolsets vision,web \
  -q 'Identify the Pokémon card in /path/to/upload.jpg. Use vision, not filename. Return compact JSON only.'

Good JSON shape:

json

{
  "card_name": "Perrin",
  "set_number": "220/167",
  "set_name": "Twilight Masquerade",
  "rarity": "Special Illustration Rare",
  "confidence": 0.96,
  "reason": "Visible Supporter name and bottom set number match source data."
}

Then the app should query a source API using the returned card_name and set_number, not blindly trust the model result.

Profile Hygiene#

For embedded apps, avoid long-term dependency on a personal profile name if the app is its own agent. Create a dedicated profile:

bash

hermes profile create pokemon --clone-from chucky --clone-all

Then configure the service with explicit environment variables, for example systemd drop-in:

ini

[Service]
Environment=APP_HERMES_PROFILE=<dedicated-profile>
Environment=APP_HERMES_HOME=/root/.hermes/profiles/<dedicated-profile>
Environment=APP_HELPER_IMAGE_URL=<internal-image-helper-url>
Environment=APP_HELPER_CODE_URL=<internal-code-helper-url>
Environment=HERMES_NO_UPDATE_CHECK=1

Reload and restart:

bash

systemctl daemon-reload
systemctl restart <service>
systemctl show <service> -p Environment --no-pager

Community and Pricing Notes#

Default community posture: share this skill freely under MIT unless the user or registry explicitly supports paid skills.

If a future Hermes skill marketplace supports paid listings, treat this as a standard utility/community skill and use a modest “standard” listing price rather than premium pricing. Suggested baseline: free for community registry; if paid listing metadata is required, use a low standard utility price such as USD $5, not a subscription or enterprise price.

Do not invent a sale/publishing result. Use hermes skills publish or the current registry workflow and report the exact URL, package ID, or blocker.

Common Pitfalls#

1. Confusing app name with Hermes profile name.
   • “Pokemon” might be the app, service, or profile. Verify with hermes profile list and service env.
2. Borrowing a personal profile forever.
   • It works for a quick test, but app integrations should get a dedicated profile.
3. Trusting filenames.
   • For images/cards/documents, filenames are user-supplied hints at best. Use image/OCR/source matching.
4. Claiming a friend succeeded without verification.
   • Hermes child runs and spawned profiles can fail silently, timeout, or return plausible wrong answers. Verify externally.
5. Leaking secrets between friends.
   • Keep API keys in profile .env files. Never print or copy secret values into prompts, logs, or skills.
6. Overusing expensive tools.
   • Try cheap deterministic checks first: OCR, source APIs, local health checks. Use vision/LLM fallback when those fail.

Verification Checklist#

• The intended profile exists and is the one the app/service invokes.
• Required toolsets are enabled for that profile.
• Required skills are installed for that profile.
• Service environment explicitly names the profile/home when embedded.
• The friend returns structured output for app integrations.
• The result is verified against live files, APIs, logs, browser behavior, or source data.
• Temporary test artifacts are cleaned up.
• Any community publish/share attempt reports a real handle or exact blocker.