# clawchief: a starter kit for running an agent as a chief of staff > clawchief is a public OpenClaw starter kit that gives an agent a founder-style operating system, a priority map, a policy layer for automatic resolution, meeting-note ingestion, a canonical task file with a separate archive, and cron jobs to drive it. Its real contribution is the file layout, and the licence file is missing from the repository, which is the first thing to check before reusing it. **snarktank/clawchief** — Turn your OpenClaw into a Chief of Staff - Repository: https://github.com/snarktank/clawchief - Website: https://ryancarson.com - Stars: 1,112 · Forks: 118 - Language: Unknown - License: not declared - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/snarktank-clawchief ## An operating model, not a tool clawchief is described as a public OpenClaw starter kit for turning OpenClaw into a founder or chief-of-staff operating system. That framing is the key to reading the repository. It is not a program, a plugin or a service. It is a set of files, a set of skills and a set of cron templates, and what you get is a written-down way of working that an agent can execute. The README is explicit about the balance. It is opinionated about the architecture of the workflow, but meant to be customized for your own people, programs, calendars, inboxes, trackers, and recurring routines. The opinionated part is the shape of the workflow, and the customizable part is everything inside that shape. The origin is documented. The README points to the launch post, which is Ryan Carson's real-world rollout of the idea, hosted on X, and the homepage of the repository is ryancarson.com. It also credits Pedro Franceschi's OpenClaw setup, explained on the Core Memory podcast with Ashlee Vance, and names the three things that setup helped inspire: the priority map, the auto-resolver layer, and the ingestion pipeline mindset for turning passive context into active operational state. The audience is therefore quite specific. It is for someone who is already running OpenClaw as an assistant and has found that the agent does not hold a consistent operating model across sessions, and who wants that model to be a set of files it can read every morning. ## Seven files, and the separation is the point The design pattern section is the most valuable part of the README, and it is short enough to quote in full because the arrows are the argument. ```bash clawchief/priority-map.md clawchief/auto-resolver.md clawchief/meeting-notes.md clawchief/tasks.md clawchief/tasks-completed.md ``` The pattern is a separation of concerns across seven concerns, and the README says that separation is the main thing this repo is trying to teach. Prioritisation goes to priority-map.md. Resolution policy goes to auto-resolver.md. Meeting-note ingestion policy goes to meeting-notes.md. Live task state goes to tasks.md, and archive state goes to tasks-completed.md. Local environment details go to workspace/TOOLS.md, and recurring orchestration goes to workspace/HEARTBEAT.md plus the cron jobs. The point of splitting live state from archive state is that an agent which reads one file of tasks does not also have to wade through a year of finished work, and the file that describes what is happening now stays short enough to read every morning. The orchestrator heartbeat is the piece that makes the rest run. The workspace templates include workspace/HEARTBEAT.md, and the cron directory holds jobs.template.json, a template for the recurring jobs. The operating lessons at the end of the README make the same point from the other direction, with two entries that are really the same rule: keep one canonical live task file, and archive prior-day completions into a separate file, and update the real source of truth in the same turn when you act. An agent that edits a file it is about to forget about is an agent that will lose the change. ## Skills hold the workflow, cron prompts stay short The repository splits behaviour into two kinds of artefact, and the distinction is the second thing the README teaches. The skills directory holds skills/executive-assistant, skills/business-development, skills/daily-task-manager and skills/daily-task-prep. The cron templates carry short DRY prompts, and the operating lesson is to keep cron prompts short and let skills hold workflow logic. That is a sound split for an agent system. A cron job that carries the whole workflow in its prompt text is a workflow you have to edit in the scheduler, and it is a workflow that no longer has a single source of truth. A cron job that says go and do the thing, with the thing defined in a skill file, means the logic lives in a file that can be reviewed like code and versioned like code. The meeting-note policy is the same idea applied to context. The lesson is to treat meeting notes as a live signal source, not passive documents, and the workspace templates include workspace/memory/meeting-notes-state.json, which is where the state of that ingestion lives. The other lessons are about the boundaries of the agent's actions, and they are the sort of thing that only appears after some painful episode. Use Gmail message-level search, not thread-only search. Check all relevant calendars before booking. Use a policy layer for prioritisation and a separate policy layer for auto-resolution, so that a decision about what matters and a decision about what to do about it can be changed independently. ## The install order matters, and the docs are the product The installation is a sequence, and the README lays it out as a numbered list rather than a single command. First read INSTALL-WITH-OPENCLAW.md. Then complete SETUP-GOG.md, which is the Google account setup. Then copy the skills into ~/.openclaw/skills/ and copy the clawchief/ and workspace/ templates into ~/.openclaw/workspace/. Then replace placeholders and customise workspace/TOOLS.md. Then create cron jobs from cron/jobs.template.json. Finally run INSTALL-CHECKLIST.md. The order is not arbitrary, and the reason is visible in the layout. The Google setup comes before the cron jobs because the meeting-note and calendar behaviour depends on accounts that have to exist first, and the checklist comes last because it verifies the pieces that were only just created. The workspace/tasks/current.md file is even labelled a deprecated pointer for older installs, which is a small sign that this kit has been through at least one layout change and has kept the old path working. The README also names the files it expects you to edit first, and that list is the real documentation of what the kit assumes. Customise workspace/TOOLS.md, clawchief/priority-map.md, clawchief/tasks.md, skills/business-development/resources/partners.md and cron/jobs.template.json. The remaining setup files are CHANNELS.md, INSTALL-CHECKLIST.md, INSTALL-WITH-OPENCLAW.md, SETUP-GOG.md, and a REVIEW-NOTES.md at the root, and there is a separate cron/jobs.template.json for the recurring jobs. ## What is deliberately left out, and what is not licensed Two omissions in the README are worth reading carefully, because one of them is a design decision and the other is a gap. The first is deliberate. The README lists private local files you probably still want, including AGENTS.md, SOUL.md, USER.md, IDENTITY.md, MEMORY.md and a memory/ directory, and states that those are intentionally not part of this public repo. It makes sense. Those files describe a person and their working context, and a public starter kit has no business carrying them. The cost is that a new user has to create them, and the template gives no guidance on their content. The second omission is the licence. The repository listing at the top level contains no LICENSE file, and the repository's licence metadata is not classified, so there is no stated grant. For a kit that people are told to copy into their own ~/.openclaw directory, that is worth resolving before you redistribute the result, and the person to ask is the author. The README points at the launch post and the website rather than at a licence page. There is also a maintenance point. The release list is short, with v2 from 2026-04-04 and v3.0.0 from 2026-04-08, and the last push to the repository was on 2026-04-09. The releases came out within days of each other, which suggests a rename or a restructure rather than a steady series, and a kit whose file layout changed between v2 and v3 is a kit to copy carefully rather than to sync automatically. ## The alternative is a tracker you update yourself There is a real alternative to this approach, and the difference is about who drives the work. The alternative is the ordinary one. You keep your tasks in a tracker or a notes file, you review them yourself, and an assistant helps when you ask. The agent is a tool you use, and the state of what needs doing lives in your head and in the tracker. clawchief inverts that. The state lives in files the agent reads, the heartbeat drives the agent on a schedule, and the policy files decide what gets done and in what order without you being in the loop. The value of that inversion is availability, since the work continues when you are not looking at it. The cost is that you have given an agent write access to the definition of your priorities, and that the separation between the priority map and the resolution policy is only as good as the rules you wrote into them. The two approaches also fail differently. A tracker fails by being ignored, quietly, for weeks. An agent-driven system fails by acting on a rule you wrote three months ago and have forgotten, which is at least visible, because the action leaves a trace in a file. Which one is right depends on what you are optimising for. If the problem is that you never look at your own list, a system that works without you is the point. If the problem is that you do not trust a system to work without you, then a tracker and a well-written prompt is a better fit. ## Conclusion clawchief fits a founder or team lead who is running an OpenClaw agent as an assistant and wants the agent's operating model written down instead of improvised in each prompt. It does not fit a team that wants a general task manager, because the whole thing is a set of markdown policies and cron templates rather than a product with a UI. Before you install anything, check the licence situation, since no licence file is listed and the repository metadata is unclassified, and read INSTALL-WITH-OPENCLAW.md, because the install order matters and the last push to the repository was on 2026-04-09. ## FAQ ### What is clawchief and what does it give you? It is a public OpenClaw starter kit for turning OpenClaw into a founder or chief-of-staff operating system. You get a source-of-truth clawchief/ layer for priorities, task state, meeting-note policy and action policy, an orchestrator heartbeat, a canonical markdown task system with a separate completed-task archive, executive-assistant and business-development skills, cron templates with short prompts, and install docs and workspace templates. ### What is the install order for clawchief? Read INSTALL-WITH-OPENCLAW.md, complete SETUP-GOG.md, copy the skills into ~/.openclaw/skills/, copy the clawchief/ and workspace/ templates into ~/.openclaw/workspace/, replace placeholders and customise workspace/TOOLS.md, create cron jobs from cron/jobs.template.json, and finally run INSTALL-CHECKLIST.md. ### Which files should I customise first in clawchief? The README names five: workspace/TOOLS.md, clawchief/priority-map.md, clawchief/tasks.md, skills/business-development/resources/partners.md and cron/jobs.template.json. The skill files are also worth reading before you change anything, since the operating lessons say to keep cron prompts short and let skills hold the workflow logic. ### What licence does clawchief use? The repository does not list a LICENSE file among its top-level entries and the licence metadata is not classified, so there is no stated grant in the repository itself. If you plan to redistribute a customised copy, you should confirm the terms with the author before you rely on them. ### How does clawchief differ from keeping tasks in a tracker? A tracker depends on you to look at it, while clawchief puts the state in files the agent reads, drives the agent from a heartbeat and cron jobs, and separates the priority map from the auto-resolution policy so the two can be changed independently. ## Sources - [Issues](https://github.com/snarktank/clawchief/issues) - [Project website](https://ryancarson.com) - [README](https://github.com/snarktank/clawchief/blob/main/README.md) - [Releases](https://github.com/snarktank/clawchief/releases) - [snarktank/clawchief on GitHub](https://github.com/snarktank/clawchief) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/snarktank-clawchief