Charlie + Bear: Your Mission, Your Tools, Your Operating Loop

01Where you are

A 60 second briefing on the company you just walked into.

Next Chapter is a boutique M&A advisory firm. We help midmarket business owners in home services (plumbing, HVAC, roofing, pest control) sell their companies.

The deal makers:

02What's been tried

You're walking into months of accumulated work. Don't propose what's already been tried.

The retired

• Old Supabase project rdnnhxhohwjucvjwbwch was retired April 2026 after 74,021 rows were archived. Never write there. Canonical Supabase is dwrnfpjcvydhmhnvyzov.
• Lob direct mail integration was abandoned mid project after costly undeliverables. Letter generation still exists in engine/contacts/ but the send path is paused. If anyone says "ship a letter," check with Ewing.
• Repos consolidated May 2026 from 4 down to 1. If you find references to next-chapter-deals, claude-skills, next-chapter-brain, or next-chapter-contacts, those are archived. This repo (next-chapter-os) is the only place to clone.

The hard rules earned in blood

• 250/150 governor: max 250 letters per batch. Hard stop until 150 contacts have been called 5 times each. Built after we burned cash on letters with no follow up.
• DNC is universal: one block is blocked everywhere. All entities. All channels.
• Letters before calls: mail sends first, enrichment is post letter. Reverse the order and you waste enrichment dollars on cold contacts.
• Multi LLM consensus required before customer facing documents. One model is not enough for a letter that goes to a CEO.

The recent rebuilds

• Old campaigns table (21 production rows of letter campaigns) was preserved when we built the new outreach_campaigns table. Don't confuse them. Letter campaigns belong in the old table. Pipeline campaigns belong in the new one.
• Promote to deal contract was just formalized. src/lib/handoff.ts defines HandoffPayload, isPromotable(), and promotionDecision(). Score 50+ auto promotes. 30 to 49 enters a review queue. Below 30 skips.
• Master cost table (spend_log) replaced the old per service ledgers. Every dollar spent gets tied to company_id, contact_id, campaign_id, deal_id, plus model, tool, source_type, and pricing_model.
• Stuck detector just shipped. The system watches your feature_metrics events. If you loop on the same action, spin without progress, or go idle for hours, it pings Ewing automatically.

03How we build at Next Chapter

The philosophy. Print this on a card.

1. We build systems of features, not features that sit idle. A feature without a loop is decoration.
2. We build small. Ship early. Test on ourselves before showing experts. Their time is rare.
3. Every feature has a registered definition before code is written. If it's not in src/lib/features/defs/, it doesn't exist.
4. Every API mutation is gated by canUse() and metric'd. No exceptions, even for one off internal tools.
5. Every dollar spent goes through circuit-breaker.ts. If you call a paid API outside the breaker, you create a budget incident.
6. Every credential comes from Doppler. Project clawdbot, configs dev and prd. Never hardcode. Never use .env. Never copy paste a key.
7. Every deliverable an expert reads is HTML with inline CSS. Markdown is fine for code. HTML is fine for humans.
8. Every assumption gets verified by reading the file. Don't guess. Don't paraphrase. Read.

04The Loop

The discipline that separates "I built a thing" from "we shipped a feature."

Five phases. None are optional. Skipping one is the most common failure mode in this organization.

Skipping the loop looks like:

• Skip plan: "I'll just start coding." You will rebuild the same thing 4 times.
• Skip test: "It looks right." Mark opens the page and it crashes.
• Skip feedback: "I'll show them when it's perfect." It will never be perfect. Show them at 60 percent and refine.
• Skip iterate: "They had feedback but I disagreed." Then you didn't actually use the feedback.

05Plan first

10 minutes of planning saves 2 hours of building.

Before you write a single line of code, do this:

1. Read the file. Open the source you'll modify. Read it. All of it. If it's long, read the part you're touching plus 30 lines on either side.
2. Verify the schema. Run a query like ?limit=1&select=* on the table you'll write to. Confirm the columns exist. Confirm the types match what you think they are.
3. Sketch the loop. What triggers your feature? What work does it do? What downstream consumer reads its output?
4. Identify the feature def. Does src/lib/features/defs/<page>.ts already have an entry? If not, register one at status: 'design' before writing code.
5. Identify missing API routes. If your UI needs a route that doesn't exist, list it. Don't write to Supabase from the browser. Ever.
6. Estimate cost. How many file reads? How many edits? Will you call any paid APIs? If so, check circuit-breaker.ts for the threshold.

Write the plan into the conversation with Claude Code before asking it to build. The plan IS the prompt.

06Build with Claude Code

Claude Code is your pair programmer. Treat it like one.

• One feature per conversation. When you finish a feature, start a new chat. Long chats accumulate context that becomes noise.
• Paste error messages verbatim. Never paraphrase. Errors include line numbers and stack traces that matter.
• Read first, ask second. "Read src/app/meetings/page.tsx then tell me how classification is wired up" beats "how does classification work?"
• Invoke skills. Use /<skill-name> to call battle tested skills instead of reinventing. The skill list is at section 13.
• The pre commit hook is your friend. It blocks em dashes, key patterns, and naming drift. If it complains, fix it. Don't --no-verify.
• Doppler handles credentials. Every script you run that needs an API key runs as doppler run --project clawdbot --config dev -- <command>. You will never need to find or paste a key. If you ever feel like you need to ask someone for a credential, stop and re read this rule.

Token economics

Claude Code costs money per token. Cheap rituals that save tokens:

• Tell Claude exactly which file to read instead of letting it search.
• Use /audit-quality to lint output before submitting, not after.
• If you've made 5 attempts at the same problem, stop and rephrase. You're not getting closer.
• Use background agents for research that doesn't need to be in your immediate context.

For the full model selection guide, see Section 07.

07Pick the right model

Three brains, three price tags, three jobs. Match them or burn money.

Claude Code gives you access to three models. They are not "good, better, best." They are different tools for different jobs, the way a hammer, a screwdriver, and a level are different tools. Using Opus to search a file is like using a level to drive a nail. It will work. It will cost five times more. And you will learn nothing from the experience except that you wasted money.

The three models

The 10-second decision

Before every Claude Code session, ask yourself one question:

Three litmus tests:

• "Can I answer this by reading one file?" — LOOKUP (Haiku)
• "Can I describe the output I want in one sentence?" — BUILD (Sonnet)
• "I need to describe the problem, not the solution." — DESIGN (Opus)

How to switch models

In Claude Code, type /model and select the model you want. You can switch mid-session, but it is usually better to start a new session at the right model. Here are the model IDs:

/model claude-haiku-4-5-20251001    # Scout — lookups, file reads, grep
/model claude-sonnet-4-6             # Builder — features, bugs, API routes
/model claude-opus-4-7               # Architect — design, novel debugging

Your tasks, mapped to models

Every task you will do in your first month falls into one of these buckets. This is not a suggestion. This is the guide.

HAIKU tasks LOOKUP

SONNET tasks BUILD

OPUS tasks DESIGN

The napkin math

10 Haiku sessions  ≈  1 Sonnet session   (in dollar terms)
 5 Sonnet sessions ≈  1 Opus session
50 Haiku sessions  ≈  1 Opus session

This means: be liberal with Haiku. 30 Haiku lookups in a day costs less than 3 Sonnet prompts. Do not try to squeeze a BUILD task into Haiku to save money — you will waste more tokens on failed attempts than you save. And do not avoid Opus when you genuinely need it — 45 minutes of Sonnet flailing can cost more than one Opus call, plus you lose the 45 minutes.

Session discipline

How you structure your Claude Code sessions determines how much they cost. Every message you send includes all the accumulated context from the conversation. A 40-message session means message 40 carries the weight of messages 1 through 39. This is why long sessions get expensive.

1. One feature, one conversation. When you finish, close the chat. Start fresh. This is already in Section 06. Now you know why it matters economically.
2. Start with the plan, not the code. Your first message should be the plan from Section 05. Tell Claude what you are building, which files are involved, what the output looks like. This front-loads the right context and prevents Claude from reading files you do not need.
3. Tell Claude which files to read. "Read src/lib/handoff.ts and explain promotion" costs a fraction of "How does promotion work?" — the second makes Claude search, read wrong files, and accumulate junk context.
4. Use /compact when context grows. If your conversation exceeds 20 exchanges, use /compact to summarize and compress. This directly reduces cost for every subsequent message.
5. Five attempts, then change strategy. If the same fix has not worked after 5 tries, do one of three things:
   • Rephrase the problem completely (maybe your description is misleading Claude).
   • Upgrade the model (if you are on Sonnet, try Opus for diagnosis only).
   • Close the session and start fresh with a different approach.
   This connects directly to the stuck detector (Section 15): 5 failed events in 30 minutes triggers the "looping" pattern. Catch yourself before it catches you.
6. Separate research from execution. If you need to understand an unfamiliar subsystem before building in it, do the research in a separate Haiku session. Read the files, take notes, close it. Then open a new BUILD session with only the relevant context.
7. Background agents for research. If you need to understand something that does not block your current task, spin it off to a background agent. Keeps your primary context clean and cheap.

The upgrade ladder

You will sometimes start a task at the wrong model tier. That is normal. Here is how to escalate:

When the stuck detector fires and what it means for model choice

The Opus justification

When you use Opus, you should be able to state the reason in one sentence. Not logged formally — this is a mental discipline, not bureaucracy.

Skills and model choice

Skills like /architect, /audit-quality, and /auto-fix handle their own internal model preferences. Your model choice applies to the Claude Code session that invokes the skill, not to the skill itself.

Expanding the skill library

Skills are not read-only. If you find yourself doing the same sequence of steps three or more times, it should become a skill. The rule:

1. Notice the pattern. You have run the same 4-step process three times this week.
2. Propose it. Create a task at /review/tasks describing what the skill would do, what triggers it, and what it produces.
3. Wait for approval. Skill creation is an operator-tier action. Ewing or Mark will review your proposal.
4. Build it. Once approved, use /skill-creator to scaffold the skill. Follow the existing pattern in skills/ — every skill has a SKILL.md that explains triggers, inputs, and outputs.

Do not build skills unsupervised. A bad skill that fires on the wrong trigger can cause more damage than the manual process it replaced. Propose first, build second.

08Test before experts

The hardest discipline. Skip it once and you'll skip it forever.

Test patterns

How to know you're done testing

You're done when:

• npx tsc --noEmit passes with zero errors.
• You can describe what your feature does, what it doesn't do, and one edge case where it might fail.
• You've personally clicked through the happy path twice.
• You've checked feature_metrics and confirmed the action recorded.
• If a paid API was involved, you've checked spend_log.

Only then do you put it in front of an expert.

09Expert feedback

Mark, John, and Ewing are your users. They will tell you what's broken. Your job is to listen, not defend.

Three feedback channels

1. FeedbackBox on the page. Every feature you build gets a feedback box. The expert types a sentence. You read it the next morning.
2. Weekly sync. Once you have something to show, you'll get 15 minutes a week with one of the experts. Show, don't tell. Let them click. Watch where they hesitate.
3. Tickets. If something is broken in production, an agent_ticket may be created automatically. Check the queue.

How to receive feedback well

• Don't argue. Note it. Decide later.
• If you don't understand the feedback, ask one clarifying question. Then stop.
• If they say "this is wrong," your job is "what would right look like?" not "let me explain why I built it this way."
• Within 24 hours, write up the feedback in the feature's commit history or in a notebook entry.

10Iterate

Every iteration tightens the spec.

Take the feedback. Restart the loop. Plan the change. Build it. Test it. Show them again.

Every iteration produces:

• A tighter feature def (the description gets sharper)
• A better understanding of the user (the expert is teaching you their job)
• One question for the next session ("you said X, did you mean Y?")

The loop never ends. Mature features still iterate. The day you stop iterating is the day the feature starts decaying.

11Your six input sessions

The most valuable 30 minutes you'll have for the next month. Each.

You each get three 30 minute Zooms with the experts:

Universal rules (every session)

1. Read everything before the call. If you ask a question you could have answered by reading the docs, you've wasted a minute that you cannot get back.
2. Have a goal. State it in the first 60 seconds. "Today I want to understand how you triage your morning queue."
3. Don't ask "what should I build." Tell them what you're building. Ask if it solves their problem.
4. Fireflies records the call. Transcript appears at /meetings/<id>. You can rewatch yourself.
5. Within 24 hours, write up: three themes that came up, one thing that surprised you, one thing they want but didn't say.

Question categories that work for every session

1. Day in the life. "Walk me through 7am, 10am, 3pm. Show me your screen if you can."
2. Decisions you make. "What questions do you ask yourself before classifying a call?" "Before promoting a deal?" "Before calling a target?"
3. Pain points. "Where do you waste time?" "What forces a context switch?" "What do you do twice that should be done once?"
4. Stories of failure. "Tell me about a deal that died because of bad data, bad timing, or a bad handoff."
5. Stories of wins. "Tell me about a deal that closed because something worked perfectly."
6. The judgment call. "Where would you never trust software to make the call?"

Per expert question banks tuned to John, Mark, and Ewing live in your individual onboarding doc. Open Charlie's package or Bear's package for the per session prep packs.

12A feature is a loop

If you remember one thing from this entire document, remember this section.

Examples of loops build these

Examples of decoration don't build these

Before you build, ask: what consumes my output? If the answer is "the user looks at it," that's fine if the user actually looks at it. If the answer is "another system reads it and does something useful," that's better.

13Skills that are your friends

68 skills are installed. These are the ones you'll use in your first month.

How to invoke: type /<skill-name> in Claude Code with arguments after.

Both of you, daily

Charlie's daily five

Bear's daily five

Browse the full list at skills/ in the repo. Each skill has a SKILL.md that explains what it does and when to use it.

14How you two collaborate

The handoff contract is your shared language. Use it.

The contract

• Charlie owes Bear: classified meetings within 24 hours of call. Promotions with complete HandoffPayload data. Honest signal flags.
• Bear owes Charlie: warm lead reviews within 48 hours. Rejections with reasons (the system enforces a 10 character minimum). Deal outcomes that inform Charlie's classification approach.
• Both owe each other: a clean spec when you ask for something. "Can you give me X" is not a spec. "I need X to look like Y because Z" is a spec.

How to disagree

1. If Charlie classifies a meeting as a deal and Bear thinks it's not, Bear rejects with a reason. The rejection is the conversation.
2. If you genuinely conflict on something the system can't resolve, escalate to Ewing. Don't workaround. Don't build duplicate code paths.
3. Don't use Slack as a spec. Slack is for "are you stuck?" Spec lives in code (types, feature defs, API contracts).

Weekly ritual

Every Friday: each of you produces one piece of output the other relies on. Show it. Talk through it. Adjust before Monday. The system is designed so neither of you can succeed without the other being good. That's intentional.

15Failure modes

The stuck detector watches for these. If you hit one, a ticket is created. Treat the ticket as a signal, not a punishment.

16Quick reference

Keep this open in a tab.

Key files

Commands

When you're stuck (in this order)

1. Re read the relevant CLAUDE.md.
2. Re read the feature def for what you're building.
3. Re read this document, especially section 4 (the Loop) and section 11 (a feature is a loop).
4. Invoke /auto-fix with the specific error you're seeing.
5. Create a task at /review/tasks.
6. Ask in #intern-help on Slack. One channel, not DMs.
7. Last resort: page Ewing.

Your individual packages

Open the page that has your name on it:

• Charlie's package — first AI build, three expert session prep packs, recommended skills
• Bear's package — first AI build, three expert session prep packs, recommended skills