# AGENTS.md โ€” AI Workspace Guide > _"The Overmind speaks through many voices, but with one purpose."_ Welcome, AI agent. This document defines how you should interact with this codebase. ## โš ๏ธ CRITICAL: Pull Request Workflow **All changes to this repository MUST go through pull requests.** This is a public open source project. Even maintainers (including AI agents working on behalf of maintainers) must: 1. Create a feature branch (`git checkout -b type/description`) 2. Make changes and commit 3. Push branch and open a PR 4. Get approval before merging **Never push directly to `main`.** This applies to everyone, including the repo owner. ## ๐ŸŽฏ Mission OpenClaw Command Center is the central dashboard for AI assistant management. Your mission is to help build, maintain, and improve this system while maintaining the Starcraft/Zerg thematic elements that make it unique. ## ๐Ÿ›๏ธ Architecture **Read First**: [`docs/architecture/OVERVIEW.md`](docs/architecture/OVERVIEW.md) Key architectural principles: 1. **DRY** โ€” Don't Repeat Yourself. Extract shared code to partials/modules. 2. **Zero Build Step** โ€” Plain HTML/CSS/JS, no compilation needed. 3. **Real-Time First** โ€” SSE for live updates, polling as fallback. 4. **Progressive Enhancement** โ€” Works without JS, enhanced with JS. ## ๐Ÿ“ Workspace Structure ``` openclaw-command-center/ โ”œโ”€โ”€ lib/ # Core server logic โ”‚ โ”œโ”€โ”€ server.js # Main HTTP server and API routes โ”‚ โ”œโ”€โ”€ config.js # Configuration loader with auto-detection โ”‚ โ”œโ”€โ”€ jobs.js # Jobs/scheduler API integration โ”‚ โ”œโ”€โ”€ linear-sync.js # Linear issue tracker integration โ”‚ โ””โ”€โ”€ topic-classifier.js # NLP-based topic classification โ”œโ”€โ”€ public/ # Frontend assets โ”‚ โ”œโ”€โ”€ index.html # Main dashboard UI โ”‚ โ”œโ”€โ”€ jobs.html # AI Jobs management UI โ”‚ โ”œโ”€โ”€ partials/ # โญ Shared HTML partials (DRY!) โ”‚ โ”‚ โ””โ”€โ”€ sidebar.html # Navigation sidebar component โ”‚ โ”œโ”€โ”€ css/ โ”‚ โ”‚ โ””โ”€โ”€ dashboard.css # Shared styles โ”‚ โ””โ”€โ”€ js/ โ”‚ โ”œโ”€โ”€ sidebar.js # Sidebar loader + SSE badges โ”‚ โ”œโ”€โ”€ app.js # Main dashboard logic โ”‚ โ””โ”€โ”€ lib/ # Third-party libraries โ”œโ”€โ”€ scripts/ # Operational scripts โ”œโ”€โ”€ config/ # Configuration (be careful!) โ”œโ”€โ”€ docs/ # Documentation โ”‚ โ””โ”€โ”€ architecture/ # Architecture Decision Records โ”œโ”€โ”€ tests/ # Test files โ”œโ”€โ”€ SKILL.md # ClawHub skill metadata โ””โ”€โ”€ package.json # Version and dependencies ``` ## โœ… Safe Operations Do freely: - Read any file to understand the codebase - Create/modify files in `lib/`, `public/`, `docs/`, `tests/` - Add tests - Update documentation - Create feature branches ## โš ๏ธ Ask First Check with a human before: - Modifying `config/` files - Changing CI/CD workflows - Adding new dependencies to `package.json` - Making breaking API changes - Anything touching authentication/secrets ## ๐Ÿšซ Never - **Push directly to `main` branch** โ€” ALL changes require PRs - Commit secrets, API keys, or credentials - Commit user-specific data files (see `public/data/AGENTS.md`) - Delete files without confirmation - Expose internal endpoints publicly ## ๐Ÿ› ๏ธ Development Workflow ### 0. First-Time Setup ```bash # Install pre-commit hooks (required for all contributors) make install-hooks # Or manually: cp scripts/pre-commit .git/hooks/pre-commit chmod +x .git/hooks/pre-commit ``` The pre-commit hook enforces rules from this file automatically. ### 1. Feature Development ```bash # Create feature branch git checkout -b feat/your-feature-name # Make changes, then test locally npm test npm run lint make check # Run pre-commit checks manually # Commit with descriptive message git commit -m "feat: add overlord status indicator" # Push and create PR git push -u origin feat/your-feature-name ``` ### 2. Commit Message Convention Follow [Conventional Commits](https://www.conventionalcommits.org/): - `feat:` โ€” New feature - `fix:` โ€” Bug fix - `docs:` โ€” Documentation only - `style:` โ€” Formatting, no code change - `refactor:` โ€” Code restructuring - `test:` โ€” Adding tests - `chore:` โ€” Maintenance tasks ### 3. Code Style - Use ESLint configuration provided - Prettier for formatting - JSDoc comments for public functions - Meaningful variable names (thematic names encouraged!) ## ๐Ÿ“ฆ ClawHub Skill Workflow This project is distributed as a ClawHub skill. After changes are merged to `main`, they need to be published to the registry so users can install/update via `clawhub install command-center`. ### Understanding Skill Metadata Two files control the skill identity: - **`SKILL.md`** โ€” Frontmatter (`name`, `version`, `description`) used by ClawHub for discovery and search - **`package.json`** โ€” `version` field for npm compatibility โš ๏ธ **CRITICAL: Version Sync Required** Both `package.json` and `SKILL.md` **MUST have the same version number**. This is enforced by pre-commit hooks. ```bash # If you change version in one file, change it in both: # package.json: "version": "1.0.4" # SKILL.md: version: 1.0.4 ``` The pre-commit hook will block commits if versions are out of sync. ### Publishing Updates ```bash # 1. Authenticate (one-time) clawhub login clawhub whoami # 2. Bump version in package.json (follow semver) # patch: bug fixes (0.1.0 โ†’ 0.1.1) # minor: new features (0.1.0 โ†’ 0.2.0) # major: breaking changes (0.1.0 โ†’ 1.0.0) # 3. Tag the release git tag -a v -m "v โ€” short description" git push origin --tags # 4. Publish (--registry flag required until upstream redirect is fixed) clawhub publish . --registry https://www.clawhub.ai \ --slug command-center --version \ --changelog "Description of what changed" ``` ### Verifying a Publish ```bash # Check published metadata clawhub inspect command-center # Test install into a workspace clawhub install command-center --workdir /path/to/workspace ``` ### Updating an Installed Skill Users update with: ```bash clawhub update command-center ``` The installed version is tracked in `.clawhub/origin.json` within the skill directory. ### Who Can Publish? Only maintainers with ClawHub credentials for `jontsai/command-center` can publish. Currently: - @jontsai (owner) Contributors: Submit PRs. After merge, a maintainer will handle the ClawHub publish. ### Release Checklist Before publishing a new version: 1. [ ] All PRs for the release are merged to `main` 2. [ ] Version bumped in both `package.json` and `SKILL.md` frontmatter 3. [ ] CHANGELOG updated (if maintained) 4. [ ] Tests pass: `npm test` 5. [ ] Lint passes: `npm run lint` 6. [ ] Git tag created: `git tag -a v -m "v"` 7. [ ] Tag pushed: `git push origin --tags` 8. [ ] Published to ClawHub with changelog ## ๐ŸŽจ Thematic Guidelines This project has a Starcraft/Zerg theme. When naming things: | Concept | Thematic Name | | ------------------ | ------------- | | Main controller | Overmind | | Worker processes | Drones | | Monitoring service | Overlord | | Cache layer | Creep | | Message queue | Spawning Pool | | Health check | Essence scan | | Error state | Corrupted | Example: ```javascript // Instead of: const cacheService = new Cache(); const creepLayer = new CreepCache(); // Instead of: function checkHealth() function scanEssence() ``` ## ๐Ÿ“ Documentation Standards When you add features, document them: 1. **Code comments** โ€” JSDoc for functions 2. **README updates** โ€” If user-facing 3. **API docs** โ€” In `docs/api/` for endpoints 4. **Architecture Decision Records** โ€” In `docs/architecture/` for major changes ## ๐Ÿงช Testing ```bash # Run all tests npm test # Coverage report npm run test:coverage ``` Aim for meaningful test coverage. Test the logic, not the framework. ## ๐Ÿ› Debugging ```bash # Enable all command-center debug output DEBUG=openclaw:* npm run dev # Specific namespaces DEBUG=openclaw:api npm run dev DEBUG=openclaw:overlord npm run dev ``` ## ๐Ÿ”„ Handoff Protocol When handing off to another AI or ending a session: 1. Commit all work in progress 2. Document current state in a comment or commit message 3. List any unfinished tasks 4. Note any decisions that need human input ## ๐Ÿ“– Lessons Learned ### DRY is Non-Negotiable **Problem**: Sidebar was duplicated across `index.html` and `jobs.html`, causing inconsistencies. **Solution**: Extract to `/partials/sidebar.html` + `/js/sidebar.js` for loading. **Lesson**: When you see similar code in multiple places, stop and extract it. The cost of extraction is always lower than maintaining duplicates. ### Naming Consistency Matters **Problem**: "Scheduled Jobs" vs "Cron Jobs" vs "Jobs" caused confusion. **Solution**: Established naming convention: "Cron Jobs" for OpenClaw scheduled tasks, "AI Jobs" for advanced agent jobs. **Lesson**: Agree on terminology early. Document it. Enforce it. ### Zero-Build Architecture Has Trade-offs **Context**: No build step keeps things simple but limits some patterns. **Solution**: Use `fetch()` to load partials dynamically, `