# Edición en español

Esta versión en español fue preparada para que la experiencia principal del producto sea en español. El nombre de marca **AI Operator Playbook** se mantiene igual.

---

# AI Operator Playbook

## Cómo contratar una IA en OpenClaw
### La guía práctica para convertir un asistente de IA en un sistema operativo de trabajo real

**Subtitle**
A practical implementation guide inspired by *How to Hire an AI* and expanded with real-world lessons from building and operating Rika.

---

## Nota inicial
La mayoría de personas no tienen un problema de calidad de IA.
Tienen un problema de sistema.

They are working with a smart model inside a weak operating environment.
The model can answer questions, generate drafts, and sound impressive — but it still forgets context, loses priorities, stalls between sessions, and depends too much on repeated prompting.

That is not because the model is useless.
It is because intelligence without structure does not become operations.

This guide exists to solve that.

AI Operator Playbook is the practical operating model for using OpenClaw as a sistema estructurado de trabajo con IA.
It translates the core principles into a concrete implementation pattern:
- durable memory
- explicit identity
- real tool use
- safe autonomy
- project continuity
- Mission Control
- reset recovery
- cost-aware context design

Esto no es un libro de prompts.
This is not a generic AI automation pitch.
Esto es un sistema para trabajo real.

---

# Part 1 — The Problem

## Por qué fallan la mayoría de asistentes con IA
Most people still use AI as an isolated chat experience.
That works for one-off help.
It breaks down when the AI is supposed to help manage ongoing work.

The failure pattern is predictable:
- the assistant forgets decisions between sessions
- projects get split across chats, files, and half-finished notes
- the user keeps repeating preferences and priorities
- the assistant offers ideas but does not maintain momentum
- autonomy feels risky because boundaries are vague
- every reset feels like partial amnesia

## Chat suelto vs sistema operativo
When you **use** AI:
- you ask for answers
- the interaction is mostly disposable
- continuity is weak
- the AI is treated like a tool on demand

When you **hire** AI:
- you define a role
- you give it structure
- you create expectations
- you build continuity
- you let it take responsibility within limits

That is the shift AI Operator Playbook is built around.

---

# Part 2 — The Operator Model

Everything starts with five core principles:
1. Persistence
2. Identity
3. Tools
4. Autonomy
5. Accountability

## Safe bounded operation
A real operator needs clear rules around:
- what it can do safely on its own
- what requires approval
- what it should never do

**Rule:** be bold internally and restrained externally.

---

# Part 3 — The AI Operator Playbook Stack

The stack is:
- model
- identity
- memory
- tools
- safety rails
- cadence
- project architecture
- Mission Control

## The most important differentiator: Mission Control
Mission Control is the compact control board that answers:
- what matters now?
- what matters next?
- what is blocked?
- what belongs to the human?
- where should the assistant resume after reset?

Identity makes the assistant coherent.
Memory makes it persistent.
Tools make it capable.
Mission Control makes it steerable.

---

# Part 4 — Install the Workspace

## Minimum structure
- `AGENTS.md`
- `IDENTITY.md`
- `SOUL.md`
- `USER.md`
- `MEMORY.md`
- `STATE-OF-WORK.md`
- `RECOVERY.md`
- `MISSION-CONTROL.md`
- `MISSION-CONTROL-RUNBOOK.md`
- `TOOL-PERMISSIONS.md`
- `docs/`
- `memory/`
- `projects/`
- `private/`

## Why this matters
Without a real workspace, the assistant sounds good but cannot operate consistently.

---

# Part 5 — Identity and Soul

## Identity files
- `IDENTITY.md` defines the assistant name, nature, and vibe.
- `SOUL.md` defines judgment, behavior, and style.
- `USER.md` defines who the assistant is helping and what matters.

## Group chat behavior
In group chats, the assistant should:
- contribute only when useful
- avoid clutter
- avoid leaking private context
- sound like a participant, not a broadcast bot

---

# Part 6 — Memory Architecture

## Memory layers
- long-term memory
- daily memory
- project memory
- system memory

## What not to store
Do not dump everything into long-term memory.
Store only durable facts, decisions, and preferences.

## Cleanup rule
Review and distill memory periodically.
Raw notes are not the same as durable truth.

---

# Part 7 — Mission Control in Practice

## Recommended structure
```md
# MISSION-CONTROL.md

## Highest Priority
- 

## Active Projects
- Project:
  - Status:
  - Next Action:
  - Owner:
  - Blocker:

## Now
- 

## Next
- 

## Later
- 

## User-Owned Items
- 

## Resume Points
- 
```

## Daily rhythm
- check highest priority
- review blockers
- confirm next useful action
- update resume points

## Weekly review
- remove stale work
- refine priorities
- identify systems drift

---

# Part 8 — Tools and Autonomy

## Tool permission matrix
### Safe internal actions
- read files
- organize docs
- draft plans
- update internal notes

### Ask-first actions
- send emails
- post publicly
- delete data
- spend money
- modify production systems

## Autonomy rule
Continue useful safe work without waiting for repeated prompts.
Ask only when risk, access, or uncertainty truly requires it.

---

# Part 9 — Project Execution Doctrine

A strong project rhythm is:
1. orientation
2. audit
3. architecture
4. prep
5. execution
6. optimization
7. continuity

Projects should live in files, not only inside chats.

---

# Part 10 — Reset Recovery

## Recovery checklist
1. read `SOUL.md`
2. read `USER.md`
3. read recent memory files
4. read `STATE-OF-WORK.md`
5. read `MISSION-CONTROL.md`
6. resume the highest-priority active project

## Success condition
A reset should slow work down temporarily, not destroy continuity.

---

# Part 11 — First 7 Days Plan

Day 1 — identity and workspace  
Day 2 — memory and user model  
Day 3 — Mission Control  
Day 4 — first project  
Day 5 — tool mapping  
Day 6 — recovery test  
Day 7 — optimization review

---

# Part 12 — Rika Delivery Layer

Rika is not just an example inside the guide.
Rika is the guided setup assistant behind AI Operator Playbook.

Responsibilities:
- onboarding
- customer classification
- implementation path
- package guidance
- follow-up
- upgrade recommendation

---

# Part 13 — Before vs After

## Before
- assistant forgets
- projects are scattered
- no memory system
- no Mission Control
- weak safety boundaries
- resets break momentum

## After
- clear identity
- real memory layers
- structured projects
- Mission Control
- safe autonomy
- explicit recovery path

---

# Part 14 — Troubleshooting and FAQ

## Common problem: the assistant is smart but inconsistent
Usually the issue is not the model.
Usually the issue is weak file architecture, weak memory, or no Mission Control.

## Common problem: I do not trust autonomy
Then the answer is not “less autonomy.”
The answer is better permission rules and clearer accountability.

## FAQ
### Do I need a better model?
Usually not first.
You usually need a better operating system first.

### Is this official OpenClaw?
No. AI Operator Playbook is an independent implementation framework for OpenClaw users.

### Is this just prompts?
No. It is a practical system for identity, memory, tools, safety, project continuity, and recovery.

---

# Part 15 — Customer Examples

## Example 1 — Solo Founder Operator
Use the system to manage projects, research, marketing, and task continuity.

## Example 2 — Business Operations Operator
Use the system to support real company workflows, reporting, operations, and internal execution.

## Example 3 — Product Delivery Operator
Use the system to sell, onboard, deliver, and support your own products with AI assistance.

---

# Part 16 — The Superpowers Execution Layer

AI Operator Playbook gives the operator structure.
The Superpowers layer improves how meaningful work gets executed.

## Why this matters
A good operator does not just have memory and files.
A good operator also needs disciplined execution.

This means:
- brainstorm before building
- write plans before implementing
- debug systematically before guessing
- verify before claiming done

## Recommended chain
For serious implementation work:
1. brainstorming
2. writing-plans
3. test-driven-development when practical
4. executing-plans or subagent-driven-development
5. systematic-debugging if something breaks
6. verification-before-completion

## Why it increases value
This turns AI Operator Playbook from only a setup framework into a more complete build-and-operate system.

# Closing line
Most people do not need better prompts.
They need an operating system for their AI.