feat(site): add skill for hermes agent#259
Conversation
👷 Deploy request for mem9 pending review.A Netlify team Owner will need to approve the deploy before you can run your build. Are you a team Owner? Visit the deploys page to approve it → Need more help? Learn more in the Netlify docs →
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9e8ea5e2b5
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@codex review |
|
Codex Review: Didn't find any major issues. Can't wait for the next one! ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
|
I think this still needs another pass before merge.
@codex review again after the changes above. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 306e305cd7
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@codex review |
|
Codex Review: Didn't find any major issues. Bravo. ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
|
One remaining issue in the Hermes public docs: please avoid
Please make Hermes activation non-interactive:
This matches the one-shot install script behavior more closely and avoids driving an interactive picker from an IM skill. |
|
Please sync this branch with the latest |
|
@Yuiham Done
|
Yuiham
left a comment
There was a problem hiding this comment.
The version of the hermes SKILL.md should be 1.0.0.
Yuiham
left a comment
There was a problem hiding this comment.
Follow-up on the Hermes flow per my earlier IM-flow comment. Three remaining gaps before that thread can fully close — see the file comments below.
| - Run `hermes plugins install mem9-ai/mem9-hermes-plugin` only as a fallback when the official install script is unavailable or when the upstream instructions explicitly require the manual path | ||
| - Run the upstream helper script `link-memory-provider.sh` from the installed mem9 Hermes plugin when the Hermes provider link is missing | ||
| - Set `HERMES_PROJECT_ROOT` only for the current install/link command when Hermes cannot auto-detect the project root | ||
| - Run `hermes config set memory.provider mem9` only on the manual fallback path, to set mem9 as the active provider non-interactively |
There was a problem hiding this comment.
The "only on the manual fallback path" wording will conflict with SETUP.md once the link-repair flow also activates mem9 non-interactively (see my comment on SETUP.md Step 3). After that lands, this scope bullet should cover both paths.
Suggested wording:
| - Run `hermes config set memory.provider mem9` only on the manual fallback path, to set mem9 as the active provider non-interactively | |
| - Run `hermes config set memory.provider mem9` on the link-repair path or the manual fallback path, to set mem9 as the active provider non-interactively |
| - Do not replace it with ad hoc shell logic when the upstream script is available. | ||
| - If the install script already completes install, setup, and verification, do not repeat those steps unnecessarily. | ||
| - The upstream README says this script installs the plugin, obtains or reuses an API key, writes `.env`, writes `mem9.json`, and creates the provider symlink. | ||
| - If the script installs the plugin but reports a connectivity failure or leaves mem9 inactive, continue to Step 3. |
There was a problem hiding this comment.
This bullet only handles "install ran but mem9 ended up inactive". It doesn't cover the case where install.sh exits non-zero or fails to install the plugin at all — today we'd silently fall through into Step 3 link-repair / Step 4 status loops, which is the exact IM-flow loop we agreed to avoid.
Per the earlier comment ("if the official install script and fallback install both fail, stop and report the install failure instead of continuing with link/setup/status"), please add a fail-stop rule here:
- If
install.shexits non-zero, fall through to Step 3b (hermes plugins install ...) as the documented manual fallback. - If both Step 2 and Step 3b fail to install the plugin, stop and report the install failure using the failure template in Step 4.
- Do not continue to link/status loops while the plugin is not installed.
That keeps the IM flow bounded and avoids the "agent keeps retrying setup forever" failure mode.
|
|
||
| - Run the upstream helper script at `${HERMES_HOME:-$HOME/.hermes}/plugins/mem9/scripts/link-memory-provider.sh`. | ||
| - If the helper script cannot locate the Hermes repo automatically, rerun it with `HERMES_PROJECT_ROOT` set for that one command only. | ||
| - Re-run `hermes memory status` to confirm. |
There was a problem hiding this comment.
The link-repair flow shouldn't rely on link-memory-provider.sh to flip the active provider for us. In a non-TTY / IM context the active provider can stay on whatever Hermes had before, so hermes memory status will keep returning "not active" even though the symlink is correct.
Per the IM-flow rule (after install/link succeeds, activate non-interactively), please add an explicit set step before re-verifying:
# Set mem9 as the active provider non-interactively
hermes config set memory.provider mem9
# Then verify
hermes memory statusThis matches the sequence already documented in TROUBLESHOOTING.md → "mem9 Is Installed But Not Active".
|
@codex review Please take another pass focused on the Hermes IM-flow. Three concrete gaps just flagged inline:
Confirm these three are the only remaining gaps in the Hermes flow, and flag anything adjacent (e.g. similar interactive-picker risks, missing fail-stops elsewhere) you'd like tightened in the same round. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9ec2d35e19
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| - Run the upstream helper script at `${HERMES_HOME:-$HOME/.hermes}/plugins/mem9/scripts/link-memory-provider.sh`. | ||
| - If the helper script cannot locate the Hermes repo automatically, rerun it with `HERMES_PROJECT_ROOT` set for that one command only. | ||
| - Re-run `hermes memory status` to confirm. |
There was a problem hiding this comment.
Set mem9 active after repairing the provider link
When the install reaches the link-repair path because hermes memory status does not show mem9, running link-memory-provider.sh only repairs provider discovery; it does not necessarily switch the active provider in non-TTY runs that are still pinned to a previous memory.provider. Add an explicit hermes config set memory.provider mem9 after the helper and before the next status check so this repair path can actually activate mem9 instead of looping or reporting failure with the link fixed.
Useful? React with 👍 / 👎.
| - Do not replace it with ad hoc shell logic when the upstream script is available. | ||
| - If the install script already completes install, setup, and verification, do not repeat those steps unnecessarily. | ||
| - The upstream README says this script installs the plugin, obtains or reuses an API key, writes `.env`, writes `mem9.json`, and creates the provider symlink. | ||
| - If the script installs the plugin but reports a connectivity failure or leaves mem9 inactive, continue to Step 3. |
There was a problem hiding this comment.
Stop or fall back when the install script fails
In the IM install flow, a non-zero install.sh result is not handled separately from the partial-success case, so an agent can continue into link/status repair commands even though the plugin may not have been installed at all. This step should explicitly fail-stop on a non-zero script exit, try the Step 3b hermes plugins install ... fallback when appropriate, and stop with a clear error if both paths fail.
Useful? React with 👍 / 👎.
| - Read `hermes version` | ||
| - Run the official install script from `mem9-ai/mem9-hermes-plugin` | ||
| - Run `hermes plugins install mem9-ai/mem9-hermes-plugin` only as a fallback when the official install script is unavailable or when the upstream instructions explicitly require the manual path | ||
| - Run the upstream helper script `link-memory-provider.sh` from the installed mem9 Hermes plugin when the Hermes provider link is missing |
There was a problem hiding this comment.
Allow provider config on the link-repair path
The allowed scope still permits hermes config set memory.provider mem9 only on the manual fallback path, which conflicts with the needed non-interactive activation after link-memory-provider.sh repairs an installed-but-inactive provider. If SETUP.md tells agents to set the provider during link repair, this scope line will block or confuse that action; broaden it to include the provider-link repair path as well.
Useful? React with 👍 / 👎.
Summary
https://mem9.ai/SKILL.mdinto a backward-compatible launcher that routes users to the correct client-specific skillutm_*params when handing off from the legacy launcher to the platform-specific skillhttps://mem9.ai/openclaw/SKILL.mdas the canonical OpenClaw entrypointWhy
The previous public
SKILL.mdassumed an OpenClaw-only install flow. Now that Hermes has its own install path, we need client-specific onboarding documents so agents do not mix OpenClaw and Hermes commands or config. Keeping/SKILL.mdas a launcher preserves backward compatibility for existing links while making the canonical install URLs explicit.Scope
This is a site/content change only:
site/public/hermes/SKILL.mdsite/public/openclaw/SKILL.mdsite/public/SKILL.mdas a router/launcher