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:
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.
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.
My long time friend Alan Shimel has been blogging up a storm on Network World (if you want to hear any amusing story, ask him about the first time he met me.) When Alan started writing his column for Network World he asked me for introductions to a bunch of our portfolio companies that were using open source. Alan is a tough critic and calls it like he sees it so while I knew there was no guarantee that he’d go easy on the companies, I knew that Alan would do an even handed job of highlighting their strengths and weaknesses. I also know that everyone I invest in values any kind of feedback – both good and bad – and they work especially hard to delight their customers so any kind of feedback will make them better.
Earlier today, Alan wrote an article on Standing Cloud titled Seeding the Cloud with Open Source, Standing Cloud Makes It Easy. On Monday, Standing Cloud released their first version of their product (called the Trial Edition) which is a free version that lets you install and work with around 30 open source products on five different cloud service providers. It’s the first step in a series of releases over the next two quarters that Standing Cloud has planned as they work create an environment where it is trivial to deploy and manage open source applications in the cloud. Alan played around with Standing Cloud’s Trial Edition, totally understood what they are doing, and explained why the Trial Edition is interesting and where Standing Cloud is heading when they release their Community Edition at the end of April.
Alan’s also written several other articles about companies in our portfolio recently, including the open source work Gist has been doing with Twitter and a great review of the Pogoplug and how it uses open source.
I believe I’m one of the people that inspired Alan to start blogging a number of years ago. Through his personal blog Ashimmy, the blog he writes for Network World titled Open Source Face and Fiction, and the blogging he does on security.exe (his company CISO Group’s blog), Alan is one of my must read technology bloggers. And he’s often funny as hell, especially when he gets riled up. Keep it up Alan!
I’m an investor in Bug Labs (personally, not through our funds). When I first met with Peter Semmelhack, the CEO, on an introduction from Fred Wilson (the lead investor) I immediately got it. After about 15 minutes, I said to Peter something to the effect of “ah – today’s version of the Healthkit.”
Peter’s vision was that in addition to being a completely open source hardware product that allows you to prototype any consumer electronics device (or – more simply – any “electronic gadget”), all the software and design would be “open.”
Bug has just announced that they will be working with IDEO to redesign the user interaction of the product out in the open. This is more than an open source software project – it’s actually a public hardware UI redesign that involves anyone in the Bug community.
I love the notion of the open source hardware movement as it is completely in line with the Ph.D. research I did at MIT under Eric von Hippel. Bug Labs agrees and actually created the BUGvonHippel module to honor Eric!
If you want to participate (or just play along at home) hop on the Bug Blog, Bug Community, and the IDEO blog.
Kevin Kelleher’s article on GigaOm this morning titled 2009: Year of the Hacker made me think back to the rise of open source after the Internet crash of 2001. In the aftermath of the crash, many experienced software developers were out of work for a period of time ranging from weeks to years. Some of them threw themselves into open source projects and, in some cases, created their next job with the expertise they developed around a particular open source project.
We are still in a tense and ambiguous part of the current downturn where, while many developers are getting laid off, some of them are immediately being picked back up by other companies that are in desperate need for them. However, many other developers are not immediately finding work. If the downturn gets worse, the number of out of work developers increases.
If they take a lesson from the 2001 – 2003 time frame, some subset of them will choose to get deeply in an open source related project. Given the range of established open source projects, the opportunity to do this today is much more extensive than it was seven years ago. In addition, most software companies – especially Internet-related ones – now have robust API’s and/or open source libraries that they actively encourage third parties to work with for free. The SaaS-based infrastructure that exists along with maturing source code repositories add to the fun. The ability to hack something interesting together based on an established company’s infrastructure is omnipresent and is one of the best ways to “apply for a job” at an interesting company.
We are thinking hard about how to do this correctly at a number of our new investments, including companies like Oblong, Gnip, and a new cloud-computing related startup we are funding in January. Of course, many of our older investments such as NewsGator and Rally Software already have extensive API libraries and actively encourage developers to work with them. And of course, there are gold standards of open source projects like my friends at WordPress and masters of the API like Twitter.
If you are a developer and want help engaging with any of these folks, or have ideas about how this could work better, feel free to drop me an email.