bd0be97630
This repo IS Atlas (总助 Claw / 老板视角项目执行雷达). The earlier
two-profile framing (Atlas + Vega placeholder) was a misread — Vega is
the agent persona answering Multica issues, not the product. Vega has
no relationship to assistant-claw the product.
Changes:
- Move atlas/* to top-level (git mv preserves history)
- Remove empty Vega placeholders prompts/.gitkeep, tools/.gitkeep
- Delete atlas/ wrapper directory (now empty)
- Update path references in INTEGRATION-hermes.md, scripts/mirror-...sh,
docs/decisions/0001-mirror-nuwa-skill.md
- Rewrite README.md as Atlas-only, remove dual-profile language
After this commit:
- Top-level OpenClaw 8 files (IDENTITY/SOUL/USER/AGENTS/TOOLS/MEMORY/
BOOTSTRAP/HEARTBEAT + CLAUDE symlink + zh-CN mirrors)
- skills/{6 sub-skills + DESCRIPTION + README}
- mcp-tools/{spec + Python implementation}
- state-schemas/{project, person, customer + README}
- autopilots/{5 atlas-*.yaml}
- client-deck/, docs/decisions/, scripts/
The ~/.hermes/skills/atlas/ destination convention preserved (atlas as
a skill namespace on the operator's machine, distinct from source path).
|
||
|---|---|---|
| .. | ||
| email-extractor | ||
| email-extractor.md | ||
| README.md | ||
MCP Tools Inventory
Atlas's hands. Skills are the brain; MCP tools (and CLI commands) are how the brain reaches the world.
| Tool | Status | Spec |
|---|---|---|
| email-fetch | V0 | (in email-extractor.md Stage 1) |
| email-extractor | V0 — critical | email-extractor.md |
| state-io | V0 | TBD — read/write state/*.json with optimistic locking |
| report-render | V0 | TBD — Markdown → PDF / HTML / WeChat-card |
| email-send | V0 (boss only) | TBD — sends Brief to boss only; refuses any other recipient in V0 |
| rule-audit | V0 | TBD — append-only audit log of which rules fired on which judgments |
| wechat-fetch | V0.5 | TBD |
| feishu-fetch | V1 | TBD |
Why MCP and not just plain CLI
For V0, plain Python CLI tools are fine. We move to MCP-server style when:
- The same tool needs to be callable by multiple Claws (e.g., Atlas + Zero both want to read state)
- We want fine-grained per-tool permission gates
- We deploy Atlas as a hosted multi-client SaaS
For now: CLI commands callable from skill prompts via Bash is the V0 model. MCP wrapping is a V0.5 refactor.
Tool Authorization Matrix
| Tool | Can Atlas call autonomously? | Requires boss approval? |
|---|---|---|
| email-fetch | ✅ | No (configured at install) |
| email-extractor | ✅ | No |
| state-io read | ✅ | No |
| state-io write | ✅ | No (state is Atlas's working memory) |
| report-render | ✅ | No |
| email-send (Brief to boss) | ✅ | No (auth granted at install) |
| email-send (anything else) | ❌ in V0 | Always |
| boss_skill.md write | ❌ in V0 | Always — boss audits diff |