/ceos-process

name: ceos-process
description: Use when documenting core processes or reviewing process followability
file-access: [data/processes/, templates/process.md, data/vision.md, data/accountability.md]
tools-used: [Read, Write, Glob]

ceos-process

Document, simplify, and audit core company processes — the 6th EOS component. Every company has a handful of core processes that must be documented as checklists, simplified to their essential steps, and followed by all.

When to Use

• "Document our sales process" or "create a new process"
• "Show our processes" or "what processes do we have?"
• "Audit process FBA scores" or "how well are we following our processes?"
• "Simplify the hiring process" or "reduce this process to essentials"
• "Update the onboarding process" or "add a step to the deployment process"
• Any conversation about documenting how work gets done

Context

Finding the CEOS Repository

Search upward from the current directory for the `.ceos` marker file. This file marks the root of the CEOS repository.

If `.ceos` is not found, stop and tell the user: "Not in a CEOS repository. Clone your CEOS repo and run setup.sh first."

**Sync before use:** Once you find the CEOS root, run `git -C <ceos_root> pull --ff-only --quiet 2>/dev/null` to get the latest data from teammates. If it fails (conflict or offline), continue silently with local data.

Key Files

| File | Purpose | |------|---------| | `data/processes/` | Process documentation files | | `data/vision.md` | V/TO document (Core Focus and Proven Process for alignment) | | `templates/process.md` | Template for creating new process files | | `data/accountability.md` | Accountability Chart (seat owners for process-owner alignment) |

Process File Format

Each process is a markdown file with YAML frontmatter:

id: process-001
title: "Customer Onboarding"
owner: "brad"
fba_score: 85
last_audited: "2026-02-14"
status: active          # draft | active | deprecated
created: "2026-01-15"

**Status values:**

• `draft` — being documented, not yet in use
• `active` — documented and in use, subject to FBA audits
• `deprecated` — no longer followed (kept for historical reference)

**File naming:** `process-NNN-slug.md` where NNN is a zero-padded ID and slug is the title slugified (lowercase, hyphens, no special chars).

**FBA (Followed-By-All) score:** A percentage from 0-100 representing how consistently the team follows the documented process. Target: 80%+.

Process

Mode: Document

Use when creating a new process or updating an existing one.

Step 1: Determine New or Update

Check the user's request:

• If they name a specific existing process → load it for editing
• If they want a new process → continue with creation

For updates, read the existing process file, display the current content, and discuss what needs to change.

Step 2: Review Context

Before creating a new process, read and briefly reference:

• The **Core Focus** and **Proven Process** from `data/vision.md` — processes should align with how the company operates
• Any **existing processes** in `data/processes/` — avoid duplicates and ensure coverage

Display a quick summary: "You currently have N documented processes: [titles]."

Step 3: Collect Process Details

For a new process, collect:

1. **Title** — short, specific name (e.g., "Customer Onboarding", "Sales Process", "Deployment Pipeline") 2. **Owner** — one person who is accountable for this process (never shared) 3. **Purpose** — why does this process exist? What outcome does it ensure? 4. **Steps** — the numbered checklist of actions

For the steps, guide the user:

• Each step should start with an action verb ("Send", "Review", "Schedule", "Create")
• Aim for 5-20 steps. If more than 20, suggest the process might need to be split
• Steps should be specific enough that someone new could follow them
• Nested steps (1.1, 1.2) are allowed for complex steps, but maximum 2 levels deep

Step 4: Validate

• **3-7 core processes.** Count existing active processes. If adding this one would exceed 7, warn: "EOS recommends 3-7 core processes. You'll have N. Is this a core process or a supporting one?" Don't block — just flag.
• **One owner.** If the user tries to assign multiple owners, explain: "Each process has one owner — the person accountable for it being documented, simplified, and followed. Who should own this?"
• **Step count.** If more than 30 steps, warn: "This process has 30+ steps. Consider splitting into sub-processes or simplifying."
• **Duplicate check.** If a process with a similar title already exists, ask: "A process called '[title]' already exists. Update that one, or create a new one?"
• **Seat alignment.** Cross-reference the process owner against `data/accountability.md`. The owner should hold the seat whose responsibilities align with the process's domain. Flag mismatches: "This process falls under [Seat] responsibilities. Should [Seat Owner] own it?"

Step 5: Generate the ID

Read existing process files in `data/processes/`. Find the highest `process-NNN` ID and increment. If no files exist, start at `process-001`.

Step 6: Write the File

Use `templates/process.md` as the template. Substitute:

• Frontmatter fields (id, title, owner, fba_score=0, last_audited=today, status=draft, created=today)
• Body sections (purpose, steps, owner name)

Write to `data/processes/process-NNN-slug.md`.

Show the user the complete file before writing. Ask: "Create this process?"

Step 7: Repeat or Finish

Ask: "Create another process, or are we done for now?"

When finished, display a summary table of all documented processes:

| Process | Owner | Status | FBA | |---------|-------|--------|-----| | Customer Onboarding | brad | active | 85% | | Sales Process | daniel | draft | — |

---

Mode: Audit

Use for reviewing FBA scores across all documented processes.

Step 1: Read All Processes

Read all process files from `data/processes/`. Pa