8.2
/ 10
1 evaluations
1.8k Downloads
Overview
Provide a structured, repeatable playbook for renaming the Clawd project to OpenClaw, covering file moves, reference updates, tooling verification, and documentation changes so the migration doesn’t break builds or contributor workflows.
Key Advantages
1.Clear, step‑by‑step migration checklist from inventory to cleanup and communication.
2.Covers both code and non‑code artifacts (docs, personas, skills, CI configs, images).
3.Emphasizes validation via tests, linting, docs build, and CI configuration checks.
4.Includes guidance for keeping human‑facing metadata discoverable for contributors.
5.Defines explicit triggers and usage context, reducing misuse or over‑application of the skill.
Use Cases
- Guiding a contributor through renaming the clawdbot/ app root to openclaw/ without breaking builds.
- Creating or reviewing a migration plan/checklist for Clawd → OpenClaw branding in a specific repo.
- Answering questions about where old Clawd artifacts live after the OpenClaw migration.
- Helping maintainers verify that package.json scripts, pnpm workspaces, and tsconfig paths still resolve after renames.
- Updating documentation (README, docs/*.md, AGENTS/SOUL files) to consistently reference OpenClaw instead of Clawd.
Evaluation Scores
8.2
/ 10
Reliability
7.5
Functionality
8.8
Usability
8.5
Safety
8.0
Performance
8.0
Compatibility
8.5
Based on 1 evaluation · Latest: 3/20/2026
Download Trend
Loading...
Evaluation History (1)
8.2/103/20/2026▼
OS: linux-x64LLM: arcee-ai/trinity-large-preview
**Judgement:** This is a strong, well‑scoped internal migration playbook tailored to renaming a Clawd-based repo to OpenClaw. It gives a concrete, end‑to‑end checklist that should substantially reduce migration mistakes when used in the intended environment.
**Strengths:**
- Covers the full lifecycle: inventory → rename/copy → reference updates → tooling verification → documentation → cleanup.
- Explicitly calls out critical artifacts (AGENTS.md, SOUL.md, MEMORY.md, skills.json, docs/*.md, CI workflows, images like README-header.png).
- Encourages validation via `pnpm test`, `pnpm lint`, docs build steps, and CI/CD checks before cleaning up old structure.
- Provides usage triggers and communication guidance, so both humans and helpers know when and how to use it.
**Key Risks / Limitations:**
- **Repo-specific assumptions:** Assumes a `clawdbot/`-centric layout, pnpm tooling, and certain files existing; applying it to differently structured repos may cause confusion or partial migrations.
- **Branding-only focus:** It is optimized for Clawd → OpenClaw; it is not a generic rename/migration framework and may miss edge cases outside this scope.
- **Potential staleness:** As repo structure, tooling, or CI providers change, the instructions could become outdated unless the skill is maintained.
- **Manual, not automated:** It doesn’t automate changes; correctness depends on the user carefully following each step (including search/replace and validation).
**Recommended Scenarios:**
- You are actively migrating a repo that still uses `clawdbot/` and Clawd branding to an `openclaw/` structure and OpenClaw naming.
- A contributor asks “What’s the migration status?” or “How do we safely rename Clawd to OpenClaw?” and needs a concrete checklist.
- You’re reviewing a PR that performs the Clawd → OpenClaw migration and want a reference list of what should have been updated.
- You need to explain where legacy Clawd artifacts live post-migration and how to run or build the app from the new `openclaw/` entrypoints.
Comments (0)
No comments yet. Be the first!