Charlie's Package: First Build, First Three Sessions

01The mission

The big goal. Then the entry point.

Mark, Ewing, and John each cover a slice of the funnel today. The ceiling is their time. The mission is to take the Meetings page from a working tool to a B2B CRM automation engine that lets each of them cover 5x as many leads at the same quality. Same headcount. Same close rate. Five times the deal flow.

That goal is months of feature work. Your first build is the entry point. It is small on purpose. It teaches you the data, the signals, the API patterns, and the people. Once you understand those, you stop being the new person and start being the operator who knows the funnel better than anyone else.

02What you're building (concrete)

A morning view that sorts unclassified meetings by signal strength, lets you classify them in batches, and shows you how fast you got through the queue.

Page name: Daily Triage. Lives at /meetings/triage. Permission tier: intern. You can ship this without operator approval.

What's on the page

1. Daily stats card (top of page)

Four numbers, computed live from feature_metrics:

• Meetings classified today: count of meetings.classify events where actor is you and the timestamp is today.
• Median time per classification: median delta between consecutive classify events in your session today. If you only have one event, show "first one of the day".
• Promotion candidates surfaced: count of meetings in today's queue where the promote criteria are met (defined below).
• Leads qualified: count of meetings classified as a deal today by you.

2. Prioritized queue (main body)

List of unclassified meetings sorted by a single composite priority score:

priority = (revenue_signal_count * 30) + opportunity_score + recency_bonus

recency_bonus = 20 if call was today
              = 10 if call was yesterday
              =  0 otherwise

Each row shows: contact name, company, when the call happened, the auto detected signals (badges), the Quick Classify dropdown, and the promote indicator.

3. Auto detected signals (badges per row)

Read straight from src/components/meetings/derive.ts. Three badges:

• Revenue mentioned (green): signals.revenue_mentioned is truthy.
• Motivated seller (orange): signals.sell_urgency is truthy.
• Buyer signal (blue): the transcript matched the buyer phrase set in derive.ts.

4. Quick Classify dropdown (per row)

Inline select with the canonical classifications from src/lib/classifications.ts: deal, voicemail, no_answer, gatekeeper, not_interested, bad_number, callback_requested. On change, the dropdown calls PATCH /api/meetings/[id]/classify and the row fades out of the queue.

5. Promote to deal indicator (per row)

Lights up green when all four conditions are true:

• revenue signal flag is set on the meeting
• opportunity score is 30 or higher
• classification is deal
• entity (company) is linked

Charlie cannot promote. Promotion is operator tier. The indicator just tells you "this one is ready for Mark to promote." Clicking it creates a task in the /review/tasks queue.

03The data you'll touch

Two tables and one component. Read each before you write a line of code.

04The feature def you'll register

Add this entry to src/lib/features/defs/meetings.ts before you write any UI code.

{
  key: 'meetings.daily-triage',
  page: 'meetings',
  label: 'Daily Triage',
  description: 'Morning queue of unclassified meetings sorted by signal strength, with inline Quick Classify and live stats',
  status: 'design',
  tier: 'intern',
  owner: 'charlie',
  created_at: '2026-05-06',
  metrics_key: 'meetings.daily-triage',
  requires_review: false,
  cost_category: 'free',
}

Status starts at design. Move it to build when you start writing the page. Move it to test when you can render the queue. Move it to live only after Mark has classified at least 5 meetings using your page without a bug.

05The API route already exists

You don't need to build a route for the classify dropdown. It's done.

The handler at src/app/api/meetings/[id]/classify/route.ts accepts PATCH with body { classification: string }. It validates against the canonical list, writes the update, and records a meetings.classify event in feature_metrics.

The pattern from your dropdown

async function classify(meetingId: string, classification: string) {
  const res = await fetch(`/api/meetings/${meetingId}/classify`, {
    method: 'PATCH',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ classification }),
  })
  if (!res.ok) throw new Error(await res.text())
  return res.json()
}

Two rules:

• Never write to meeting_notes from the browser. Always go through this route.
• If the call fails, surface the error in the row, not as a toast that disappears. Mark needs to see what went wrong.

06The page you'll build

One server file for the initial render. One client file for the dropdowns.

File layout

Server pattern (page.tsx)

import { canUse } from '@/lib/features/permissions'
import { getCurrentActor } from '@/lib/auth'
import { getTriageQueue, getTodayStats } from './queue'
import { StatsCard } from './StatsCard'
import { QuickClassifyRow } from './QuickClassifyRow'
import { FeedbackBox } from '@/components/FeedbackBox'

export default async function TriagePage() {
  const actor = await getCurrentActor()
  if (!canUse('meetings.daily-triage', actor)) return <NotAllowed />

  const [queue, stats] = await Promise.all([
    getTriageQueue(),
    getTodayStats(actor),
  ])

  return (
    <main>
      <StatsCard stats={stats} />
      <ul>
        {queue.map((m) => <QuickClassifyRow key={m.id} meeting={m} />)}
      </ul>
      <FeedbackBox feature="meetings.daily-triage" />
    </main>
  )
}

Two things this pattern enforces. The canUse() check gates the page. The FeedbackBox guarantees Mark can leave a sentence the first time he uses it.

07Definition of done

The checklist. Don't say "done" until every box is ticked.

08How to demo it

Show, don't tell. Let Mark drive.

Set up a 15 minute slot with Mark. Pull up /meetings/triage on his screen. Hand him the keyboard. Say one sentence: "Triage the morning queue." Then shut up.

Watch where he hesitates. The hesitations are the bugs. After 10 minutes of him classifying, ask three questions:

1. "What was missing?"
2. "What was in the way?"
3. "What would you do tomorrow morning that this doesn't help with yet?"

Write his answers down. Within 24 hours, file each answer as a feature idea or a ticket. Don't argue any of them in the room.

09Recommended skills for this build

Four skills that will make this faster.

10What to do AFTER this ships

The next five builds. Each one builds on the Daily Triage.

Don't pick the next one yet. Ship the Triage first. Demo it. Take feedback. Then pick whichever of these Mark or John tells you matters most.

1. Auto classification suggestions. Use the existing transcript and signal data to suggest a classification on each row. The dropdown still lets Charlie or Mark override. Track agreement rate. Once agreement passes 85%, suggest defaulting.
2. Voicemail callback queue. A second view at /meetings/callbacks. Surfaces voicemail classified meetings ordered by callback freshness, contact responsiveness history, and time of day patterns. The job: tell Mark which callback to make next.
3. Gatekeeper detection signals. When the transcript suggests the caller hit a gatekeeper, surface what the gatekeeper said and what John would say next. Track gatekeeper bypass rate per company.
4. Campaign aware prioritization. The queue today treats every meeting equal. Layer in outreach_campaigns so meetings tied to active campaigns float up and meetings tied to closed campaigns sink.
5. Auto enrichment trigger. When a contact answers a phone for the first time and gets classified as a deal, fire an enrichment job (linkedin, exa, web) and put the results on the meeting detail page within an hour. Bound by the circuit breaker so it never runs more than 25 times a day on intern tier.

Each one is its own feature def, its own loop, its own demo. Don't try to ship two at once.

11Your three expert Zooms

30 minutes each. Product input, not training. The point is for you to learn what to build, not for them to teach you M&A.

The shared briefing covers the universal rules. Read those again before each call. Below are the three prep packs tuned to the specific person you're talking to. Each pack has a goal, what to verify before the call, the question bank, what NOT to ask, and the writeup template you fill out within 24 hours.

12Post session writeup template

Same template for every session. Within 24 hours. No exceptions.

Save each writeup to skills/maxswarm/notebook/sessions/charlie-<expert>-<date>.md. Format:

Session: Charlie : <expert>
Date: <date>
Goal stated: <what I told them at the start>

Three themes that came up:
1.
2.
3.

One thing that surprised me:

One thing they want but didn't say (my interpretation):

Three feature ideas that came out of this:
1.
2.
3.

What I'm doing in the next 7 days based on this:

The writeup is the artifact. Don't trust your memory. Fireflies has the transcript if you need to verify a quote. Your interpretation is what matters most. Write it while it's fresh.

13Your requirements (live)

Pulled from your Fireflies transcripts of the John, Mark, and Ewing sessions, then consolidated into a build queue. Click any field to edit. Edits save on blur.

Calendar invite title pattern: Charlie & John discuss Meetings Page for System Requirements Gathering. Match this exactly so the auto-extractor knows to pull from the transcript.

13Quick reference

Keep this open in a tab while you build.

Files for the Daily Triage

Commands

When stuck (in this order)

1. Re read the shared briefing, section 4 (the Loop) and section 11 (a feature is a loop).
2. Re read this page, section 7 (definition of done).
3. Invoke /auto-fix with the specific error.
4. Invoke /architect if it's a "where does this live" question.
5. Create a task at /review/tasks.
6. Ask in #intern-help on Slack. One channel.
7. Last resort: page Ewing.