القائمة
Sync files with centralized storage. Use when your coordinator or another Worker notifies you of file updates (config changes, task files, shared data, collaboration artifacts).
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Analyze current OpenClaw setup and generate a migration package (ZIP) for importing into HiClaw as a managed Worker
Use before direct filesync calls, reading non-task shared files, pushing mid-task progress, or troubleshooting missing shared files. Do not use for normal task acceptance or submission; taskflow ack_task and submit_task handle lifecycle sync internally.
Discover and install agent skills from the open ecosystem. Use when you encounter an unfamiliar domain, framework, or workflow that you lack specialized knowledge about, or when your coordinator suggests searching for skills before starting a task.
Use only when you need to look up team topology, worker phase, runtime state, or identity that is NOT available from the current message context. Do not use for standard task flows — the coordinator is the message sender, and the task room is in meta.json.room_id.
Discover and install agent skills from the open ecosystem. Use when you encounter an unfamiliar domain, framework, or workflow that you lack specialized knowledge about, or when your coordinator suggests searching for skills before starting a task.
Sync files with centralized storage. Use when your coordinator or another Worker notifies you of file updates (config changes, task files, shared data, collaboration artifacts).
| name | file-sync |
| description | Sync files with centralized storage. Use when your coordinator or another Worker notifies you of file updates (config changes, task files, shared data, collaboration artifacts). |
When your coordinator notifies you that your config has been updated (e.g., model switch, skill update), trigger an immediate sync:
hermes-sync
This pulls openclaw.json, SOUL.md, AGENTS.md, and skills from MinIO and re-bridges the config into ~/.hermes/ (config.yaml + .env).
Hot reload caveats:
SOUL.md on the next message — no restart needed~/.hermes/skills/ are picked up on the next message as wellconfig.yaml (model, terminal, matrix behavior) require a process restart — your coordinator handles this when neededAutomatic background sync:
The shared/ directory is automatically mirrored from MinIO at startup and every sync cycle. No manual pull is needed.
Task and project files are at:
| Local path (auto-synced) |
|---|
shared/tasks/{task-id}/ |
shared/projects/{project-id}/ |
# Read the spec (already synced locally)
cat shared/tasks/{task-id}/spec.md
# Push your results back to MinIO (push is still manual)
bash ./skills/file-sync/scripts/push-shared.sh tasks/{task-id}/ --exclude "spec.md" --exclude "base/"
The push-shared.sh script automatically detects your team and pushes to the correct MinIO path.
When to use:
push-shared.shhermes-sync to trigger an immediate pullAlways confirm to the sender after push completes.
Example workflow:
# Coordinator assigns task: "New task [st-01]. Please file-sync and read shared/tasks/st-01/spec.md"
# Run file-sync to pull latest
hermes-sync
# Read the spec
cat shared/tasks/st-01/spec.md
# ... do the work ...
# Push results
bash ./skills/file-sync/scripts/push-shared.sh tasks/st-01/ --exclude "spec.md" --exclude "base/"
# Confirm to coordinator
"Task complete. Results pushed to MinIO."