$7,140 for Brisket: A Day Inside Builder OS

What Builder OS is

Builder OS is a folder of markdown files you open in Claude Code. It holds what you own, who you work with, what you decided and why, and what happened this week. On top of that sits a set of slash commands that read those files and write back to them.

The commands themselves are short because the folder does the heavy lifting. When you ask for a meeting prep, Claude already knows that this person wants the bottom line first, what you promised them last week, and which decision they haven't heard about yet.

I built it for builders, meaning anyone who ships things with other people. The example follows a product manager because PMs juggle the most moving parts, but the blank version starts by interviewing you about your actual job, so it works for engineers, designers, founders, marketers, ops, sales, support, and data people too.

There are two downloads:

• The example: Jules Adeyemi's full OS, frozen at 8:30am on the Thursday after the Nashville tab. Open it and replay her day yourself.
• The blank OS: same structure, empty. Type /onboard and it interviews you to fill itself in.

The folder in sixty seconds

builder-os/
├── CLAUDE.md          ← who you are + map of the folder. Claude reads it first.
├── MISSION.md         ← what you own, this quarter's projects, your team at a glance
├── SPRINT.md          ← this week: commitments, waiting-on, parked
├── BACKLOG.md         ← everything else
│
├── projects/          ← one folder per project
│   └── halvsies-host/
│       ├── README.md      ← the problem, what done looks like, assumptions to test
│       ├── decisions.md   ← every call we've made, newest first
│       ├── research/      ← interviews, data, field notes
│       └── artifacts/     ← scope docs, drafts, decks
│
├── team/              ← one file per person: how they like information, what they care about
├── memory/            ← daily/, meetings/, 1on1s/, done/
├── runbooks/          ← repeat work with its own rules (weekly update, incidents)
├── context/           ← company, product, customers, glossary, metrics, voice
├── templates/         ← starting points for new files
├── inbox/             ← dump anything, sort later
├── CONFIG.md          ← what's connected
├── CHANGELOG.md       ← how your OS has changed over time
└── .claude/
    ├── settings.json  ← loads SPRINT.md into every new session
    └── skills/        ← the slash commands

If you've worked on a software team, most of these words already mean something to you, and that's on purpose. A few ideas hold it together.

Context and memory are separate. context/ is the stuff that rarely changes: your company, your product, your metrics, how you write. memory/ is what happened: every day, every meeting, every 1:1. Claude reads both, but only memory/ grows every day.

Decisions are files. Every project has a decisions.md. Three weeks from now, when someone asks why you launched with a confirm step instead of waiting, the answer is a dated entry with the options you rejected and what would have changed your mind.

Your team is context. The team/ folder holds a file for every person you work with, customers included. Each one says how that person likes to get information and what they care about. This is the folder that turns a generic meeting prep into one that sounds like you've known them for a year.

Everything writes back. Every command saves what it produces to a file, so the next command can build on it. The brief lands in today's daily note, the prep lands in the meeting file, and the debrief adds notes under the prep in that same file.

Jules's Thursday

Jules is Lead PM at Halvsies, a 41-person startup in Brooklyn. Halvsies is a bill-splitting app with 2.3 million monthly users. You snap a receipt, an AI model reads it, and everyone gets a payment request. Jules owns two things: Halvsies Host, a new paid product for people who plan group trips for a living, and Auto-Split v2, the one-tap feature that read the Nashville tab.

It's twelve days after the brisket. Last Call Co.'s pilot renewal is due October 30. Her manager wants a launch decision on Auto-Split by Friday. The CEO wants to know if she should call the owner herself.

I ran these commands against the example folder. Every terminal output below is real, trimmed for length.

Claude already knows the week

Jules opens Claude Code in her Builder OS folder. Before she types anything, a small hook in .claude/settings.json has already loaded SPRINT.md into the session: her commitments, who she's waiting on, and the week's focus line.

It's a one-line SessionStart hook, and it means Claude never starts cold. It's the cheapest upgrade in the whole system.

/brief

/brief

# Brief · Thursday, Oct 22

The one thing: Call Gus at 11:00, then send him the timeline and
make-good in writing before you leave. You promised it for today.

## Calendar
- 9:30 · Product sync · Hana owes the pay-by-link estimate.
- 10:15 · 1:1 Coco · Bring a launch recommendation, not a menu. Tell
  her about Gus before Bea does, since Bea Slacked at 7:12am asking
  if she should call him. Ask about Imani's 2-months-free.
- 11:00 · Gus · Straight talk, with dollars rather than percentages.
  The timeline and make-good are drafted.
- 13:30 · Rafa data review · His export is overdue. Leave with a date.
- 16:30 · Bea sync · Answer her Gus question after the 11:00 call.

## Stuck
- 🧊 Dev's error analysis · 6 days · blocked on Rafa's export.
  Unstick it at 1:30.

## Projects at risk
- Auto-Split v2 🔴 · Dev can't pick the confidence cutoff without
  the export.

What just happened. The brief read SPRINT.md, the projects in MISSION.md, yesterday's end-of-day notes, the team file for everyone on the calendar, and a Slack message sitting in inbox/. It noticed that Dev is stuck because Rafa is stuck, and that Rafa is on the calendar at 1:30. "Bring a launch recommendation, not a menu" comes from Coco's team file, where Jules wrote down what Coco said two days ago. "Dollars rather than percentages" comes from Gus's.

No calendar connection was needed for this. The example has today's schedule written into the daily note, and every command falls back to files when a connection isn't there. With Google Calendar connected, it pulls the real schedule.

/prep gus-ferreira

Ten minutes before the call that decides whether her biggest pilot renews.

/prep gus-ferreira

# Prep · Gus Ferreira · 2026-10-22, 11:00

Goal: He hears straight what happened and what we're doing. He leaves
ready to read the written follow-up and decide on Oct 30.

Open with: "Gus, here's what happened. Luis's handwritten $1,140 tab
read as $7,140. A '1' with a serif looked like a '7', and the app
called the receipt printed. That's why $612 requests went out instead
of $97.71. Both refunds ($1,224) are done. I'm sending you the full
timeline today."

He'll probably ask
- Handwriting thing or app-is-broken thing? Handwriting is the
  trigger, and the model has seen very few handwritten tabs (~1% of
  training). The honest part is that it misread the total,
  misclassified the receipt, and one-tap sent it anyway.
- What's changing? For the model fix, I have {number: check Dev's
  error analysis}. It's blocked on Rafa's export, so don't promise
  a date.

Careful
- Coco hasn't OK'd the make-good. Settle that at the 10:15 1:1
  before you offer it.
- Use dollars, not percentages. No spin and no long emails.
- The groom's mom called him, not you.

What just happened. Gus's team file says "straight talk" and "hates percentages without dollars attached," so the prep opens with a plain account in dollars. The serif detail and the $97.71 came from the engineer's read log in the project's research/ folder. Look at {number: check Dev's error analysis}: the file didn't have that number, so instead of guessing, the prep left a hole and told Jules where to fill it. The warning about the make-good came from a rule in the incident runbook that says anything public needs her manager's sign-off.

/debrief

The call went better than expected. Jules pastes her notes exactly as she typed them, typos and all:

/debrief gus call

gus call 11am. way calmer than last wk. read the timeline, said "ok so
its a handwriting thing not a your app is broken thing" lol
- he wants: the receipt photo with the number circled before anything
  sends. "dont tell me $612 show me the receipt"
- his trip hosts (luis etc) do all the snapping. half the guests never
  open the app, they just want a link to pay. !!! guests-wont-download
  thing again
- renewal: "if the handwriting thing is fixed before my new years trips
  im in." first NYE trip leaves dec 29
- asked if he can talk to dev directly about the model
- me: send him the fix plan in writing by tues oct 27
- he'll send me photos of ~40 handwritten tabs from past trips

Filed
- memory/meetings/2026-10-22-gus-ferreira.md: added Notes, Decisions
  and Commitments under your existing prep.
- SPRINT.md: added a commitment to send Gus the fix plan by Tue 10-27.
  Under Waiting on, added Gus's photos of about 40 handwritten tabs.
- team/gus-ferreira.md: added 6 dated notes. Open loops updated.
- projects/halvsies-host/research/field-notes.md: added 4 Gus quotes
  and the guests-won't-download point, which bears on assumption 4.

Needs a call
- Gus talking to Dev: I didn't promise anything. Check with Dev first.
- Oct 30 renewal vs. Dec 29: his yes depends on the fix, but the
  renewal decision is Oct 30. Decide how you frame this in the written
  plan, and don't promise a date.

Team files
- Luis (his trip host, 200+ weekends) has no team file. Should I
  create one? He seems to matter, since he does the snapping.

What just happened. Messy notes turned into four filed updates and a receipt Jules can check in ten seconds. Gus's quotes went into the project's research folder, where this afternoon's synthesis will find them. The debrief also caught something Jules hadn't noticed: Gus just moved the real deadline from October 30 to December 29. It flagged the conflict instead of quietly rewriting her goals. And it noticed that Luis, the person actually holding the phone, doesn't have a team file.

/decide

Coco said "bring me a call, not a menu." Jules has made her call. Now it needs to exist somewhere other than her head.

/decide should Auto-Split v2 launch on Nov 5? My call: ship Nov 5 with
Dev's confirm-before-send guardrail; pilots get it Oct 28; retrain on
handwritten tabs for January.

It writes this to projects/auto-split-v2/decisions.md (trimmed):

## 2026-10-22 · Launch Auto-Split v2 on Nov 5?
Call: Ship Nov 5 with Dev's confirm-before-send guardrail; Host pilots
get it Oct 28; retrain on handwritten tabs for January
Made by: Jules  Status: decided

Options considered:
- A. Ship Nov 5 as planned, one-tap everywhere (a second overcharged
  group is a kill criterion, and 22% of pilot reads are hard receipts)
- B. Delay until the retrain lands (needs ~5,000 labeled handwritten
  tabs and 3 to 4 weeks; misses Nov 5 and Friendsgiving)
- C. Guardrail, then retrain: on handwritten, faded or dark receipts,
  low confidence, or a share 3x the group's usual, don't send. Show
  the photo with the total circled and make the payer confirm.
- D. Show the top two readings (people pick fast at 1am)

Be honest about: the guardrail doesn't raise the exact-total rate. The
98% target in the README is not met on Nov 5; it routes hard receipts
to confirmation instead of fixing them. The retrain is what closes
that gap.

Revisit: 2026-10-28 (pilot rollout); go/no-go for Nov 5 on 2026-11-03
Who needs to know: Coco, Dev, Hana, Tamsin, Bea → [ ] told

What just happened. Every number in that record came from a file: the 22% from the data analyst's read-quality report, the 5,000 tabs from the engineer's model notes, and the 3x rule from his guardrail proposal. Option A, doing nothing, is on the list on purpose, because seeing the cost of inaction written down makes the other options easier to judge. Then there's the "Be honest about" line, which Jules didn't ask for. Her own project README says the target is 98% on every receipt type, and the record points out that her decision doesn't hit it. Better that Coco hears it from Jules than finds it later. The "Who needs to know" line also became tell-them commitments in SPRINT.md, each due when that person needs it.

/research

Jules has a two-hour focus block and a design review tomorrow. On Monday her designer, Ollie, asked her a question she couldn't answer: "Who's actually holding the phone at the bar at midnight?"

/research halvsies-host

Sample size: N is 4 (three pilot interviews and one running
field-notes file). That's really 3 customers. The headline says so.

Findings
- Guests won't download the app (4 of 4, strong). Gus, Imani and Pete
  each said it in their own words.
- They want the unpaid list, not the multi-trip dashboard (3 of 4,
  strong). Gus has opened the dashboard twice in three weeks.
- The receipt photo next to the number builds trust (3 of 4, strong).
- Auto-Split is trusted on printed receipts and breaks on handwritten
  ones (3 of 4, emerging).
- All three say they'll pay, with conditions (4 of 4, strong on
  intent). Nobody has paid yet.

What just happened. This is where the system pays for itself. The full synthesis file has a direct quote under every finding, tagged with the interview it came from, so nothing in it is vibes. ("Wedding guests are 22 to 85. Grandma isn't downloading Halvsies.") Then it went back to the four assumptions in the project's README.md and graded each one, and three of the four came back weakened. Host was scoped as a dashboard for planners. The evidence says it's a way for guests to pay without installing anything, with the receipt photo attached.

Jules doesn't stop at the synthesis. She hands it straight back with a detailed prompt, because the scope doc in artifacts/ was written in September, before anyone talked to a planner:

Rewrite projects/halvsies-host/artifacts/v1-scope.md using the synthesis
you just wrote (projects/halvsies-host/synthesis.md), the decisions in
projects/halvsies-host/decisions.md, and the Auto-Split launch decision
in projects/auto-split-v2/decisions.md.

Rules:
1. Every item in the "What's in" table needs a "Why" column that cites
   a specific quote (with the interview file it came from) or a dated
   decision. If an item has no evidence behind it, move it to "Later"
   and say so.
2. Re-rank priorities based on the findings, not on the original
   scope. If the synthesis weakened an assumption, the items that
   depended on it should drop.
3. Add a "What changed since v1" section at the top: three to five
   bullets, each naming the finding that caused the change.
4. Keep anything Bea or Coco already decided (pricing unit, annual
   discount) exactly as decided. Don't reopen it.
5. List the open questions this creates, each with an owner from
   team/ and a due date before the Nov 10 paid launch.
6. Don't invent numbers. If an item needs a number we don't have,
   write {number: ask Rafa} and keep going.

Save the old version as v1-scope-2026-09-01.md and write the new one
as v1-scope.md. Then give me a five-line summary I can paste to Ollie
before tomorrow's 2pm review.

The new scope leads with pay-by-link and the receipt photo, and the multi-trip dashboard drops to "Later." Ollie gets his answer the night before his review.

/weekly

The weekly update is a runbook: a folder with its own CLAUDE.md, a list of readers, a list of sources, the shape the update should take, and every update Jules has sent before. /weekly runs it one step at a time and stops after each.

1. Gather pulls from SPRINT.md, the done log, the week's daily notes, meeting notes, and decisions. Then it asks: "Which two or three of these does Coco need to know?"
2. Draft writes for the readers in readers.md. Coco gets the bottom line first. Bea gets one moment with a real planner, because her team file says a story beats a dashboard. The engineers get named when their work moved something.
3. Polish runs her voice rules.
4. Send happens only after Jules sends it herself. The final copy goes into sent/, where next week's draft reads it for tone.

The checkpoints are the point. Claude never runs all four steps in a row, because the useful part is Jules deciding what matters between steps.

/polish

Before anything goes to another human, it goes through context/voice.md: Jules's rules, her banned words, the habits she wants caught, and three messages she's actually written. Here's a real run on a draft that sounds like it came out of a press release:

Then it did the part I like most. It didn't make the update sound better by inventing details. It told Jules where the draft was still thin:

Where it's still thin
Your voice rules want numbers over adjectives and the bad news said
plainly. The draft has none to work with, and I didn't add any.
- Accuracy: a figure, like your "58% of handwritten tabs" style.
- Which customers: names instead of "several pilot customers."
- Guest behavior: the actual finding in place of "some things."

/new-skill scan

Last stop. Jules asks the OS to look at her own week and find work she keeps doing by hand.

/new-skill scan

I scanned memory/daily/ and memory/meetings/. That's only about 12
days of notes, so counts are small.

1. Pilot check-in write-up (how's it going, usage, moment that
   mattered, price reaction, renewal odds, asks). Your 10-20 note says
   "third time this week I wrote one up by hand in the same shape."
2. "Tell X about the call" follow-ups, in each person's format. Your
   sprint has Coco, Dev, Hana, Tamsin, Bea and Gus waiting on the same
   Auto-Split decision.
3. Ask someone for data, then track it. Mostly covered by /eod.
4. Pattern-spotting across pilots. Better as /research.

I'd start with #1. The shape is identical each time, the inputs are
the same, and you flagged it yourself.

What just happened. The OS read its own memory and proposed new commands Jules didn't know she needed. It also talked her out of two of them, because existing commands already cover them. Number 2 is the sleeper. Six people need to hear about one decision, and six people want it six different ways. That turns into one command, and it only works because the team files exist.

Jules builds /checkin. /new-skill asks her six questions, writes the skill, adds it to the command table in CLAUDE.md, logs it in CHANGELOG.md, and runs it once on yesterday's call notes so she can fix the wording. Then she runs /eod, which updates SPRINT.md, writes the day to memory/, and leaves a carry-forward list that tomorrow's /brief will start from.

Mod it

The OS ships with a starter set of commands, but the ones you'll use most are the ones you build, because they encode how you work.

/new-skill is the front door. Point it at something you keep doing or let it scan your memory folder. It interviews you, decides whether the job needs a skill (one sitting, one output) or a runbook (several steps with checkpoints and its own reference files), writes it, wires it into CLAUDE.md, and test-runs it on your real files.

Jules built /incident this way after her third customer fire of the year. It has its own runbook folder with a make-good menu sized to what the customer lost, plus a rule that her manager gets a two-line Slack within 30 minutes of any fire. That rule exists because of one bad Sunday, and now it's permanent.

If you want to skip the scan and go straight to building, give /new-skill everything up front. The more you tell it, the fewer questions it asks:

/new-skill Build me a command called /checkin for pilot and customer
check-in calls.

Trigger: I'll type /checkin <customer name> and paste my raw call
notes (or a transcript) underneath.

What it should do:
1. Find the customer's file in team/ and the project they belong to in
   projects/. If either is missing, ask before creating anything.
2. Write the call up in memory/meetings/YYYY-MM-DD-checkin-<name>.md
   using this exact shape: How's it going / Usage (what they actually
   use, not what they say) / Moment that mattered / Price reaction /
   Renewal odds (yes, likely, coin flip, unlikely, no) / Asks.
3. Copy any direct quotes into the project's research/field-notes.md,
   newest on top, with the date.
4. If they said yes, no, or changed their renewal terms, log it in the
   project's decisions.md and update the tally in MISSION.md (for
   example "2 of 3 pilots in"). Ask me before changing MISSION.md.
5. Add anything I promised to SPRINT.md under Commitments with a due
   date, and anything they promised under Waiting on.
6. Add new facts about how this person works to their team file under
   "Notes over time," dated.

Checkpoint: show me the filed receipt (every file touched and what
changed) before you change MISSION.md.

Rules: never invent a quote, number, or date. If my notes are unclear
about who said something, mark it (unclear who). Keep the write-up
under 200 words.

When it's written, test it on memory/meetings/2026-10-21-pilot-checkin-pete.md
so I can see the output, then ask me what to change.

Three rules make a skill good inside Builder OS:

• Point at files instead of pasting knowledge in. The skill says "read the team file." The knowledge lives in the folder, where every other command can use it.
• Degrade gracefully. If the calendar isn't connected, say so in one line and use the files.
• Write the output to a file, so the next command can build on it.

Builder OS and Shipforward

If you've seen Shipforward, my agent software factory for Claude Code, you might be wondering how the two fit. They're built to work together, and they solve different problems.

Builder OS is your desk. It's personal, it runs every day, and it lasts longer than any one project. It knows your people, your week, your commitments, and why every call got made. It's where you figure out what to build and why.

Shipforward is the factory floor. It runs inside a codebase, one product at a time, and moves work down a line: idea, PRD, spec, tickets, code. It's where the what becomes something people can use.

The handoff runs both ways.

Going out: when a project's research and decisions are solid, /handoff out packages them into one file: the problem, who has it, the evidence with quotes, the decisions that are already final, the constraints, and the open questions. Shipforward starts from that file instead of from a blank PRD, so the spec is grounded in what users actually said.

Coming back: building always surfaces decisions nobody planned for. The confirm screen ships a day late. A scope cut happens in a ticket thread. Engineering picks a 0.97 confidence cutoff instead of 0.95. Paste those into /handoff in and they land in the project's decisions.md, the dates land in SPRINT.md, anything that shipped goes into memory/done/, and anyone who needs to hear about it gets a tell-them commitment. Friday's /weekly picks all of it up without you retyping a thing.

In Jules's world, the Auto-Split guardrail is a perfect example. She made the call on Thursday in Builder OS. The confirm screen gets specced, ticketed, and built in Shipforward. When it ships to the pilots on October 28, the build's decisions flow back, and her update to Coco writes itself from files.

Here's the prompt Jules would use to kick off that handoff:

/handoff out auto-split-v2

Package this project for the build. Context for whoever picks it up:
we decided on 2026-10-22 to ship Auto-Split v2 on Nov 5 with a
confirm-before-send guardrail, give it to the three Host pilots on
Oct 28, and retrain on handwritten tabs in January.

Make sure the handoff file includes:
1. The Nashville incident in plain words, using the read log in
   research/nashville-tab-read-log.md as the only source for times
   and amounts.
2. Rafa's exact-total rates by receipt type from
   research/read-quality-2026-10-11.md, with his caveat about the
   small handwritten sample copied word for word.
3. The three guardrail triggers exactly as Dev wrote them in
   artifacts/model-notes.md (hard receipt type, confidence below the
   cutoff, any share over 3x the group's usual), and mark the cutoff
   (0.95 vs 0.97) as an open question owned by Dev.
4. Gus's quote "dont tell me $612 show me the receipt" as the design
   north star for the confirm screen.
5. Every constraint the build has to respect: the Oct 28 pilot date,
   the Nov 5 launch, the Nov 13 feature cutoff, the Dec 14 code
   freeze, and that Tamsin needs final user-facing wording by Oct 29.
6. A "Do not reopen" list with every decision from decisions.md.

Don't design the confirm screen. Don't invent numbers. If the build
will need something we don't have, put it under Open questions with
the person in team/ who can answer it.

Builder OS is free, and it's useful on its own whether or not you ever use Shipforward. If you're building software and want the factory too, that's what Shipforward is for.

Not a PM? Start with /onboard

The blank OS starts with one command. /onboard is an interview, not a form: one or two questions at a time, about fifteen minutes total, writing files as it goes so nothing is lost if you stop halfway.

It covers seven short sections:

1. You: your role, and what you'd tell a new teammate you actually do all day
2. Goals: what you're on the hook for, your biggest current project, and what you're explicitly not doing
3. Team: your manager and the people you work with every week, with how each one likes to get information
4. Rhythm: your recurring meetings and the work you produce on repeat
5. Tools: what's connected, what could be, and what stays as files
6. Voice: you paste a few things you've written, and it pulls out your rules
7. Pack: it suggests runbooks built for your kind of work

That last step uses role packs. Here's a sample of what each one includes:

If your role isn't on the list, it builds a pack from the repeat work you described in the rhythm section.

Set it up

1. Download the blank OS and unzip it somewhere you'll keep it.
2. Open a terminal in the folder and run claude.
3. Type /onboard.
4. Tomorrow morning, type /brief.

If you'd rather look around first, the example download will let you open the files in Claude Code and replay Jules's Thursday. Its README lists the commands in order and includes the exact notes to paste into /debrief.

Share with a team, if you need to

Builder OS is local first. You do not need a team layer. If you want shared context, keep it in a separate, team-owned GitHub repository, cloned into shared/ or added as a Git submodule in each person's private Builder OS.

Share only reviewed team context: company and product facts, a glossary, confirmed metrics, project decisions, source-backed research, handoffs, and team runbooks. Keep daily notes, SPRINT.md, one-to-ones, personal work preferences, and private opinions about people in each person's own OS. Let Claude read shared/, but send changes through a pull request so a teammate reviews them before they become shared truth. Pull the latest version when a work session starts to keep everyone's context current.

GitHub works well when the team uses pull requests. Teammates who prefer Obsidian can open the same repository as a vault with the obsidian-git plugin, while GitHub remains the source of truth and review path. If the team will not use GitHub, a shared Notion or Drive folder is a better home. Builder OS still works on its own without any of this.

For a GitHub team repo, clone it into shared/ first, then run this one-time setup prompt from your Builder OS. It asks Claude to prepare a small, source-backed starter set without publishing your private notes.

Set up the optional shared team layer for my Builder OS.

Treat this Builder OS as my private workspace. Treat shared/ as a
separate, team-owned GitHub repository.

First, check whether shared/ exists and is a Git repository. If it
doesn't, stop and ask me for the team repository URL. Do not create
or change a remote.

Review my local files and propose a concise, source-backed starter
set for shared/:
- context/company.md, product.md, glossary.md, and metrics.md
- projects/PROJECT-SLUG/README.md and decisions.md
- projects/PROJECT-SLUG/research/ and handoffs/
- runbooks/ for team-wide processes

Do not copy daily notes, SPRINT.md, one-to-ones, personal goals or
work preferences, private opinions about people, customer personal
data, credentials, or unverified claims. Cite the source file for
each fact in research and decision context.

Before changing anything, show me a file-by-file plan with the exact
source paths and proposed content. Wait for my approval.

After approval, add only the approved content on a new branch. Preserve
existing shared files and show me the diff. Prepare a pull request for
review, but do not merge it.

Add a short rule to my personal CLAUDE.md: read shared context, never
write directly to the shared main branch, and propose future updates
through pull requests.

Offer a Claude Code SessionStart hook that runs
git -C shared pull --ff-only. Show me the settings change and wait for
approval before adding it. If GitHub CLI is unavailable, leave the
branch local and give me the commands to open the pull request.

Questions people ask

Do I need to connect my calendar and task tracker?

No. Every command works from the files alone. Connections make /brief and /weekly pull live data, and /onboard checks what's available and offers to use it.

Won't the files go stale?

That's what the daily loop is for. /debrief updates team files and commitments after every meeting, /eod updates SPRINT.md at the end of the day, and /cleanup runs once a week to catch stale projects, aging waiting-on items, and an inbox that's getting full. The OS stays current because the commands you already use keep feeding it.

Does this work outside Claude Code?

The core is just markdown in a folder, so any AI tool that reads local files can use it. The slash commands, the session hook, and connections are what make it smooth in Claude Code.

How is this different from a Notion second brain?

A second brain is something you maintain so you can read it later. Builder OS is something Claude reads and writes as part of doing the work. You rarely file anything by hand.

Do I need Shipforward to use Builder OS?

No. Builder OS works on its own for any role. Shipforward is for people turning ideas into shipped software, and /handoff connects the two when you use both. It also works with any other build workflow: the handoff file is plain markdown.

Can I put work information in it?

It's local files on your machine. Follow your company's rules about what can go where, the same as you would for any notes.