Marta Meeting Processing

Process post-meeting artifacts from Marta/BeonIQ meetings. Fetches transcripts, saves notes, updates context, syncs GitHub issues, and posts summaries to Slack.

Trigger: Use when user says "process the meeting", "grab the marta meeting", "meeting notes", or after any meeting with Marta/BeonIQ team.

Workflow

Phase 1: Fetch Transcript

1. Fathom API (primary source):

   bashCopy

   # List recent calls
   curl -s -H "X-Api-Key: 2Oio2EqggEIt5g_XuDt3KA.8ubzimd9viyHFQw-kc4A-uXfuDCS7kKOwC3bUGY5Np8" \
     "https://api.fathom.ai/external/v1/calls?limit=10" | jq '.calls[:5] | .[] | {id, title, started_at}'
   

   Then fetch the specific call:

   bashCopy

   curl -s -H "X-Api-Key: 2Oio2EqggEIt5g_XuDt3KA.8ubzimd9viyHFQw-kc4A-uXfuDCS7kKOwC3bUGY5Np8" \
     "https://api.fathom.ai/external/v1/calls/<CALL_ID>" | jq '.'
   

2. Granola (backup):

   • Cache at /Users/tori/Library/Application Support/Granola/cache-v4.json
   • Contains metadata + transcripts (notes/summaries are server-side only)

Phase 2: Save Meeting Notes

Save to: context/team-communications/YYYY-MM-DD/meetings/

Filename format: fathom-<descriptive-slug>-<recording-id>.md

Template:

# [Meeting Title]

**Date:** [Date, Time CT]
**Source:** Fathom (Recording ID: [ID])
**Participants:** [Names and roles]
**Artifacts:** [Any shared docs, boards, etc.]

---

## Key Decisions

### 1. [Decision Title] (CONFIRMED/PROPOSED/DISCUSSED)
- Detail
- Quote if impactful

---

## Action Items

| Owner | Action | Priority |
|-------|--------|----------|
| Name | What to do | High/Medium/Low |

---

## Architecture Impact on Existing Issues

- **#NNN** (issue title): How this decision affects the issue

---

## GitHub Issues Created

| Issue | Title | Assignees | Labels |
|-------|-------|-----------|--------|
| #NNN | Title | @user | label1, label2 |

*(Populated during Phase 4c)*

---

*Captured from Fathom transcript. [Any availability notes]*

Phase 3: Update Context File

Update context/marta-mvp.md with:

• New decisions that change architecture or domain model
• New action items
• Updated subscription/pricing info
• New UX decisions or deferred topics
• New meeting notes file reference

Phase 4: GitHub Issues

Phase 4a: Comment on Existing Issues

For each issue affected by meeting decisions:

1. Add a comment with the relevant decision
2. Quote the speaker if it clarifies intent
3. Reference the meeting notes file
4. Update labels if status changed

Comment template:

## Update from [Date] Meeting

[Decision or finding]

> "[Quote from participant]" — [Name]

See: `context/team-communications/YYYY-MM-DD/meetings/[filename].md`

Phase 4b: Dedup Check

Before creating ANY new issue, search for duplicates:

gh issue list --repo ChinchillaEnterprises/transportation-insight --search "key words from action item" --state open --json number,title,assignees,labels

If >70% scope overlap with an existing open issue: Comment on the existing issue instead of creating a new one. Add the new context/requirements from the meeting.

Phase 4c: Auto-Create New Issues

For each new action item with clear scope, create an issue using the assignment and label rules below.

gh issue create \
  --repo ChinchillaEnterprises/transportation-insight \
  --title "[PREFIX] Issue title" \
  --assignee user1,user2 \
  --label "label1,label2" \
  --body "$(cat <<'EOF'
## Source
[Date] meeting with [participants]

## Context
[Why this issue exists, what meeting decision drove it]

## Requirements
- [ ] Requirement 1
- [ ] Requirement 2

## Relationship to Existing Issues
- Depends on #NNN
- Blocks #NNN
- Related to #NNN

## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2
EOF
)"

After each issue is created, record it in the meeting notes ## GitHub Issues Created table.

Phase 4d: Post-Creation Tracking

After all issues are created:

1. Update the meeting notes file with the ## GitHub Issues Created table
2. Include created issue numbers in the Slack summary (Phase 5)

Team Assignment Rules

Map action items to assignees based on domain keywords in the action item content.

Multi-assignee rules:

• Full-stack features (touches both UI + backend) → feathars91,SOROUSH911
• Features with explicit QA acceptance criteria or "Hailee to verify" → add hailee-landin
• Ambiguous domain or purely technical → default feathars91
• Never assign mbras (Marta is the client, not a developer)

How to apply: Read the action item content. Match keywords against the Domains column. If multiple people's domains match, assign all of them. If nothing matches, default to feathars91.

Label Assignment Rules

Apply labels in three categories. Use existing repo labels only.

1. Type (exactly one)

2. Priority (if discussed in meeting)

3. Context (all that apply)

Issue Title Prefix Rules

Every issue title MUST start with a prefix in brackets:

Phase 5: Post to Slack

Post summary to #marta channel (C09QU6TN2EQ), tagging Marta (<@U095VLYG3C7>):

Keep it SHORT — 3-5 bullets max. Link to the meeting notes file or GitHub issues for details. Include any newly created issue numbers.

Also post to #internal-beoniq (C09JD94HRUN) with:

• Key architectural decisions
• Action items for Abel/dev team
• Any blockers or priority changes
• List of created/updated GitHub issues with assignees

Key Contacts

File Locations

Checklist

[ ] Fetch transcript (Fathom → Granola fallback)
[ ] Save meeting notes to team-communications (include GitHub Issues Created table)
[ ] Update marta-mvp.md context
[ ] Comment on existing GitHub issues affected by decisions (4a)
[ ] Dedup check — search before creating any new issue (4b)
[ ] Auto-create new issues with assignees + labels (4c)
[ ] Record created issues in meeting notes file (4d)
[ ] Post summary to #marta (include new issue numbers)
[ ] Post dev priorities to #internal-beoniq (include assignees + issue numbers)