Ceos Rocks

ceos-rocks

Manage quarterly Rocks — the 3-7 most important priorities for the next 90 days. Each Rock has one owner, a measurable outcome, and a due date at quarter end.

When to Use

• "Set rocks for this quarter" or "let's plan our quarterly priorities"
• "Rock status" or "how are our rocks tracking?"
• "Score rocks" or "end of quarter review"
• "Create a rock" or "add a new rock for [person]"
• "What rocks does [person] own?"
• Any quarterly planning or review conversation

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

Rock File Format

Each Rock is a markdown file with YAML frontmatter:

id: rock-001
title: "Launch Beta Program"
owner: "brad"
quarter: "2026-Q1"
status: on_track       # on_track | off_track | complete | dropped
created: "2026-01-02"
due: "2026-03-31"

Status values:

• on_track — progressing as expected
• off_track — behind or at risk
• complete — done (set during end-of-quarter scoring)
• dropped — no longer a priority (set during end-of-quarter scoring)

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

Milestones: Rocks support two milestone formats:

• Structured (frontmatter): Array of milestone objects with title, optional due date, and status (todo/in_progress/done). Enables date-based progress tracking and overdue detection.
• Markdown checklist (body): Traditional - [ ] / - [x] checklist items in the Milestones section. Simple and human-friendly.

Both are valid. Tracking mode prefers frontmatter milestones when present, falls back to markdown checklist parsing otherwise.

Attachments: Optional attachments array in frontmatter references supporting documents. Each attachment has a path (relative to CEOS root) and optional label. The skill displays references but does not manage files.

Quarter Format

Quarters follow YYYY-QN format: 2026-Q1, 2026-Q2, 2026-Q3, 2026-Q4.

To determine the current quarter from today's date:

• Jan-Mar = Q1, Apr-Jun = Q2, Jul-Sep = Q3, Oct-Dec = Q4

Process

Mode: Setting Rocks

Use when creating new Rocks at the start of a quarter.

Step 1: Determine the Quarter

Check if the user specified a quarter. If not, use the current quarter. If creating Rocks for a past quarter, warn: "That quarter has already started/ended. Continue anyway?"

Create the quarter directory if it doesn't exist: data/rocks/YYYY-QN/

Step 2: Review Context

Before creating Rocks, read and briefly summarize:

• The 1-Year Plan from data/vision.md (what are we trying to achieve this year?)
• Any existing Rocks for this quarter (avoid duplicates)

Step 3: Walk Through Each Rock

For each Rock, collect:

1. Title — short, specific description (e.g., "Launch Beta Program")
2. Owner — one person (Rocks are never shared)
3. Measurable outcome — what does "done" look like?
4. Milestones — 2-4 checkpoints toward completion
5. Structured milestones (optional) — Ask: "Add due dates to milestones?"
   • If yes, collect for each milestone: title, due date (YYYY-MM-DD), status (default: todo)
   • Store as milestones array in frontmatter
   • If no, use markdown checklist only (traditional format)
   • If more than 7 milestones, warn: "EOS recommends 3-5 milestones per Rock. Are all of these essential checkpoints?"
6. Attachments (optional) — Ask: "Any supporting documents to reference?"
   • If yes, collect: path (relative to CEOS root) and optional label for each
   • Store as attachments array in frontmatter

Step 4: Validate

• 3-7 Rocks per person. If someone has fewer than 3, ask if they should own more. If more than 7, flag: "Too many Rocks for [person]. EOS recommends 3-7. Which ones are the real priorities?"
• Alignment check. Does each Rock connect to a 1-Year Plan goal? Flag any that don't.
• Due date. Set to the last day of the quarter.
• Seat alignment. Cross-reference Rock owners against data/accountability.md. Flag mismatches if a Rock's subject area doesn't match the owner's seat responsibilities, for example: "This Rock falls under the [Seat] responsibilities. Should [Seat Owner] own it instead?"

Step 5: Generate the ID

Read existing Rock files across every quarter directory under data/rocks/. Find the highest rock-NNN ID and increment. If no Rock files exist anywhere, start at rock-001.

• Rock IDs are globally sequential across quarters. Numeric IDs run sequentially across the whole repository rather than resetting each quarter, so a new quarter continues from the highest existing ID. This avoids collisions and keeps a Rock reference stable no matter which quarter it came from.

  // Good
    # After Q1 has rock-001 through rock-007:
    data/rocks/2026-Q2/rock-008-launch-beta.md
    data/rocks/2026-Q2/rock-009-hire-vp-sales.md
  
  // Bad
    # Don't restart numbering each quarter:
    data/rocks/2026-Q2/rock-001-launch-beta.md
    data/rocks/2026-Q2/rock-002-hire-vp-sales.md
  

Step 6: Write the File

Use templates/rock.md as the template. Substitute:

• Frontmatter fields (id, title, owner, quarter, status=on_track, created=today, due=quarter-end)
• Body sections (measurable outcome, milestones)

Write to data/rocks/YYYY-QN/rock-NNN-slug.md.

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

Step 7: Repeat or Finish

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

When finished, display a summary table of all Rocks for the quarter:

Mode: Tracking Rocks

Use for weekly or ad-hoc status checks.

Step 1: Read All Rocks

Read all Rock files in data/rocks/[current-quarter]/. Parse the frontmatter for status.

Step 2: Display Status

Show a status table:

Milestone progress computation:

• If frontmatter has milestones array: Count entries with status: done vs total. Display: "N/M complete". If any milestone has due in the past and status is not done, append "(X overdue)".
• Else: Parse markdown checklist in body (count [x] vs total [ ] and [x]). Display: "N/M done".

Attachment display: If frontmatter has attachments array, show after the status table:

Attachments:
  • Beta spec (data/rocks/2026-Q1/rock-001-beta-spec.pdf)
  • Requirements doc (data/rocks/2026-Q1/requirements.pdf)

Step 3: Update Status

If a Rock's status needs to change:

1. Show the current status
2. Ask what the new status should be (on_track or off_track)
3. Show the diff in the frontmatter
4. Ask for approval before writing
5. Add a dated note to the Notes section

Mode: Scoring Rocks (End of Quarter)

Use at the end of a quarter for the completion review.

Step 1: Load All Rocks

Read all Rock files in data/rocks/[quarter]/.

Step 2: Score Each Rock

For each Rock, ask: "Complete or incomplete?"

• EOS scoring is binary. No partial credit. The measurable outcome was either achieved or it wasn't.

• Update status to complete or dropped (if the Rock was abandoned or deprioritized)

• A Rock that was worked on but not finished gets dropped — it can become a new Rock next quarter

• Append a timestamped entry to the Notes section. Whenever a rock file is created or updated, add a dated line to its Notes section, in the form - YYYY-MM-DD: [what happened]. At end-of-quarter scoring, append a scoring entry rather than only flipping the frontmatter status. The result is an audit trail inside each file, so the history of a Rock is readable without consulting git.

  // Good
    ## Notes
  
    *Track progress, blockers, and context here during the quarter.*
  
    - 2026-02-15: Rock created for 2026-Q1
    - 2026-04-03: Q1 scoring — dropped
  
  // Bad
    ## Notes
  
    *Track progress, blockers, and context here during the quarter.*
  
    - 2026-02-15: Rock created for 2026-Q1
    # (status changed to dropped, but no scoring entry was added)
  

• Use dropped, not not_done, for a Rock abandoned as no longer a priority. The two are not interchangeable. not_done means the Rock was pursued and missed; dropped means it stopped being relevant or was re-scoped away — a deliberate deprioritization. Scoring an abandoned Rock as not_done reads as a failure to deliver and loses the signal that the team chose to stop. Keep the quarterly planning doc's scorecard table using the same word as the rock file.

  // Good
    # Rock intentionally abandoned after re-scoping:
    status: dropped
    # In Notes:
    - 2026-04-03: Q1 scoring — dropped
  
  // Bad
    # Same Rock, recorded as merely incomplete:
    status: not_done
  

Step 3: Show the diff for each status change, ask for approval.

Step 4: Summary

Display the quarter scorecard:

Q1 2026 Rock Scorecard
━━━━━━━━━━━━━━━━━━━━━━
Complete: 4/6 (67%)
Target: 80%+

✓ Launch Beta Program (brad)
✓ Hire VP Sales (daniel)
✓ Implement CRM (daniel)
✗ Redesign Onboarding (brad) — dropped
✓ ISO Certification (sarah)
✗ Partner Program (brad) — dropped

If completion rate is below 80%, flag it: "Below the 80% target. Consider: Were Rocks too ambitious, or were there execution issues? This is a good topic for the next L10."

Output Format

Setting: Show each Rock file before writing. End with a summary table. Tracking: Status table with milestone progress (from frontmatter milestones if present, else markdown checklist). Overdue milestones flagged. Attachments listed if present. Scoring: Quarter scorecard with completion rate.

Guardrails

• Always show diff before writing. Never modify a Rock file without showing the change and getting approval.
• One owner per Rock. If the user tries to assign a Rock to multiple people, explain that EOS Rocks have one owner. Suggest splitting into separate Rocks.
• 3-7 per person. Warn (don't block) if someone is outside this range.
• Binary scoring only. Don't allow "partial" or percentage-based scoring. Complete or dropped.
• Milestone status values. Only accept todo, in_progress, done for structured milestones. If the user provides another value during creation, show the allowed values.
• Respect quarter boundaries. Rocks in data/rocks/2026-Q1/ belong to Q1. Don't move them between quarters — create new Rocks in the next quarter instead.
• Cross-reference V/TO. When setting Rocks, check alignment with the 1-Year Plan from data/vision.md. Use ceos-vto if deeper vision review is needed.
• ID uniqueness. Always check existing files before assigning an ID to avoid collisions.
• Don't auto-invoke other skills. Mention ceos-vto, ceos-l10, and ceos-annual when relevant, but let the user decide when to switch workflows.
• Sensitive data warning. On first use, remind the user: "Rocks may contain sensitive business priorities. Use a private repo."

Integration Notes

V/TO (ceos-vto)

• Read: ceos-rocks reads data/vision.md to check the 1-Year Plan when setting Rocks. Each Rock should connect to a 1-Year Plan goal.
• Suggested flow: If Rocks don't align with the 1-Year Plan, suggest: "Review the V/TO with ceos-vto to ensure strategic alignment."

L10 Meetings (ceos-l10)

• Read: ceos-l10 reads Rock files during Section 4 (Rock Review) of the L10 meeting. Each Rock owner reports on_track or off_track status.
• Suggested flow: Off-track Rocks should be discussed further in the IDS section of the L10.

Quarterly Conversations (ceos-quarterly)

• Read: ceos-quarterly references Rock progress during quarterly conversations. Rock ownership and status provide context for individual performance discussions.

Annual Planning (ceos-annual)

• Read/Write: During annual planning, the team scores the outgoing quarter's Rocks and sets Q1 Rocks for the new year. ceos-annual orchestrates this; ceos-rocks handles the actual Rock creation and scoring.

To-Dos (ceos-todos)

• Related: Rock milestones may generate To-Dos during L10 meetings. These To-Dos are tracked in data/todos/ via ceos-todos with source: l10.

Accountability Chart (ceos-accountability)

• Read: ceos-rocks reads data/accountability.md when setting Rocks to validate that Rock owners match seat responsibilities. A Rock about sales pipeline should belong to whoever owns the Sales & Marketing seat.
• Suggested flow: If a Rock doesn't align with the owner's seat, suggest: "This Rock falls under the [Seat] responsibilities. Should [Seat Owner] own it instead?"

Read-Only Principle

Other skills read data/rocks/ for reference. Only ceos-rocks writes to Rock files. This preserves a single source of truth for quarterly priorities.