Ray-Starter-Kit — Repo Skeleton Scope (v1)

Scoping doc for the parting-gift kit Ben hands off at the Mammoth Growth AI Demo Day on Wed 2026-05-13. Build is Mon-Tue. This doc names what ships, where each piece comes from, what has to be sanitized, and what gets cut if time runs short.

Recommended repo name + URL

Three candidates considered:

Pick: coo-in-a-box with ray-starter-kit as a redirect.

Rationale: the parting-gift framing is "here's the recipe so you can build YOUR version." Ray is one instantiation. Naming the kit after Ray confuses the gift (do they get Ray, or do they get to build their own?). coo-in-a-box makes the gift legible without prior context. The README leans on the harness-engineering vocabulary for depth. ray-starter-kit stays as a memorable-to-Ben handle and a redirect for any URL that gets shared from his slides.

Org placement: github.com/RayDataCo/coo-in-a-box. Public. Personal repo (github.com/benwilson/...) reads as a side-project; org placement signals this is a repeated investment for RDCO and gives a clean home if Ray-as-a-Service becomes a real bet.

Top-level repo structure

coo-in-a-box/
├── README.md                      # The "what is this and why" — distilled from the two concept docs
├── LICENSE                        # MIT (permissive — gift, not a moat)
├── .gitignore                     # Standard (state files, secrets, .env, .DS_Store)
├── INSTALL.md                     # 30-min Day-1 installer walkthrough
├── ONBOARDING.md                  # The 6-week ratchet doc
├── docs/
│   ├── architecture.md            # The 8-layer map (distilled from ray-architecture-introspection)
│   ├── harness-vs-personal-fit.md # The two-layer moat thesis (distilled from harness-moat doc)
│   ├── unhobbling-moments.md      # The 13 inflection points + why each matters
│   └── composability-chains.md    # The 5 worked-example chains
├── identity/
│   ├── SOUL.template.md           # Sanitized SOUL with [[ROLE]] [[VOICE]] [[CHANNELS]] placeholders
│   ├── CLAUDE.template.md         # The 4 universal hard rules + commentary
│   └── memory/
│       ├── MEMORY.md              # Empty index (the index pattern, no entries)
│       └── README.md              # How memory files work + when to write one
├── vault/                         # Folder scaffold the operator clones to ~/their-vault/
│   ├── 00-inbox/.gitkeep
│   ├── 01-projects/.gitkeep
│   ├── 02-sops/.gitkeep
│   ├── 03-contacts/README.md
│   ├── 04-finance/README.md
│   ├── 08-tooling/README.md
│   ├── 05-meetings/.gitkeep
│   ├── 06-reference/
│   │   ├── README.md
│   │   ├── concepts/.gitkeep
│   │   └── research/.gitkeep
│   ├── 07-archive/.gitkeep
│   ├── 09-bet-stacks/README.md
│   ├── 10-source-material/.gitkeep
│   ├── decisions.md               # Empty append-only template
│   ├── log.md                     # Empty append-only template
│   └── README.md                  # Vault discipline + folder semantics
├── skills/                        # 12 sanitized skills (the unhobbling set)
│   ├── README.md                  # How skills work + install instructions
│   ├── check-board/SKILL.md
│   ├── process-inbox/SKILL.md
│   ├── process-newsletter/SKILL.md
│   ├── morning-prep/SKILL.md
│   ├── improve/SKILL.md
│   ├── skillify/SKILL.md
│   ├── self-review/SKILL.md
│   ├── curiosity/SKILL.md
│   ├── deep-research/SKILL.md
│   ├── log-bet-decision/SKILL.md
│   ├── vault-health/SKILL.md
│   └── sync-contacts/SKILL.md
├── scripts/
│   ├── audit-vault-outputs.py     # Renamed/generalized from audit-newsletter-outputs.py
│   ├── scheduled-jobs.template.txt # Cron schedule with personal cadences swapped for placeholders
│   └── README.md                  # When to use deterministic scripts vs LLM skills
├── channels/
│   ├── README.md                  # Bring-your-own-channel intro
│   ├── imessage-setup.md          # Install + LaunchAgent + tmux, sourced from project_channels_agent_setup
│   └── discord-setup.md           # Same pattern, Discord variant
└── handout.pdf                    # Optional 1-page printable for the demo room (cut candidate)

Per-file source map

Aggregate: ~14 hours pre-cut. With the v2-deferred items removed (see "Recommended cuts" below), v1 lands at ~10.5 hours. Fits the 8-12 hour budget.

Sanitization risk inventory

Per file, what personal data lives in the source that MUST be stripped before public push:

Sanity-check pass before publish: run grep -rE "(rdco-vault\|raydata\.co\|mammothgrowth\|ben@\|/Users/ray/\|hq\.raydata\|stratechery\|squarely\|Sophia\|wife\|Mammoth)" coo-in-a-box/ on the staged repo. Should return zero hits. Add this to INSTALL.md as a final pre-publish gate so future updates don't drift.

6-week onboarding ratchet — proposed outline

This is ONBOARDING.md. NEW content. The pitch in the harness-moat doc says: "Compress the calibration period from 6 months to 6 weeks via guided onboarding." This file is the guide.

Day 1 — Minimum-viable Ray (target: 60 min)

• Install Claude Code (link to docs)
• Install one channel MCP (iMessage if Apple-stack, Discord if not). Reference channels/
• Copy identity/SOUL.template.md to ~/SOUL.md. Fill [[ROLE]] (e.g. "COO", "Chief of Staff", "Strategic Partner"), [[VOICE]] (3-5 sentences in your voice), [[OPERATOR]] (your name + 1-line context). Don't perfect; ship version 1.
• Copy identity/CLAUDE.template.md to ~/CLAUDE.md. Keep the 4 hard rules verbatim. Add zero personal rules today.
• Send your first message via the channel. Confirm it routes back through the reply tool.
• DONE. You have minimum-viable Ray.

Day 2-7 — First crons + first vault entries (target: 30 min/day)

• Day 2: Clone vault/ to ~/your-vault/. Add a single decision to decisions.md. Open one project under 01-projects/.
• Day 3: Install your first cron loop. /check-board is the safest first cron — daily Notion sync. Confirms the loop architecture works.
• Day 4: Install your second cron — /morning-prep at 6:30am (or your wake time). This is the first thing that PINGS you without being asked. Recipe-changing moment.
• Day 5: First feedback_*.md memory file. Pick something you corrected today and write it as a 5-line file in ~/.claude/projects/<x>/memory/. Update MEMORY.md index.
• Day 6: Install /process-inbox cron (30min cadence). Drop one document in ~/your-vault/00-inbox/. Watch it get filed.
• Day 7: Recap. Look at your decisions.md + memory index + first 3-4 vault entries. The compounding has started.

Week 2 — First /improve cycle (target: 1-2 hr total over the week)

• Install /self-review (Sun 7am) and /improve autonomous (Mon 7am). The ratchet is now live.
• Run /self-review manually once mid-week to feel what it does.
• After Mon 7am, read ~/your-vault/01-projects/self-review/review-log.md. See what /improve patched.
• Write your first 3 deliberate memory files: pick three things from your week's session output that you'd want Ray to do differently. File each. Update the index.
• Add your FIRST personal hard rule to CLAUDE.md. Earned, not generic.

Week 3-4 — Composability emerges (target: ratchet runs itself)

• Install /curiosity (Tue+Sat 10pm) + /deep-research (1am nightly). The autonomous research engine now runs.
• Install /process-newsletter watch. Add 2-3 senders to whitelist.yml. Watch briefs land in vault overnight.
• The chains start firing without you noticing. By end of week 4 you should have: ~5 morning briefs read, ~5 research briefs in 06-reference/research/, ~10 memory files, ~3-4 personal hard rules in CLAUDE.md.
• Drop a screenshot of your MEMORY.md index in your team chat. People will ask what it is.

Week 5-6 — Personal-fit thickens (target: it feels like YOUR Ray)

• Install /log-bet-decision and start logging strategic choices to 09-bet-stacks/.
• Install /sync-contacts if you want autonomous contact triage (requires Gmail + Calendar MCPs).
• Start writing your own skills. /skillify is the meta-skill: tell it what failure pattern you saw, it scaffolds the skill. First custom skill is the "I built this" moment.
• Run /vault-health once. Read what it tells you. The vault is no longer empty.
• By week 6, the difference between "Claude Code I happen to have configured" and "my COO" is undeniable. The personal-fit layer has thickened. The ratchet is yours.

What to expect after week 6

• The kit gave you the universal harness. The next 6 months of operating give you the personal-fit layer that no one else has. That's the moat-at-depth.
• Update upstream: if a kit update lands (git pull), your CLAUDE.md + memory + vault DON'T get clobbered. Only the templates, skills, and scripts update.
• If you want to give RDCO feedback on what the next kit version should include, open an issue. The kit ratchets too.

Estimated total build time

That's over budget. Cuts below bring it to ~10-11h.

Recommended cuts if time runs short

Order of cut, easiest to hardest:

1. handout.pdf — defer to v2. The slide deck has the URL; a paper handout is duplicative for a 10-min demo. Saves 1h.
2. docs/unhobbling-moments.md + docs/composability-chains.md as separate files — collapse into docs/architecture.md as sub-sections. Saves 0.5h.
3. sync-contacts skill — 1h sanitization for the longest skill. It also requires Gmail + Calendar MCPs. Defer to v2. Saves 1h. (Update: keep it. It's the strongest "this is what autonomous looks like" demo. Cut something else.)
4. process-newsletter skill — 45min sanitization + depends on a whitelist file the kit doesn't fully ship. Defer to v2 with a note "shipping in v0.2 — needs whitelist tooling". Saves 1.25h including the whitelist file. (Recommend cutting this instead of sync-contacts — process-newsletter has more dependencies.)
5. audit-vault-outputs.py generalization — ship as-is with a "rename + edit invariants for your org" header. The 13-invariant PATTERN is the gift; the implementation can stay opinionated. Saves 0.75h.
6. Per-folder vault READMEs — ship 03-contacts, 04-finance, 06-reference, 09-bet-stacks only (the 4 with structural conventions). Others get .gitkeep. Saves 0.5h.
7. Channel install detail — link to MCP server READMEs upstream rather than re-document install steps. Keep the LaunchAgent + tmux pattern doc. Saves 0.75h.

Applying cuts 1, 2, 4, 5, 6, 7: ~5h saved. v1 lands at ~13h. With cut 3 (sync-contacts deferred): 14h-1h = 12h. Inside budget.

Recommended v1 cut set: 1, 2, 4, 5, 6, 7 (keep sync-contacts; it's a strong demo). Lands at ~13h, slightly over budget but achievable across two days.

Aggressive v1 cut set: 1, 2, 4, 5, 6, 7, plus collapse INSTALL.md into README.md and ship audit script verbatim with rename only. Lands at ~10h.

Open questions for founder review

1. Repo name — coo-in-a-box (recommended), ray-starter-kit, harness-starter, or something else?
2. Visibility — Public GitHub repo (recommended for shareability + SEO + future Ray-as-a-Service signal) or unlisted gist (simpler, no public-facing accountability if v1 is rough)?
3. Landing page — Should raydata.co/coo-in-a-box (or /starter) point at this with a hosted README + GitHub link? Recommended yes for v2; v1 can stay GitHub-only since the demo audience can scan a QR code to the repo directly.
4. process-newsletter in v1 or v2? — Recommend v2. Heavy sanitization, depends on whitelist tooling that's unscoped. The 11 other skills cover the demo arc.
5. Audit script — generalize or ship-as-is with rename? — Recommend ship-as-is with rename + a short "fork and customize the invariants" header. The pattern is the gift. Generalizing it to the point of being framework-agnostic loses the "concrete worked example" value.
6. Deterministic-script ecosystem — Recommend ship ONLY audit-vault-outputs.py + scheduled-jobs.template.txt in v1. The other 30 scripts (extract-key-frames, vtt-to-text, finance-venv, etc.) are bet-specific. Document them as "RDCO ships these in our setup; here's the pattern, you'll write your own as needs emerge." Saves significant scope.
7. MEMORY.md template — Ship the index format only (no actual feedback files), or ship 2-3 sample feedback files showing the shape ("feedback_example_voice.md", "feedback_example_decision_pattern.md")? Recommend 2-3 anonymized examples. Pure-empty index is hard to learn from.
8. License — MIT recommended (permissive gift). Anything else worth considering? Apache-2.0 if patent concerns; GPL if RDCO wants any modifications to come back upstream (probably not the gift vibe).

Status

• 2026-05-10 09:56 ET: Scope filed (this doc).
• Next: founder review (target: today). Open questions 1-3 are blocking; 4-8 are tunable mid-build.
• Then: Mon AM build kickoff per cut decisions.