openclaw worker kit

turn a plain-language job title into a governed worker pack.

this repo is for non-technical operators who want a usable worker, not a vague "ai employee" pitch.

how it works

1. fill out role-intake.md
2. paste it into worker-pack-generator-prompt.md
3. run the prompt in the model of your choice
4. review the output against the guides
5. drop the resulting files into your openclaw workspace
6. start with a packet worker, not a live execution worker

read start-here.md for the full step-by-step.

read guides/walkthrough.md to see the entire process from intake to month one.

repo structure

openclaw-worker-kit/
├── start-here.md                  # step-by-step instructions
├── role-intake.md                 # plain-language questionnaire
├── worker-pack-generator-prompt.md # the prompt that builds your worker pack
├── openclaw.json5.example         # starter config posture
│
├── templates/                     # what the generator produces
│   ├── agents.md                  # operating contract
│   ├── soul.md                    # tone and behavior
│   ├── tools.md                   # allowed, restricted, blocked tools
│   ├── standing-orders.md         # recurring programs
│   ├── review-gates.md            # approval rules
│   ├── memory-rules.md            # what gets stored, what doesn't
│   └── deliverables.md            # output format
│
├── examples/                      # complete worker packs, fully filled in
│   ├── sales-follow-up-worker.md
│   ├── research-packet-worker.md
│   ├── client-support-worker.md
│   ├── ops-assistant-worker.md
│   └── content-repurposing-worker.md
│
├── guides/                        # safety, boundaries, and walkthrough
│   ├── walkthrough.md             # full intake-to-output demo
│   ├── what-to-leave-manual-first.md
│   └── trust-boundary-checklist.md
│
├── LICENSE
└── README.md

what a worker pack includes

• role and scope (what the worker does and doesn't do)
• source-of-truth ranking (which system wins when records disagree)
• review gates (what always needs approval)
• memory rules (what gets stored, what never gets stored)
• tool posture (what's allowed, restricted, or blocked)
• failure behavior (what happens when the worker gets stuck)
• deliverable shape (the exact output format, every time)
• escalation path (when to stop and ask for help)
• first-month posture (tighter gates for the first 30 days)
• failure modes to watch (the most likely ways this worker will drift)

how to use this with openclaw

workspace files load at the start of every session through the bootstrap.

recommended placement after you generate a worker pack:

workspace root (auto-injected every session):

• agents.md
• soul.md
• tools.md
• memory.md (renamed from memory-rules.md)

referenced from agents.md:

• standing-orders.md
• review-gates.md
• deliverables.md

good first worker types

• meeting recap packet worker
• sales follow-up draft worker
• support triage packet worker
• research brief worker
• content repurposing draft worker

bad first worker types

• "do everything" assistant
• live outbound closer
• worker with financial authority
• worker touching five systems with no rollback
• worker with broad browser and filesystem access on day one

what this repo is not

• not a no-thought autopilot
• not a promise of safe autonomy
• not a replacement for process design
• not a drop-in replacement for openclaw docs

it's a design kit. the operating layer is the product.

when review gets boring, the worker is getting usable.