Build a founder personal brand that books calls, not just views

# PROJECT: PERSONAL AI CONTENT INTELLIGENCE SYSTEM

You are my technical implementation partner. I am a non-technical founder and marketer. I do not want to learn programming or manually operate complicated tools.

Your job is to BUILD a working system on my computer that converts my Fathom meeting recordings and transcripts into a searchable, contextual Idea Bank in Obsidian.

Do not stop at explaining the architecture, writing a plan, or generating sample code. Inspect the environment, implement the system, test it, and help me get it running. You should do as much of the work as your available permissions allow.

Explain any action you need from me in simple, non-technical language. Ask me only for information, account access, or approvals that are genuinely necessary.

## 1. THE OUTCOME

I want a personal AI system that automatically:

1. Retrieves new meeting transcripts from Fathom.
2. Saves the original transcripts and meeting metadata as Markdown files.
3. Understands the meeting using my personal, professional, business, and client context.
4. Extracts strong content ideas, opinions, stories, lessons, examples, frameworks, and useful quotes.
5. Stores each idea as an individual Markdown file in my Obsidian vault.
6. Updates relevant company, client, project, and personal context when new information is discussed.
7. Tracks action items, decisions, commitments, and follow-ups.
8. Identifies patterns across different meetings rather than looking at every call in isolation.
9. Creates a daily digest containing the best new insights, content opportunities, changes, and pending actions.
10. Runs automatically every morning without requiring me to manually execute commands.

I want this to work in the background. My job should be to review useful ideas, approve content, and act on important follow-ups.

## 2. TECHNICAL APPROACH

Preferred stack:

- Fathom: source of meeting transcripts and recordings.
- Claude Code: implementation, processing logic, and AI-assisted analysis.
- Obsidian: my knowledge base, stored as ordinary Markdown files.
- Fathom's official API or supported webhooks: meeting retrieval.
- A reliable local scheduler or supported hosted scheduler: recurring automation.
- A secure way to store credentials.

Do not introduce n8n, Supabase, a custom web application, or unnecessary paid services unless you can demonstrate that a specific requirement cannot be met with the simpler approach.

First inspect my computer and determine:
- Whether Claude Code is working.
- Whether Obsidian is installed.
- Whether I already have an Obsidian vault.
- Whether the necessary tools are installed.
- Whether a suitable Fathom API integration is available.
- Whether the computer can run scheduled tasks reliably.

Use official documentation to verify current API capabilities and authentication requirements. Do not assume an endpoint, API field, webhook event, or permission exists without checking.

Prefer the simplest architecture that is reliable, secure, and maintainable.

If an existing vault is available, use it rather than creating a competing knowledge base. Never overwrite or reorganize my existing notes without permission.

## 3. FATHOM INGESTION

Connect to my Fathom account through its supported API or webhook functionality.

The system must:

- Retrieve all accessible new meetings and their transcripts.
- Retrieve historical meetings when I approve a backfill.
- Preserve meeting titles, dates, participant names, transcript text, speaker attribution, timestamps, summaries, and recording links wherever available.
- Save the original transcript before attempting AI extraction.
- Handle pagination and long transcripts.
- Detect duplicate meetings using stable Fathom meeting IDs.
- Retry temporary failures without creating duplicate records.
- Keep a processing log.
- Allow failed meetings to be processed again.
- Never silently discard a transcript.
- Distinguish a missing transcript from an empty transcript.
- Respect account permissions and any API limits.

Do not scrape private pages or bypass authentication. If an API limitation prevents a feature, explain the limitation and offer the simplest supported alternative.

For historical import, start with a small sample. Show me the result before processing my entire archive.

## 4. OBSIDIAN VAULT STRUCTURE

Create the following structure inside my existing vault, or create a new vault only if necessary and approved.

00 Dashboard/
- Daily Dashboard.md
- System Status.md

01 Meetings/
- One original transcript file per meeting.

02 Idea Bank/
- Personal/
- Expertise/
- Social Proof/
- Trending/
- Opinion/
- Stories/
- Frameworks/
- Experiments/

03 Context/
- My Profile.md
- Writing Style.md
- Businesses and Projects.md
- Clients/
- Audience and Content Goals.md
- Good Insight Examples.md
- Current Priorities.md

04 Daily Insights/
- One dated digest per day.

05 Action Items/
- Open Actions.md
- Completed Actions.md

06 Content Pipeline/
- Inbox/
- Approved/
- Drafts/
- Published/

07 System/
- Processing Log.md
- Automation Settings.md
- Error Log.md

Use sensible filenames and Obsidian links between records. Adapt this structure to an existing vault if needed.

Do not create empty files that serve no purpose. Keep the workspace clean and easy to navigate.

## 5. MEETING NOTE FORMAT

Each meeting note should contain:

- Meeting title.
- Date and time.
- Participants.
- Client or project, when identifiable.
- Fathom recording URL.
- Original transcript.
- Summary.
- Important decisions.
- Action items and their owners.
- Commitments and deadlines.
- Questions that remain unresolved.
- Ideas extracted.
- Links to related meetings, projects, people, and idea notes.
- Processing status.

Preserve the original transcript. Never replace the source material with an AI summary.

## 6. IDEA EXTRACTION

Extract individual ideas, not merely meeting summaries.

For every useful idea, create a separate Markdown file with:

- A clear, specific title.
- The underlying idea in plain English.
- The category.
- Why it is interesting or useful.
- The exact supporting quote from the source transcript.
- The speaker and timestamp, when available.
- A link to the original meeting.
- Relevant people, businesses, clients, or projects.
- Potential content angles.
- Suggested platforms: X, LinkedIn, Instagram, or newsletter.
- A confidence score as a rough prioritization signal, not proof of truth.
- A review status.
- Tags and related ideas.
- Any factual verification or privacy concerns.

Use these categories:

PERSONAL
Experiences, failures, lessons, turning points, founder stories, and observations from real life.

EXPERTISE
Practical knowledge, strategies, frameworks, processes, explanations, and professional lessons.

SOCIAL PROOF
Verified results, metrics, experiments, customer outcomes, case studies, and evidence. Never invent or exaggerate numbers.

TRENDING
References to current events, emerging technologies, industry changes, and timely discussions. Verify whether something is actually current before labeling it time-sensitive.

OPINION
Beliefs, disagreements, contrarian takes, predictions, arguments, and strong points of view.

STORIES
Narratives with a situation, conflict, decision, consequence, or lesson.

FRAMEWORKS
Repeatable methods, checklists, mental models, and processes.

EXPERIMENTS
Tests, hypotheses, things tried, results, and lessons learned.

An idea may have multiple tags, but assign one primary category.

## 7. THE MOST IMPORTANT RULE: INSIGHT VERSUS EVENT

I specifically want you to distinguish a genuinely useful insight from a record of something that happened.

An EVENT answers:
- What happened?
- Who attended?
- What did someone do?
- What was discussed?

An INSIGHT answers:
- Why did this happen?
- What does it reveal?
- What is surprising or non-obvious?
- What general principle can someone learn?
- What assumption does it challenge?
- What can another person apply?
- What evidence supports this conclusion?

For example:

Event:
"I spoke to a founder who is struggling to get leads from LinkedIn."

Weak takeaway:
"LinkedIn is important for founders."

Stronger potential insight:
"Founders often judge LinkedIn by follower growth when the more useful question is whether the right buyers are starting conversations."

The stronger version is only valid if the transcript supports that interpretation. Do not attribute an AI-generated conclusion to a speaker as a verbatim quote.

Another example:

Event:
"A client received a large number of impressions on a post."

Weak takeaway:
"The post went viral."

Stronger potential insight:
"The post may have worked because it framed a familiar problem in a way the audience had not considered."

This is a hypothesis until there is evidence about why the post performed.

For each candidate idea, ask:

1. Is it specific?
2. Is it supported by the source?
3. Does it explain something, challenge an assumption, or offer a useful lesson?
4. Is it distinct from generic advice?
5. Could it become a useful piece of content?
6. Is the reasoning genuinely present, or did you invent it?

Score ideas on specificity, novelty, usefulness, evidential support, and content potential.

Do not confuse confidence with insight quality. Keep those assessments separate.

If a call contains no meaningful insight, say so. Do not manufacture ideas just to fill the database.

## 8. MY CONTEXT AND MEMORY

Maintain a useful, organized knowledge base about me, my work, my businesses, and my clients.

When new information appears in a meeting:

- Update the relevant context file.
- Add the source meeting link and date.
- Preserve historical information when facts change.
- Distinguish confirmed facts from hypotheses.
- Avoid duplicating existing context.
- Track changing priorities, commitments, client status, and project developments.
- Do not turn a temporary statement into a permanent preference.
- Flag ambiguous or contradictory information for review.
- Do not infer sensitive personal information.

Maintain a concise current-state summary for efficient processing. Do not feed every historical note into every model request. Retrieve only the context relevant to each meeting and its ideas.

Keep my personal information separate from client information. Do not expose one client's confidential information in another client's context or in public content suggestions.

## 9. WRITING STYLE AND CONTENT GENERATION

Learn my writing style from a historical export of my X/Twitter posts, which I will provide if available.

Use my writing samples to learn:
- Sentence length and rhythm.
- How I open posts.
- My level of directness.
- How I use observations, stories, and opinions.
- How I explain business concepts.
- My vocabulary and natural voice.
- What makes a thought sound authentic rather than generic.

Do not simply copy my old posts. Learn the underlying style.

My preferred writing style:
- Simple language.
- Short sentences.
- Conversational and direct.
- Subtle wit when natural.
- Raw, honest founder perspective.
- Clear opinions backed by reasoning.
- No forced friendliness.
- No generic marketing language.
- No empty motivational advice.
- Avoid phrases like "dive into" and "unleash your potential."
- Avoid unnecessary em dashes.
- Do not exaggerate achievements or make unsupported claims.
- Do not make everything sound polished, corporate, or AI-generated.

For now, the system should extract and organize ideas, not automatically publish content.

It may suggest possible hooks, angles, and formats. Keep complete drafts in a separate review queue, and only generate them when I ask or explicitly enable that feature.

## 10. DAILY AUTOMATION

Every morning, run the following sequence:

1. Retrieve new or newly available Fathom transcripts since the last successful run.
2. Deduplicate and save original transcripts.
3. Extract ideas, decisions, commitments, and action items.
4. Update relevant business, client, project, and personal context.
5. Identify recurring themes across recent meetings.
6. Compare new ideas against existing ideas to reduce duplication.
7. Create a dated Daily Insights file.
8. Update the dashboard and processing log.
9. Report failures clearly.

The daily digest should include:

- The strongest new ideas.
- Why each idea is worth considering.
- Supporting quotes and source links.
- New opinions or stories worth developing.
- Recurring patterns across conversations.
- Important client or project updates.
- New action items, deadlines, and commitments.
- Changes to previously recorded context.
- Ideas requiring verification or human review.
- A short list of recommended next actions.

Prioritize quality over quantity. A short digest with three excellent ideas is better than 30 generic observations.

Schedule this to run every morning at 8 AM local time if the environment supports it.

If a local Mac scheduler is used, explain that the computer may need to be awake and connected to the internet. Do not promise background execution if the machine will be unavailable. Recommend a hosted option only if local scheduling cannot meet the requirement.

Avoid repeatedly processing the entire archive. Track successful runs and use incremental processing.

## 11. HISTORICAL X/TWITTER IMPORT

If I provide an export of my previous posts:

- Import it as a writing reference.
- Preserve original text and available dates.
- Separate original posts from reposts, replies, and threads when the export allows.
- Identify representative examples of my strongest writing.
- Build a concise Writing Style guide from evidence.
- Keep the original archive intact.
- Do not treat old opinions as current beliefs without checking context.

If no export is available, create the writing-style structure and ask me for examples later.

## 12. SECURITY AND PRIVACY

- Never ask me to paste passwords or secret API keys into chat or Markdown files.
- Use secure credential storage, environment variables, or the official authentication flow.
- Never commit credentials to Git.
- Add appropriate secret files to .gitignore.
- Do not upload my entire Obsidian vault to a remote service.
- Send only the necessary transcript and relevant context for each AI task.
- Keep a record of which services receive transcript data.
- Never automatically publish or share confidential meeting content.
- Keep potentially sensitive ideas in review status.
- Do not delete existing files or modify unrelated system settings without my permission.
- Ask before enabling an automation that sends data externally, changes account settings, or incurs a new recurring cost.
- Validate webhook signatures if webhooks are used.
- Respect recording consent, contractual restrictions, and access permissions.

## 13. IMPLEMENTATION METHOD

Work in this order:

PHASE 1: INSPECT
Inspect my computer and relevant project folders. Identify what is already installed and what access is missing.

PHASE 2: PLAN
Create a short implementation plan with the required integrations, any costs, and any decisions that genuinely require my input.

PHASE 3: BUILD THE FOUNDATION
Create the vault structure, templates, context files, and processing logic.

PHASE 4: CONNECT FATHOM
Implement transcript retrieval using verified official API capabilities. Help me authenticate securely.

PHASE 5: PROCESS ONE REAL MEETING
Process one meeting end to end. Show me the transcript file, extracted idea files, context updates, and daily digest. Wait for my feedback before bulk processing.

PHASE 6: IMPROVE QUALITY
Use my feedback to refine the extraction rules. Ensure ideas are grounded in actual statements and that event summaries are not mislabeled as insights.

PHASE 7: BACKFILL HISTORY
Import older meetings in manageable batches, with duplicate detection and recovery from failures.

PHASE 8: AUTOMATE
Configure the daily schedule, logging, retries, and system-status reporting.

PHASE 9: TEST
Test duplicate handling, empty transcripts, long transcripts, API failures, invalid model responses, permission errors, and reruns.

PHASE 10: HAND OVER
Give me a plain-English summary of what works, where my files live, how the daily automation runs, what it costs, and how I can pause or resume it.

## 14. HOW TO WORK WITH ME

I am not a developer.

Do not ask me to manually write code, debug stack traces, or choose between technical implementation details unless absolutely necessary.

Prefer handling technical work yourself. When an action requires me, give me one simple step at a time with the exact screen or button to use.

Do not claim that a feature works until you have tested it.

If a permission, subscription, API limitation, or external account blocks progress, explain exactly what is blocked and what I need to do.

Do not stop after creating files. Continue until the workflow is working or a genuine external dependency prevents further progress.

Start by inspecting my current environment. Then tell me the single most important thing you need from me, if anything, and proceed with all independent work.