Streamline Workflow with CEOS: Claude Meets EOS

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, […]
The post Streamline Workflow with CEOS: Claude Meets EOS appeared first on Feld Thoughts.

** Back to Blog

Streamline Workflow with CEOS: Claude Meets EOS

Feb 14, 2026

Category Code

• #EOS
• #Claude Code
• #CEOS
• #Open Source
• #ai

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).

[...]

Original source