Clawchief Turns OpenClaw Into a Founder's Operating System

What it does

Clawchief is a portable operating model for OpenClaw that turns a general-purpose AI assistant into a persistent chief of staff. It ships a set of markdown policy files, skill definitions, cron templates, and workspace scaffolding that give an AI agent the context it needs to triage your inbox, manage your calendar, track tasks, process meeting notes, and run business development outreach — all without asking you every five minutes.

Why I starred it

Most AI assistant setups I've seen are glorified prompt libraries. You paste a system prompt, run a query, and lose all state when the session ends. Clawchief takes the opposite approach: it builds a persistent operational layer where the AI knows your priorities, understands when it can act autonomously, and maintains a canonical task file across sessions. The repo came out of Ryan Carson's real-world rollout, and the architecture borrows ideas from Pedro Franceschi's OpenClaw setup (discussed on the Core Memory podcast). What caught my eye is that someone actually codified the decision framework most founders carry around in their heads — who matters, what's urgent, when to act vs. when to ask.

How it works

The architecture separates concerns into five source-of-truth files in clawchief/:

clawchief/
├── priority-map.md        # who/what matters, urgency levels
├── auto-resolver.md       # when to act, draft, escalate, or ignore
├── meeting-notes.md       # ingestion policy for meeting notes
├── tasks.md               # canonical live task state
└── tasks-completed.md     # archive for completed tasks

The priority map (clawchief/priority-map.md) is the most interesting piece. It defines four urgency levels (P0 through P3) and four action modes: interrupt now, handle and summarize, queue for digest, and ignore. Every incoming signal gets mapped against people categories (principal, core family, key operators, strategic relationships, warm prospects) and programs (revenue, EA ops, board comms, legal, biz dev, marketing, product). The routing rules at the bottom are where the real logic lives — if a signal hits the principal and a revenue-critical program, it's automatically high priority. If it touches legal, the system biases toward caution.

The auto-resolver (clawchief/auto-resolver.md) defines three resolution lanes. The safe auto-resolve lane handles low-risk operational work: updating tasks, sending scheduling confirmations, creating follow-ups. The draft-first lane catches anything requiring the principal's voice — investor messaging, legal answers, pricing decisions. The escalate lane is for signals with too much ambiguity to safely draft. The key rule: "After classifying a signal, prefer to resolve the obvious next step instead of merely summarizing it."

The skills in skills/ are where workflows live. The executive-assistant skill (skills/executive-assistant/SKILL.md) is the most detailed — it defines a bounded sweep workflow that searches Gmail by message (not thread), classifies each message into action buckets, and handles scheduling directly through gog (a Google Workspace CLI). One specific detail I liked: it explicitly requires gog gmail send --reply-to-message-id=... for thread replies instead of plain sends with a Re: subject, which preserves proper threading.

The daily-task-prep skill (skills/daily-task-prep/SKILL.md) runs as an isolated cron job. It reads the task file, checks calendars, archives yesterday's completed tasks into clawchief/tasks-completed.md, promotes backlog items with today's due date into the ## Today section, and adds principal-owned meetings. The safety rules are well thought out — it won't wipe ## Today to rebuild it, won't archive tasks completed today during the same prep run, and preserves manually added items.

The cron template (cron/jobs.template.json) ties it together:

{
  "name": "Executive assistant sweep",
  "schedule": { "kind": "cron", "expr": "*/15 8-21 * * *" },
  "sessionTarget": "main",
  "payload": {
    "kind": "systemEvent",
    "text": "Executive assistant sweep. Use the executive-assistant skill."
  }
}

Every 15 minutes during work hours, the system sweeps the inbox and calendar. Daily task prep runs at 2 AM as an isolated session. Business development sourcing runs once daily. The prompts stay short — the skills carry the workflow logic.

Using it

Installation follows a seven-step process. You clone the repo, set up gog for Google Workspace access, copy skills into ~/.openclaw/skills/, copy clawchief/ and workspace/ into ~/.openclaw/workspace/, replace placeholder tokens like {{OWNER_NAME}} and {{TIMEZONE}}, create cron jobs from the template, and validate with the install checklist.

The task file uses a structured markdown format:

## Today
### Principal
#### Revenue / customer growth
- [ ] Close the Acme deal
### Assistant
#### Executive assistant
- [ ] Follow up on scheduling thread with Jane — due 2026-04-03

## Every weekday
#### Revenue / customer growth
- Ship one concrete growth action

## Backlog with due date
- Principal: board deck review — due 2026-04-15

Tasks group under owner (principal vs. assistant) and program headers that match the priority map. The daily prep job moves items between sections automatically.

Rough edges

The repo is three days old with three commits. There are no tests, no CI, and no programmatic logic — it's entirely markdown policy files and templates. Whether that's a limitation depends on how you see it. The design deliberately pushes all execution to OpenClaw's runtime, which means the repo itself is just configuration. But it also means there's nothing to validate that your priority map is consistent or that your cron jobs match your skill definitions.

Every file is littered with {{PLACEHOLDER}} tokens. The install docs list them, but there's no script to do the replacement — you're grepping and replacing by hand. The SETUP-GOG.md prerequisite assumes you already have a working Google Workspace CLI, which is its own adventure.

The business-development skill references a Google Sheet as the source of truth for outreach state, but the sheet schema isn't defined anywhere in the repo. You have to infer the expected columns from the skill's instructions.

There's also no versioning strategy. The repo ships "template v1" labels in each file, but there's no migration path if the structure changes.

Bottom line

Clawchief is for founders or operators who already use OpenClaw and want a structured operating model instead of ad-hoc prompts. The priority map and auto-resolver pattern is genuinely useful as an architecture reference, even if you never install the rest.