I’ve been aware of EOS (Entrepreneurial Operating System) for over a decade. A number of companies I’m on the board of use some element, or all of it. Several friends, including Bart Lorang, are EOS Implementers.
Last night, while watching Olympic highlights and the first few episodes of Steal, I created a v0.1 of CEOS — an open-source project that brings the core EOS toolkit to any Claude Code session. I went from an empty GitHub repo to a public-ready project in about 90 minutes. Please feel free to make fun of Amy and me about how we spend our Friday nights.
EOS has great tools — V/TO, Rocks, Scorecard, L10 Meetings, IDS. But most companies implement them in a patchwork of Google Docs and spreadsheets. Or Notion pages. Or maybe they use one of the EOS-related SaaS products. The data ends up scattered across platforms, locked in proprietary formats, and disconnected from the actual conversations where decisions happen.
Since I’m living inside Claude Code (and integrating more and more of my workflow to it), I thought I’d see if I could make a set of skills that implement EOS. I’m working on another project (private at this point, but maybe I’ll open source it) called CompanyOS, which, while focused on a very early-stage company (like the 5,000+ that have gone through Techstars), potentially could scale.
CEOS is built on three ideas:
1. Everything is a file. Every Rock, every Scorecard entry, and every L10 meeting is a Markdown file with YAML front matter. Human-readable on GitHub, parseable by any tool, and diffable in git. No database. No SaaS subscription. Git history is your audit trail.
2. Skills, not software. CEOS isn’t an application — it’s a set of Claude Code skills. Each skill teaches Claude how to facilitate a specific EOS workflow. You say “let’s set our quarterly rocks” and the ceos-rocks skill walks you through the process: reviewing the V/TO for alignment, collecting titles and owners, validating the 3-7 rule, generating the files. You say “run our L10” and ceos-l10 pulls your scorecard data, reviews your Rocks, checks last week’s actual to-dos, and facilitates IDS on your top 3 issues.
3. Fork and own it. The upstream repo (bradfeld/ceos) has skills, templates, and docs — no company data. You fork it, run ./setup.sh init, answer four questions (company name, quarter, team members, L10 day), and your EOS data lives in your fork’s data/ directory. Pull upstream for skill updates; your data stays untouched.
Here’s the timeline of the work I did with Claude Code. It implemented everything – I just provided the guidance. And yes, Claude came up with the timeline below. If you aren’t technical and don’t care, skip the next 10 paragraphs – they’ll be boring. But, if you are technical, it’s kind of fascinating what Claude decided, entirely on its own, to do.
9:38 PM — gh repo create bradfeld/ceos --public --add-readme --license mit --clone. One command created the GitHub repo, initialized it with LICENSE and README, and cloned it locally.
9:42 PM — Repo scaffolding. README with project overview and architecture diagram. CONTRIBUTING.md addressing two audiences (EOS practitioners and developers — deliberately different skill sets). .ceos marker file for skill repo-root detection. .gitignore that keeps data/ out of the upstream repo. Directory structure for skills, templates, and docs.
9:50 PM — Seven EOS template files. This was the first real design decision: which files get YAML frontmatter (structured data that skills parse programmatically) vs. which are pure markdown (reference documents humans read). The answer: frontmatter for objects with lifecycle state — Rocks have status: on_track, Issues have ids_stage: identified, L10 meetings have rating. Pure markdown for reference documents like the V/TO and Accountability Chart.
10:04 PM — The setup script. Pure bash, zero dependencies. Three modes: ./setup.sh (symlink skills), ./setup.sh init (guided setup), ./setup.sh --uninstall (clean removal). Two portability decisions that matter: using | as the sed delimiter instead of / so file paths in values don’t break substitution, and avoiding sed -i entirely (macOS and GNU Linux handle it differently) by using temp files instead.
10:23 PM — Five EOS skills. This was the meat of the project. Each skill is a SKILL.md file — essentially a prompt engineering document in structured form. The key tension in writing skills is comprehensiveness vs. followability. Too much detail and Claude skims; too little and it improvises. The pattern that worked: tables for quick-reference data (status enums, file paths, modes) and prose for workflow logic.
The five skills:
- ceos-vto — Review and update the Vision/Traction Organizer. Shows diffs before writing. Runs alignment checks between sections.
- ceos-rocks — Three modes: setting (with V/TO alignment checks, 3-7 validation, ID generation), tracking (milestone progress, status updates), and scoring (binary complete/dropped, quarter scorecard with 80% target).
- ceos-scorecard — Define metrics with goals and thresholds, log weekly values, 13-week trend analysis with automatic escalation to the Issues list.
- ceos-l10 — The full Level 10 Meeting. Seven sections with time boxes. Pulls real data from scorecard and rocks files. Reviews actual to-dos from last week’s meeting. Facilitates IDS on the top 3 issues. Captures meeting rating.
- ceos-ids — Structured issue resolution with 5 Whys for root cause identification, discussion capture, and to-do generation.
A critical design choice: skills reference each other but never auto-invoke. The L10 skill mentions that ceos-ids can create issue files, but lets you decide when to switch. Loose coupling through mentions, not tight coupling through auto-invocation.
10:39 PM — Five documentation files targeting different audiences. The EOS primer translates business concepts into developer vocabulary. The data format spec translates the same content into a parsing contract. The skill-authoring guide sits at the intersection—it’s prompt engineering documentation in disguise as a contributor guide. A skill reference provides users with a quick overview of all five skills, including trigger phrases and examples.
10:52 PM — GitHub configuration. CODEOWNERS, three issue templates (EOS Process Request, Bug Report, Skill Improvement), a PR template with before/after sections, and custom labels. The issue templates are deliberately different — one for EOS practitioners (“I think the Rock scoring process should work differently”), one for developers (“setup.sh fails on Ubuntu”), one for skill improvements (“ceos-l10 should handle recurring agenda items”).
11:08 PM — Final cleanup. Removed companyos-integration.md which contained internal details about how CEOS would integrate with our private CompanyOS system. Archived the content to a Linear comment before deleting — git history preserves it, but a Linear comment makes it findable without git archaeology.
During this, my Claude instance learned a few things that have been incorporated into our local learning (a dynamic file I keep and use to update skills during periodic sweeps).
Writing skills are prompt engineering in document form. The biggest trap is the description field. If you write “manages Rocks in three modes with binary scoring,” Claude will follow that summary and skip the detailed process sections. The description should say when to use it (“use when setting, tracking, or scoring quarterly Rocks”), not what it does. The body has the what.
Templates need lifecycle awareness. The distinction between frontmatter and pure markdown isn’t about complexity — it’s about whether the file has state that changes over time. A Rock moves from on_track to off_track to complete. A V/TO document is edited but doesn’t have lifecycle states. That distinction determines whether a skill can programmatically query and manage the data.
Documentation for AI skills packages needs three layers. User-facing (what can I do?), contributor-facing (how do I add?), and machine-facing (what’s the contract?). Most projects get the first two. The third — the data format spec that makes YAML frontmatter a real, portable, parseable contract — is what makes the ecosystem extensible.
The .ceos marker pattern is underrated. Borrowed from .git and .npmrc, a zero-byte marker file at the repo root gives every skill a reliable way to find the CEOS repository regardless of where the user’s working directory is. No environment variables, no configuration, no hardcoded paths. Just search upward for .ceos.
CEOS is live at github.com/bradfeld/ceos. MIT license. Do whatever you want with it. If you are into EOS, come play. I’ll pay attention to any PRs and issues. Following are the next few things I’m going to create.
- Process Documentation skill — The 6th EOS component. Document core processes as checklists with followability metrics.
- People Analyzer skill — Right people, right seats. The GWC (Get it, Want it, Capacity to do it) evaluation tool.
- Quarterly Conversation skill — The formal quarterly check-in between managers and direct reports.
- Annual Planning skill — Year-end V/TO refresh and next-year Rock setting.
And, while I was trying to come up with a name for this, with Claude, it told me I need to include the following footer.
CEOS is an independent open-source project. It is not affiliated with or endorsed by EOS Worldwide.