Back to The Times of Claw

Setting Up OpenClaw for a Team: A Complete Guide

OpenClaw for teams: step-by-step setup guide covering shared workspaces, skill distribution, permissions, and multi-user workflows for engineering teams.

Mark Rachapoom
Mark Rachapoom
·7 min read
Setting Up OpenClaw for a Team: A Complete Guide

Setting up OpenClaw for a team is straightforward once you understand how the workspace model works. Each team member runs their own local OpenClaw instance, but through shared skill definitions and a common DuckDB schema, teams coordinate without centralizing data. Here's the complete setup walkthrough.

If you're new to OpenClaw and DenchClaw, start with what DenchClaw is and how it fits into your stack before continuing.

How OpenClaw's Team Model Works#

OpenClaw is local-first by design. That means there's no central server holding your team's data — each person's agent runs on their own machine. This sounds like it would fragment collaboration, but it doesn't, because the coordination layer is configuration, not data.

Think of it this way:

  • Skills define what agents can do → share these via Git
  • Schema defines what data looks like → version-control this
  • Entries are local → each person owns their own

Teams share the rules, not the records. This is the right model for most product and engineering orgs: you want consistent tooling without a centralized data silo.

Step 1: Install DenchClaw on Each Machine#

Every team member runs the same install command:

npx denchclaw

This scaffolds the workspace at ~/.openclaw-dench/workspace/ and starts the OpenClaw gateway. First-run setup takes under two minutes.

For teams with strict environment requirements, you can pin a version:

npx denchclaw@1.4.0

Tip: Add ~/.openclaw-dench/workspace/skills/ to your .gitignore if you're putting the workspace in version control — skills are installed separately via ClawHub.

Step 2: Create a Shared Skills Repository#

Skills are the core of team coordination in OpenClaw. A skill is a SKILL.md file that teaches the agent a new capability. When everyone on your team installs the same skills, they get the same agent behaviors.

Here's the recommended structure for a team skills repo:

team-skills/
├── crm-custom/
│   ├── SKILL.md
│   └── references/
│       └── field-definitions.md
├── sales-workflow/
│   ├── SKILL.md
│   └── scripts/
│       └── lead-score.sql
├── engineering/
│   └── SKILL.md
└── README.md

Creating a skill:

mkdir -p team-skills/crm-custom
cat > team-skills/crm-custom/SKILL.md << 'EOF'
# CRM Custom Skill
 
This skill extends the default CRM with company-specific fields and workflows.
 
## Fields
 
All leads must have:
- `lead_score` (integer, 0-100)
- `source` (text: "inbound" | "outbound" | "referral")
- `assigned_to` (text: team member name)
 
## Commands
 
When asked to score a lead:
1. Query their engagement history from entry_fields
2. Apply the scoring rubric in references/field-definitions.md
3. Update lead_score via DuckDB UPDATE
EOF

Push this to a private GitHub repo. Team members install via:

clawhub install github:your-org/team-skills

Step 3: Distribute the DuckDB Schema#

Each team member's DenchClaw workspace has a workspace.duckdb file. The schema is consistent by default (objects, fields, entries, entry_fields tables), but you may want custom objects or field definitions.

Option A: Schema migration file

Create a schema-migrations/ folder in your shared repo with numbered SQL files:

-- schema-migrations/001_add_lead_score.sql
ALTER TABLE entry_fields ADD COLUMN IF NOT EXISTS lead_score INTEGER DEFAULT 0;
 
INSERT INTO fields (object_type, field_key, field_label, field_type)
VALUES ('contact', 'lead_score', 'Lead Score', 'integer')
ON CONFLICT DO NOTHING;

Document in your README that new team members should run these in order after installation.

Option B: Seed script

For more complex setups, write a seed script:

#!/bin/bash
# team-skills/scripts/seed-schema.sh
DB="$HOME/.openclaw-dench/workspace/workspace.duckdb"
 
duckdb "$DB" < schema-migrations/001_add_lead_score.sql
duckdb "$DB" < schema-migrations/002_add_pipeline_stages.sql
 
echo "Schema seeded successfully"

The full setup guide covers the default schema in detail.

Step 4: Configure Agent Personas per Role#

Different team members need different agent behaviors. A sales rep's agent should default to CRM operations; an engineer's agent should default to code review and deployment.

Create role-specific SOUL.md templates in your shared repo:

# SOUL.md - Sales Agent
 
You are a sales-focused agent. Your primary tools are the CRM skill and browser automation.
 
When the user says "check my leads", run:
1. Query contacts with status='Lead' from DuckDB
2. Sort by lead_score DESC
3. Present the top 5 with their last activity date
 
Default to brief, action-oriented responses. The user is busy.

Team members copy the relevant template to ~/.openclaw-dench/workspace/SOUL.md after installation.

Step 5: Set Up Shared Document Templates#

The workspace docs/ folder stores markdown documents that persist in DuckDB. For teams, you want consistent document templates — meeting notes, call logs, proposal outlines.

# In your team skills repo
mkdir -p team-skills/templates
cat > team-skills/templates/call-log.md << 'EOF'
# Call Log: {{contact_name}} — {{date}}
 
**Duration:** 
**Attendees:** 
**Summary:** 
 
## Key Points
 
-
 
## Action Items
 
- [ ]
 
## Next Steps
 
**Next call:** 
EOF

Instruct team members to copy templates/ into ~/.openclaw-dench/workspace/docs/templates/.

Step 6: Establish Skill Update Workflow#

Skills evolve. When you update a team skill, you need a rollout process.

Recommended workflow:

  1. Author updates the skill in the team repo
  2. Open a PR with a clear description of what changed
  3. Team lead reviews and merges
  4. Send a Slack/Discord message: "New skill version. Run clawhub update team-skills to install."
  5. Team members run the update command

This is the same Git-based workflow you use for code — because skills are code.

Step 7: Onboarding New Team Members#

Document an onboarding checklist in your repo's README:

## New Team Member Setup
 
1. `npx denchclaw` — installs and starts OpenClaw
2. `clawhub install github:your-org/team-skills` — installs team skills
3. Copy `team-skills/soul-templates/[your-role].md``~/.openclaw-dench/workspace/SOUL.md`
4. Run `./scripts/seed-schema.sh` — applies schema migrations
5. Open DenchClaw in browser: http://localhost:3000
6. Ask the agent: "What can you do?" — verify skills loaded correctly

Onboarding should take under 15 minutes. If it takes longer, your setup is too complex.

Team Patterns That Work Well#

Async knowledge sharing: When someone writes a useful SQL query or DuckDB pattern, add it to a shared skill's references/ folder. Over time, this becomes a team knowledge base the agent can actually use.

Lightweight CRM sync: Some teams use a lightweight sync script (via cron) to export key CRM fields to a shared Google Sheet. The agent writes locally; the Sheet provides visibility. Not ideal long-term, but works for small teams.

Review before external sends: Add a rule to team SOUL.md: "Never send emails, Slack messages, or external communications without explicit confirmation." This prevents the agent from acting on partial context.

What Not to Do#

Don't share the actual workspace.duckdb file. It contains personal context, memory files, and private CRM data. Share schema definitions, not data.

Don't put API keys in SOUL.md or skills. Use environment variables instead. OpenClaw reads from .env in the workspace root.

Don't skip versioning your skills. Unversioned skills drift. Six months in, you won't remember what changed, and debugging will be painful.

FAQ#

Can multiple people access the same OpenClaw instance? No — OpenClaw is designed as a single-user local agent. Each team member runs their own instance. Shared access would require a hosted deployment, which is possible but not the default model.

How do we handle shared contacts/leads? The recommended pattern is to export/import contact data via CSV when needed, or build a sync skill that pulls from your team's CRM of record. DenchClaw's DuckDB schema makes this straightforward with standard SQL.

What happens if someone's skills are out of date? The agent will behave differently from the rest of the team. Add a clawhub update check to your weekly team sync checklist. ClawHub (clawhub.ai) tracks installed versions.

Can we use OpenClaw with a self-hosted LLM? Yes. OpenClaw routes to whichever model you configure. For teams with data residency requirements, routing to an on-premise Ollama instance or a private Azure OpenAI deployment is straightforward.

Is there an enterprise support tier? DenchClaw is MIT licensed and community-supported. For enterprise contracts, reach out via dench.com.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →

Mark Rachapoom

Written by

Mark Rachapoom

Building the future of AI CRM software.

Continue reading

DENCH

© 2026 DenchHQ · San Francisco, CA