# OpenClaw Implementation Prompts

Each prompt below is a self-contained brief you can hand to an AI coding assistant (or use as a project spec) to build that use case from scratch. Adapt the specific services to whatever you already use — the patterns are what matter.

1) Personal CRM Intelligence

Build me a personal CRM system that automatically tracks everyone I interact with, with smart filtering so it only adds real people — not newsletters, bots, or cold outreach.

Data sources:
- Connect to my email (Gmail API or IMAP) and scan the last 60 days of messages.
- Connect to my calendar (Google Calendar API) and scan the last 60 days of events.
- Run this ingestion on a daily cron schedule.

Contact extraction from email:
- Extract sender/recipient email addresses and names from messages.
- Estimate the number of exchanges (back-and-forth threads, not just raw message count): Math.min(Math.floor(totalMessages / 2), threadCount).
- Collect sample subject lines and message snippets for classification.

Contact extraction from calendar:
- Only include meetings with 1-10 attendees (skip large all-hands).
- Only include meetings at least 15 minutes long (skip quick check-ins that are really just reminders).
- Extract attendee names, emails, and the meeting title.

Filtering — this is critical. Most contacts from email are noise. Use a two-stage filter:

Stage 1 — Hard filters (always reject):
- My own email addresses and domains.
- Emails from family or personal contacts I've explicitly excluded (configurable list).
- Contacts already in the CRM or previously rejected.
- Generic role-based inboxes: info@, team@, partnerships@, collabs@, noreply@.
- Marketing/transactional domains matching patterns like: noreply@, tx., cx., mail., email. prefixes.

Stage 2 — AI classification (use a fast, cheap LLM like Gemini Flash or Haiku):
Send the candidate's name, email, exchange count, and sample subject lines/snippets to an LLM with these rules:
- REJECT clearly automated or notification-only senders.
- REJECT if all sample subjects look like newsletters, digests, or automated reports ("weekly roundup", "monthly update", "AI news").
- REJECT cold outreach with low engagement — if exchanges are low relative to total emails, it's one-way pitching.
- REJECT if snippets show repetitive promotional content (product launches, feature announcements, affiliate reports).
- APPROVE only if it looks like a real person with genuine two-way interaction or a meaningful business relationship.
- Higher confidence for real back-and-forth conversations with varied, substantive topics.

Contact scoring (used for ranking, not filtering):
- Base score: 50
- +5 per email exchange (max +20)
- +3 per meeting (max +15)
- +15 if their title matches preferred titles (CEO, Founder, VP, Head of, Engineer, Partner, etc.)
- +10 if they appeared in small meetings (≤3 attendees)
- +10 if last interaction was within 7 days, +5 if within 30 days
- +25 bonus if the person appears in both email AND calendar (stronger signal)
- +10 if they have a recognizable role, +5 if they have a company

For each approved contact, store:
- Name, email(s), company, role/context
- Interaction timeline with dates
- Last-touch timestamp (auto-updated)
- Contact score
- Tags or categories

Learning system:
- Maintain a learning.json config with:
  - skip_domains: domains to always reject (populated over time from rejections)
  - prefer_titles: titles that boost contact scores
  - skip_keywords: subject-line keywords that indicate spam
  - min_exchanges: minimum exchange threshold (default 1)
  - max_days_between: max days since last interaction (default 60)
  - max_attendees: meeting size cap (default 10)
  - min_duration_minutes: meeting length minimum (default 15)
- When I reject a contact, learn from it — add their domain to skip_domains if appropriate.

Deduplication:
- When a new contact is found, check by email, then by name+company combination.
- Merge records rather than creating duplicates.

Semantic retrieval:
- Generate embeddings for each contact record.
- Let me ask natural-language questions like:
  - "Who did I meet from [company] last month?"
  - "When did I last talk to [name]?"
  - "Show contacts I haven't spoken to in 30+ days."

Storage: SQLite with WAL mode and foreign keys enabled.

Notifications: After each ingestion run, send a summary of new contacts, merges, rejections, and any issues.

2) Knowledge Base (RAG) — Save Anything, Recall It Later

Build me a personal knowledge base with RAG (retrieval-augmented generation).

Ingestion — I send a URL or file and the system saves it. It should handle:
- Web articles
- YouTube videos (transcripts)
- Tweets/X posts
- PDFs
- Plain text or notes

Source type detection: Determine the type from the URL pattern or file extension. Classify as: article, video, pdf, text, tweet, or other.

Content extraction with fallback chain — this is important because no single extractor works for every site:
1. For Twitter/X URLs:
   a. Try FxTwitter API (api.fxtwitter.com) — free, no auth needed
   b. Fall back to X API direct lookup
   c. Fall back to web scraping
2. For YouTube URLs:
   a. Pull transcript via YouTube transcript API or yt-dlp
3. For all other URLs (articles, blogs, etc.):
   a. Try a clean text extractor (like Mozilla Readability or similar)
   b. Fall back to Firecrawl or Apify for sites that block simple extraction
   c. Fall back to a headless browser (Playwright/Puppeteer) for JavaScript-heavy pages
   d. Last resort: raw HTTP fetch + HTML tag stripping
- Retry once on transient errors (ECONNRESET, ETIMEDOUT, DNS failures) with a 2-second delay.

Content quality validation — reject bad extractions:
- Minimum 20 characters of content.
- For articles/non-tweets: at least 15% of non-empty lines must be longer than 80 characters (to detect prose vs. navigation menus).
- Total content must be at least 500 characters for non-tweet types.
- Detect error pages by looking for 2+ signals: "access denied", "captcha", "please enable javascript", "cloudflare", "404", "sign in", "blocked", "rate limit".
- Maximum content length: 200,000 characters (truncate beyond this).

Deduplication — two layers:
1. URL-based: Normalize URLs before comparing — strip tracking params (utm_source, utm_medium, utm_campaign, fbclid, igshid, ref, s, t), remove www., normalize twitter.com to x.com, remove trailing slashes and fragments.
2. Content-hash: SHA-256 hash of the cleaned content. Store as a UNIQUE column — reject if the same hash already exists.

Chunking:
- Chunk size: 800 characters per chunk.
- Overlap: 200 characters between chunks.
- Minimum chunk size: 100 characters (append tiny remainders to the last chunk).
- Split on sentence boundaries (regex: /(?<=[.!?])\\s+/).

Embedding generation:
- Use Google gemini-embedding-001 (768 dimensions, free) or OpenAI text-embedding-3-small (1536 dimensions) as fallback.
- Max input: 8000 characters per chunk.
- Process in batches of 10 chunks with 200ms delay between batches.
- Retry failed embeddings 3 times with exponential backoff (1s, 2s, 4s).
- Cache embeddings with an LRU cache (1000 entries).

Storage — SQLite with two tables:
- sources: id, url, title, source_type, summary, raw_content, content_hash (UNIQUE), tags (JSON array), created_at, updated_at
- chunks: id, source_id (FK), chunk_index, content, embedding (BLOB), embedding_dim, embedding_provider, embedding_model, created_at
- Index on chunks(source_id), sources(source_type), sources(content_hash).
- Enable WAL mode and foreign keys with CASCADE deletes.

Concurrency protection: Use a lock file to prevent simultaneous ingestion runs. Check if lock is stale (PID dead or file older than 15 minutes).

Retrieval — When I ask a question:
1. Embed my query using the same embedding provider.
2. Cosine similarity search over all stored chunks. Return top 10.
3. Deduplicate results: keep only the best chunk per source.
4. Sanitize content in results (max 2500 characters per excerpt).
5. Pass top chunks to an LLM: "Answer using only the provided context. Cite which sources you drew from."
6. Return the answer with source references.

3) Content Idea Pipeline (Research → Dedupe → Project Management)

Build a content idea pipeline that researches topics, prevents duplicate ideas, and creates production-ready tasks.

Trigger: I describe a topic idea in chat.

Step 1 — Research:
- Search X/Twitter for recent discourse on the topic (use the tiered approach from Use Case #4 if built).
- Search my knowledge base (Use Case #2) for related saved content.
- Optionally run a web search.

Step 2 — Semantic dedupe (this is the critical gate):
- Maintain a database of all past content ideas with these fields:
  - id (format: YYYY-MM-DD-NNN)
  - date, type (short/long-form), title, slug (URL-friendly, UNIQUE)
  - summary (the pitch text)
  - tags (comma-separated)
  - status: pitched, accepted, rejected, produced, duplicate
  - response (my feedback)
  - embedding (BLOB — generated via Gemini or OpenAI)
  - created_at

- When a new idea comes in, run a hybrid similarity search:
  - Semantic similarity (70% weight): Cosine similarity between the new idea's embedding and all stored embeddings.
  - Keyword matching (30% weight): Match against title (30%), summary (20%), and tags (20%).
  - Combined score: (semantic × 0.7) + (keyword × 0.3)

- Hard gate: If any existing idea scores above 40% combined similarity, REJECT the new idea. Show me what it matched and the similarity score. No exceptions — this prevents re-pitching old concepts.

Step 3 — Brief assembly (only if it passes dedupe):
- Keep it short — a few sentences on the angle and why it's video-worthy.
- Do NOT generate titles, thumbnails, hooks, or scripts unless I explicitly ask.
- Include links to relevant tweets or KB sources from the research step.

Step 4 — Create task:
- Create a task in my project management tool (Asana, Linear, Notion, or Todoist) with the brief as the description.

Step 5 — Store the idea:
- Add the new idea + its embedding to the pitch database so future ideas are compared against it.
- Set initial status to "pitched".

Step 6 — Notify me with the brief and a link to the created task.

Build a social media research tool that answers "What are people saying about [topic]?" using X/Twitter, while minimizing API costs.

Query decomposition:
- Take my question and break it into 2-4 focused search queries covering different angles.

Tiered retrieval — always try the cheapest option first:
- Tier 1 (free): FxTwitter API (api.fxtwitter.com) — works for individual tweet lookups, no auth needed.
- Tier 2 (low-cost, ~$0.15/1K tweets): A paid Twitter data provider like TwitterAPI.io or SocialData. Supports search, profiles, user tweets, and thread context.
- Tier 3 (expensive, ~$0.005/tweet): Official X API v2 (api.x.com/2). Last resort only. Rate limit to 350ms between requests to stay under 450 req/15min.

How the tiers cascade by operation:
- Single tweet lookup: Tier 1 → Tier 2 → Tier 3
- Search: Tier 2 → Tier 3
- Profile lookup: Tier 2 → Tier 3
- Thread expansion: Tier 2 → Tier 3

Filtering:
- Filter by timeframe (default: last 7 days, configurable).
- Rank by engagement (likes + retweets + replies).
- Remove retweets and duplicate content.
- Suppress low-quality or spam results.

Thread expansion: For high-engagement tweets that are part of a thread, pull the full thread.

Caching: Cache results with a 1-hour TTL so repeated queries don't burn API credits.

Usage logging: Log every API call to a separate log file per tier, with timestamps and estimated costs.

Output — synthesize into a briefing:
- Key narratives: 3-5 dominant takes
- Notable posts: 5-10 most relevant tweets with links
- Sentiment summary: positive, negative, or mixed
- Contrarian takes: interesting minority opinions

5) YouTube Analytics + Competitor Tracking

Build a YouTube analytics system that tracks my channel daily and monitors competitors.

My channel — collect these metrics daily via YouTube Data API and YouTube Analytics API:
- views (total and per-video)
- estimatedMinutesWatched (watch time)
- averageViewDuration
- subscribersGained
- impressions and CTR (if available via Analytics API)

Store each day's metrics in a SQLite table:
- daily_stats: video_id, date, views, watch_time_minutes, avg_view_duration, impressions, ctr, subscribers_gained
- videos: id, title, published_at, thumbnail_url, duration_seconds

Derived metrics:
- 7-day moving average for daily views
- Subscriber-to-view conversion rate
- Views-per-video trend

Competitor tracking:
- Accept a configurable list of competitor channel IDs/usernames.
- Daily, pull each competitor's recent uploads (title, publish date, views) and subscriber count via YouTube Data API.
- Track upload cadence and momentum.

Chart generation — produce PNG charts using matplotlib (dark theme):
1. "trend" chart: Daily view trend for a specific video (line chart with fill area)
2. "top" chart: Top N videos by views (horizontal bar chart, color-coded by short vs long-form)
3. "daily" chart: Channel-wide daily views with 7-day moving average overlay
- Format numbers with commas, dates as readable labels, include grid and legends.
- Save charts to a designated output folder.

Schedule: Daily cron job collecting all data. Optional daily summary sent to chat.

6) Nightly Business Briefing (Multi-Perspective AI Council)

Build a nightly business analysis system that collects signals from across my tools and produces prioritized recommendations using a multi-persona AI review council.

Signal collection — pull data from whatever systems you use. Normalize each signal into:
{ source, signal_name, value, confidence (0-100), direction (up/down/flat), category }

Example sources: YouTube metrics, CRM health, project management backlog, social growth, email themes, meeting action items, sales pipeline, operations/cron reliability.

Compact to the top 200 signals by confidence score, with up to 4 sample events per source.

Three-phase AI review council (all phases use a frontier model like Claude Opus or GPT-4):

Phase 1 — Draft (LeadAnalyst):
- Score business outlook on weekly and monthly horizons (0-100), plus a blended average.
- Generate 5-10 recommendations, each with: title, description (2-3 plain sentences), evidence references, estimated impact (0-100), estimated effort (0-100), confidence (0-100).
- Constraints: use only provided data, no made-up facts, plain human language, don't recommend publishing content immediately.

Phase 2 — Parallel review (4 personas, run simultaneously via Promise.all):
1. GrowthStrategist: Scalable growth, asymmetric upside. Demands concrete evidence.
2. RevenueGuardian: Near-term revenue and cash flow. Challenges anything that doesn't protect income.
3. SkepticalOperator: Execution reality, data quality risks. Challenges weak assumptions.
4. TeamDynamicsArchitect: Team health, collaboration quality, sustainable pace.

Each reviewer:
- Critiques every recommendation: support, revise, or reject (with score adjustments)
- Can propose new recommendations the draft missed
- Returns: reviewer_name, key_findings[], votes[] (with adjusted scores), new_recommendations[]

Phase 3 — Consensus (CouncilModerator):
- Receives draft + all 4 reviews.
- Reconciles disagreements.
- Produces final recommendation set with consensus notes.

Fallback: If consensus fails, use draft recommendations. If a reviewer fails, substitute a stub review with the error message.

Ranking — score each recommendation:
priority = (impact × w1) + (confidence × w2) + ((100 - effort) × w3)
Default weights: w1=0.4, w2=0.35, w3=0.25. Store weights in a policy table and update via feedback over time.

Filter: Remove any "publish now" recommendations (hard constraint).

Output: Deliver ranked recommendations to my preferred channel. Store full council trace (draft, all reviews, consensus, models used) in a database for auditing and backtesting.

Schedule: Run nightly via cron.

7) CRM/Business Tool Natural Language Access

Build a natural-language interface to my CRM (HubSpot, Salesforce, or whatever I use).

Supported objects and operations:
- Contacts: search, create, update, list, get by ID
- Companies: search, create, update, list
- Deals: search, create, update, list, query by pipeline stage
- Owners: list
- Associations: link contacts to companies, deals to contacts, deals to companies
  (For HubSpot, common association type IDs: 1=Contact→Company, 3=Deal→Contact, 5=Deal→Company)
- Properties/schema: inspect available fields for any object

Intent classification — parse my message into:
1. Lookup: "Find the contact for [name]" → search contacts
2. Create: "Add a new contact: [name], [email], [company]" → create contact
3. Update: "Update [contact]'s title to [new title]" → update contact
4. List: "Show all deals in negotiation stage" → filter deals
5. Associate: "Link [contact] to [company]" → create association

Validation: If I'm missing required fields, ask me before proceeding.

Response format: Return clean, readable summaries — not raw JSON. For deal queries, include: deal name, amount, stage, close date, last modified.

Authentication: API key or OAuth stored in environment variables.

8) AI Content Humanization

Build a text rewriting tool that removes AI-generated artifacts and makes content sound like a real person wrote it.

Input: I paste draft text (social posts, blog paragraphs, emails, video scripts).

Step 1 — Detection. Scan for common AI tells:
- Overuse of: "delve", "landscape", "leverage", "it's important to note", "in conclusion", "game-changing", "revolutionary", "transformative"
- Tone inflation: dramatic language when the subject doesn't warrant it
- Generic phrasing that could apply to any topic
- Repetitive sentence structures (every sentence starting the same way)
- Excessive hedging: "It's worth noting that perhaps..."
- Lists that feel generated (too clean, too parallel, no personality)
- Identical paragraph lengths and rhythms

Step 2 — Rewrite:
- Replace vague qualifiers with specific, concrete language
- Vary sentence length (mix short punchy sentences with longer ones)
- Use contractions, sentence fragments, and informal word choices where natural
- Remove filler while keeping the core message
- Add the kind of imperfections real writing has — not errors, but human cadence

Step 3 — Channel tuning (optional, based on destination):
- Twitter/X: Punchy, under 280 chars, direct, no filler
- LinkedIn: Professional but conversational, authoritative without being stiff
- Blog: Longer form, personal anecdotes and opinions welcome
- Email: Brief, clear, action-oriented, warm but efficient

Output: Return the revised text. Optionally highlight what changed and why.

9) Image Generation + Iterative Editing

Build an image generation workflow where I describe what I need in chat and iterate until it's right.

Core flow:
1. I describe an image: subject, style, composition, mood, colors, any text to include.
2. Generate 1-3 variants using an image generation API (DALL-E 3, Midjourney API, Stable Diffusion, or Flux).
3. I review and either:
   a. Accept → save as final asset
   b. Request changes → I describe adjustments ("darker background", "remove text", "more minimal") and it generates new variants incorporating my feedback
4. Loop continues until I'm satisfied.

Image editing:
- I can send an existing image and ask for edits: swap background, adjust composition, combine multiple images.
- Use inpainting or img2img when available.

Context tracking: Remember what we've been working on across multiple messages in the same session so I don't have to re-describe the whole concept each iteration.

Output: Save final assets to a designated folder. Deliver as downloadable files in chat.

10) Task Management from Meetings + Chat

Build a system that extracts action items from meetings and conversations, gets my approval, then creates tasks in my task manager.

Input sources:
- Meeting transcripts from Fathom, Otter.ai, Fireflies, or any transcript provider
- Notes I paste into chat
- Direct commands: "Add a task to follow up with [person] by Friday"

Extraction — use an LLM (Gemini Flash or similar fast model) to parse transcripts and extract:
- description: what needs to be done (max 150 characters, clear and actionable)
- assignee: who is responsible (name as it appears in the transcript)
- is_owner: boolean — is this MY action item or someone else's?
- todoist_title: clean task title (max 120 chars) — only generate this for items where is_owner is true
- Do NOT extract vague items like "think about X" — only concrete actions with a clear next step.

CRM cross-reference (if you have Use Case #1 built):
- Match mentioned people against CRM contacts to enrich with company/role context.

Approval flow — this is important, don't auto-create tasks:
1. Show me the extracted task list with each item numbered.
2. Let me choose: "all", "none", or specific items by number (e.g. "1, 3, 5").
3. Let me edit any task before confirming (change title, priority, due date).
4. Only after I approve, create the tasks via the Todoist/Asana/Linear API.
5. If any task creation fails, keep it in a pending state for retry.

Direct task creation:
- When I say "remind me to [thing] by [date]", skip extraction and create directly after confirming.

Output: Send confirmation with links to created tasks. Persist approval state so I can check what's pending.

Default project: Configure a default project/list for tasks (e.g. "Work" or my company name).

11) AI Usage and Cost Tracking

Build a logging and reporting system that tracks every AI API call and provides cost visibility.

Logging — wrap every LLM/AI API call with a logger that records this structure (one JSON object per line in a JSONL file):
{
  "timestamp": "ISO8601",
  "model": "model-name",
  "tokens": { "input": number, "output": number, "total": number },
  "taskType": "string (e.g. crm-ingestion, x-research, image-gen, business-analysis)",
  "description": "string (brief note on what this call was for)",
  "costEstimate": number,
  "source": "tracker-name"
}

Cost calculation — use a pricing lookup table (per 1M tokens, input/output):
- Anthropic: Opus ($15/$75), Sonnet ($3/$15), Haiku ($0.80/$4)
- OpenAI: GPT-4 ($30/$60), GPT-4 Turbo ($10/$30), GPT-3.5 Turbo ($0.50/$1.50), o1 ($15/$60)
- Google: Gemini Pro ($10/$30), Gemini Flash ($0.30/$1.20), Gemini 1.5 Pro ($1.25/$5)
- xAI: Grok ($2/$10)
- Default for unknown models: $1/$3
- Formula: (inputTokens / 1M) × inputPrice + (outputTokens / 1M) × outputPrice
- Keep this table in a config file so it's easy to update when pricing changes.

Storage: Append-only JSONL file. Optionally mirror to SQLite for faster querying.

Reporting — generate on demand with filters (--days N, --model X, --task-type Y):
1. Overall summary: total calls, total tokens (input/output/total), total cost
2. By model: calls, tokens, cost — sorted by cost descending
3. By task type: calls, tokens, cost — sorted by cost descending
4. By day: last 10 days showing calls, tokens, and cost per day
5. Trend: daily or weekly spending over the last 30/90 days

Routing suggestions:
- Flag any task type where a frontier model (Opus, GPT-4) is being used but the task is simple (short inputs, formatting-only, data extraction) — suggest downgrading to a cheaper model.
- Flag workflows that account for >25% of total spend as optimization candidates.
- Suggest caching strategies for repeated queries (especially research workflows).

Output: Markdown report or simple web dashboard. Optionally send weekly cost summary to my chat.

Here are focused, ready-to-run prompts you can paste into an AI coding assistant to implement each OpenClaw use case as a concrete code project (TypeScript or Python). Each is scoped to one use case and assumes a local, self-hosted stack (SQLite, cron, env-based secrets).

You can ask me next: “Refine #N for Python FastAPI + SQLite-vec” or “Refine #N for Node/TypeScript + Prisma” and we’ll harden one into a full spec.

1) Personal CRM Intelligence — Implementation Prompt

You are a senior backend engineer. Implement a local-first personal CRM ingestion + scoring service with the following requirements:

Tech stack and basics:

Use either: (a) Python 3.11 + FastAPI + SQLAlchemy, or (b) Node 20 + TypeScript + Express + Prisma.
Persistence: SQLite database file personal_crm.db with WAL mode and foreign keys enabled.
All secrets (Gmail, Google Calendar, LLM API keys) from environment variables.
Provide a minimal CLI wrapper (e.g. python -m app ingest or node cli.js ingest) for cron.

Data sources and ingestion:

Email:
- Integrate with Gmail via Gmail API or IMAP (configurable via env).
- Scan the last 60 days of messages.
- Extract: thread id, message id, date, sender, recipients, subject, snippet/body preview.
- For each contact candidate, compute:
  - total_messages in threads involving that email.
  - thread_count involving that email.
  - exchange_count = Math.min(Math.floor(total_messages / 2), thread_count).
Calendar:
- Integrate with Google Calendar API.
- Scan the last 60 days of events.
- Only include meetings with 1–10 attendees and duration ≥ 15 minutes.
- Extract: start/end times, attendees (name + email), title.

Filtering (two-stage):

Stage 1 — hard filters:

Maintain learning.json config file with:
- skip_domains: string[]
- prefer_titles: string[]
- skip_keywords: string[]
- min_exchanges: number (default 1)
- max_days_between: number (default 60)
- max_attendees: number (default 10)
- min_duration_minutes: number (default 15)
Always reject:
- My own email addresses/domains (config: own_emails[], own_domains[]).
- Emails in an explicit skip_contacts[] list.
- Contacts already in CRM or previously rejected.
- Generic inboxes: addresses starting with info@, team@, partnerships@, collabs@, noreply@.
- Domains or local parts matching marketing patterns: prefixes noreply., tx., cx., mail., email..
- Contacts with exchange_count < learning.min_exchanges.

Stage 2 — LLM-based classification:

For each remaining candidate, call a cheap LLM (Gemini Flash / Claude Haiku / GPT-4o-mini is fine; make the provider pluggable).
Prompt input fields:
- name
- email
- exchange_count
- list of sample subject lines (up to 5)
- short snippets/body previews (up to 5)
LLM must respond with strict JSON: { "decision": "APPROVE" | "REJECT", "reason": "string" }.
Apply rules:
- REJECT clearly automated or notification-only senders.
- REJECT if all sample subjects look like newsletters/digests/reports.
- REJECT cold outreach with low engagement (many one-way promos, low replies).
- REJECT repetitive promo content (product launches, features, affiliate reports).
- APPROVE only for genuine, two-way or meaningful relationships.
Treat malformed JSON from the LLM as REJECT with logged warning.

Contact model, scoring, and dedupe:

Database schema (simplified, adjust types to ORM):

contacts:
- id (PK)
- name
- primary_email
- emails (JSON array of strings)
- company
- role
- context (short free-text)
- last_touch_at (datetime)
- contact_score (integer)
- source_flags (JSON: { email: boolean, calendar: boolean })
- tags (JSON array of strings)
- created_at, updated_at
interactions:
- id (PK)
- contact_id (FK → contacts.id)
- kind ("email" | "meeting")
- external_id (e.g. Gmail thread ID or Calendar event ID)
- occurred_at (datetime)
- metadata (JSON)
rejections:
- id (PK)
- email
- reason
- domain
- llm_reason
- created_at
Add indexes on contacts.primary_email, contacts.name, and interactions.contact_id.

Deduplication rules:

When adding or updating a contact:
- First search for an existing contact by exact primary_email.
- If not found, search by any email in emails array.
- If still not found, search by name + company combination (case-insensitive).
- Merge records rather than creating duplicates:
  - Union of email sets.
  - Update last_touch_at to max of all.
  - Merge tags and source flags.
For rejections, track domain for each entry; when I explicitly reject a contact later (via some admin UI or CLI), add their domain to learning.skip_domains if it’s not my own domain.

Contact scoring (at each ingestion run, recompute):

Base score: 50.
+5 per email exchange (max +20).
+3 per meeting (max +15).
+15 if title matches learning.prefer_titles (e.g., "CEO", "Founder", "VP", "Head of", "Engineer", "Partner" — seeded defaults).
+10 if they appeared in small meetings (≤3 attendees) at least once.
Recency bonus:
- +10 if last_touch_at within 7 days.
- +5 if within 30 days.
+25 if person appears in both email and calendar.
+10 if they have a recognizable role (non-empty) and +5 if company is non-empty.

Semantic retrieval:

Create an embeddings table:
- contact_embeddings:
  - contact_id (PK, FK → contacts.id)
  - embedding (BLOB)
  - embedding_dim (int)
  - provider (e.g. "google", "openai")
  - model
  - updated_at
Generate one embedding per contact from a concatenation of:
- name, emails, company, role, top interaction subjects, and recent interaction snippets; max ~1000 chars.
Use either:
- A vector extension (sqlite-vec) for cosine similarity, or
- Load all embeddings into memory and compute cosine similarity in app code for now.
Add a retrieval function/API that lets me ask:
- “Who did I meet from [company] last month?”
- “When did I last talk to [name]?”
- “Show contacts I haven’t spoken to in 30+ days.”
Implement these via a mix of:
- Semantic similarity over embeddings for free-text queries.
- Simple SQL filters on interactions and contacts.last_touch_at.

Notifications:

After each ingestion run (invoked via CLI), compute:
- new_contacts_count
- merged_contacts_count
- rejected_contacts_count
- any errors
Print a human-readable summary to stdout and optionally send a webhook or email summary (add a simple notifier interface).
Log detailed ingestion stats to a JSONL log file.

Deliverables:

Fully working service with:
- CLI commands:
  - ingest-email
  - ingest-calendar
  - ingest-all (both + scoring + notifications)
- HTTP endpoints (optional but preferred):
  - GET /contacts?query=... (search by text, uses semantic + basic filters)
  - GET /contacts/:id
  - POST /contacts/:id/reject (updates learning.json when appropriate)
Include a short README.md with:
- Setup instructions,
- How to configure Gmail/Calendar,
- Example cron line for daily ingestion.

Use best practices: retry transient API failures, structured logging, and clear separation of providers (email/calendar/LLM) from the domain logic. Use the OpenClaw/OpenAI/Gemini LLM examples and SQLite+vector patterns from SQLite RAG guides as inspiration, but write all code from scratch.¹²³

2) Personal Knowledge Base (RAG on SQLite) — Implementation Prompt

You are a backend/infra engineer. Implement a personal RAG knowledge base with URL/file ingestion, SQLite storage, and embedding-based retrieval:

Tech & storage:

Language: Python 3.11 preferred (FastAPI + Pydantic + SQLAlchemy), but Node 20 + TS is acceptable.
Database: SQLite kb.db with WAL mode and foreign keys.
Two tables:
- sources(id, url, title, source_type, summary, raw_content, content_hash UNIQUE, tags JSON, created_at, updated_at)
- chunks(id, source_id FK, chunk_index, content, embedding BLOB, embedding_dim, embedding_provider, embedding_model, created_at)
Indexes:
- CREATE INDEX idx_chunks_source_id ON chunks(source_id);
- CREATE INDEX idx_sources_source_type ON sources(source_type);
- CREATE UNIQUE INDEX idx_sources_content_hash ON sources(content_hash);

Source type detection:

Accept:
- URLs (web articles, YouTube, Twitter/X, other)
- Files: PDFs, text, markdown.
Classify type by pattern:
- Twitter/X: twitter.com, x.com.
- YouTube: youtube.com, youtu.be.
- PDFs by .pdf extension.
- Else: article or text depending on input.

Content extraction (fallback chain):

For Twitter/X URLs:

Try FxTwitter API (https://api.fxtwitter.com) for tweet text, author, metadata (no auth).¹
If that fails, fall back to official X API (stub provider with env-based token).
If that fails, fall back to HTTP fetch + HTML parsing.

For YouTube URLs:

Try YouTube transcript extraction via:
- Either official YouTube Data API, or
- yt-dlp or similar library to fetch transcript/captions.
Extract: title, transcript text, (optionally) chapters.

For all other URLs:

Try a “readability” style extractor (e.g., Mozilla Readability port, or trafilatura/readability-lxml in Python).
If content is too short or looks like boilerplate, fall back to:
- Firecrawl/Apify API (configure via env) OR a generic scraping provider.
If still failing or JS-heavy, fall back to headless browser (Playwright/Puppeteer) and re-run readability on rendered HTML.
Last resort: raw HTTP fetch + HTML tag stripping.

For files:

PDFs: use a robust PDF text extractor (e.g. pdfminer.six, pymupdf, or pdfplumber).
Plain text / markdown: treat file content as raw_content.

Retries:

For network calls, retry once on transient errors (ECONNRESET, ETIMEDOUT, DNS failures) with ~2-second delay.

Content quality validation:

Reject ingestion if:
- Total content < 20 characters.
- For non-tweets:
  - Total content < 500 characters.
  - Or < 15% of non-empty lines are longer than 80 characters (indicates mostly nav/boilerplate).
- If page text contains at least 2 signals of error: "access denied", "captcha", "please enable javascript", "cloudflare", "404", "sign in", "blocked", "rate limit".
Truncate any content beyond 200,000 characters.

Deduplication:

URL normalization:
- Strip tracking params: utm_*, fbclid, igshid, ref, s, t.
- Normalize www..
- Normalize twitter.com → x.com.
- Remove trailing slashes and fragments.
Content hash:
- Compute SHA-256 of cleaned content.
- Store as content_hash and enforce UNIQUE.
- If a source with same hash exists, skip creating a duplicate.

Chunking:

Chunk size: 800 characters.
Overlap: 200 characters between chunks.
Minimum chunk size: 100 characters; append small remainders to previous chunk.
Split on sentence boundaries using regex (?<=[.!?])\s+.
Store chunk_index starting at 0.

Embedding generation:

Use:
- Google gemini-embedding-001 (768-dim) as primary, or
- OpenAI text-embedding-3-small (1536-dim) as fallback.²³
Max input per chunk: 8000 characters (well above our chunk size).
Process in batches of 10 chunks with 200ms delay between batches to avoid rate limits.
Retry failed embedding calls up to 3 times with exponential backoff (1s, 2s, 4s).
Implement an in-memory LRU cache (size 1000) keyed by (provider, model, content_hash) to avoid re-embedding identical content.

Concurrency protection:

Use a lockfile (e.g. .kb_ingest.lock):
- On ingestion start, create lock with PID and timestamp.
- If lock exists:
  - If PID alive and lock age < 15 minutes → abort new ingestion.
  - If PID dead or lock age ≥ 15 minutes → treat as stale and override.

Retrieval:

HTTP endpoint: POST /query with { "question": string, "max_sources": number }.
Steps:

Embed query with same provider/model as chunks.
Run cosine similarity search over all chunk embeddings: - Either with SQLite-vec / vector extension, or in-memory compute. - Return top 10 chunks.
Deduplicate by source_id: keep best chunk per source.
For each selected chunk, sanitize content to max 2500 characters (center around high-density parts if you want; simple truncation is ok).
Call an LLM (configurable, e.g. local via OpenAI-compatible endpoint) with system prompt: - “You are a helpful assistant. Answer the user’s question using only the provided context chunks. If the answer is not in the context, say you don’t know. For each assertion, cite the source id(s) used.”
Return: - answer (string) - sources array with: - source_id - url - title - source_type - excerpt (chunk content substring)

CLI/HTTP:

Provide:

- CLI: `ingest-url <url>`, `ingest-file <path>`, `query "<question>"`.

- HTTP: `POST /ingest/url`, `POST /ingest/file` (multipart), `POST /query`.

Draw from SQLite RAG implementations that use SQLite-vec / sqlite-ai, but implement your own simplified layer around SQLite for storing BLOB embeddings and doing cosine similarity in app code if the vector extension is not used.³⁴²

3) Content Idea Pipeline — Implementation Prompt

You are implementing a content idea dedupe + task creation pipeline.

Core requirements:

Language: Python 3.11 or Node 20 + TS.
Storage: SQLite content_ideas.db.
External systems (optional adapters):
- X/Twitter search via some data provider.
- Personal KB (Use Case #2) via HTTP API.
- Project management tool (Asana / Linear / Notion / Todoist) via env-configured adapter.

Schema:

ideas:
- id (TEXT, PK, format YYYY-MM-DD-NNN)
- date (DATE)
- type ("short" | "long")
- title (TEXT)
- slug (TEXT, UNIQUE, URL-friendly; kebab-case from title or short pitch)
- summary (TEXT) — the pitch text user provides (plus minimal system edits).
- tags (TEXT, comma-separated)
- status ("pitched" | "accepted" | "rejected" | "produced" | "duplicate")
- response (TEXT) — my feedback or notes.
- embedding (BLOB)
- embedding_dim (INT)
- created_at (DATETIME)
Add index on status and date.

Trigger / API:

When user submits a new idea via chat or HTTP:
- Input: { idea_text: string, type?: "short" | "long", tags?: string[] }.
- Convert to canonical summary (light rewrite allowed).
- Generate a default title if not provided (short but descriptive).
- Generate a slug (lowercase, hyphenated, dedup by appending -2, -3, etc. if needed).

Step 1 — Research (optional but wired for future):

Given idea_text, run:
- Twitter/X search (if configured): recent tweets, last ~7–30 days.
- Internal KB search (Use Case #2) via HTTP query.
- Optional web search via any provider.
Store research refs (URL + snippet) in a transient structure for the brief, not in DB (or in a side table if needed).

Step 2 — Semantic dedupe (critical gate):

Compute an embedding for idea_text using Gemini/OpenAI.
For all existing ideas:
- Semantic similarity:
  - Cosine similarity between new idea’s embedding and each stored embedding.
  - Normalize semantic score to.
- Keyword matching:
  - Tokenize new idea’s words (simple lowercased terms, remove stopwords).
  - For each existing idea:
    - Title keyword overlap weight 0.3.
    - Summary overlap weight 0.2.
    - Tag overlap weight 0.2.
  - Aggregate keyword score in.
- Combined score:
  - combined = semantic * 0.7 + keyword * 0.3.
Hard rule:
- If any existing idea has combined >= 0.4, reject the new idea as duplicate:
  - Return a response containing:
    - duplicate: true
    - matched_idea_id
    - matched_title
    - matched_summary
    - similarity: combined
  - Do not create a new DB record; instead, log this attempt if desired.

Step 3 — Brief assembly (if passes dedupe):

Generate a short brief:
- 2–4 sentences max.
- Focus on:
  - Angle and why it’s worth producing.
  - Target format (short vs long).
  - Concrete audience benefit.
- Include relevant links from:
  - Tweets found in research.
  - KB sources found in research.
Do not generate titles, hooks, thumbnails, or script unless user explicitly asks.

Step 4 — Task creation:

Implement a TaskManager abstraction with drivers:
- AsanaTaskManager, LinearTaskManager, NotionTaskManager, TodoistTaskManager.
Use env var TASK_MANAGER_PROVIDER to pick one.
Create a task with:
- title: idea title.
- description: generated brief plus research links.
- tags/labels: from tags.
Return the created task URL or ID.

Step 5 — Store idea:

Generate an ID of the form YYYY-MM-DD-NNN:
- Where YYYY-MM-DD is today.
- NNN is a 3-digit sequence for the day (001, 002, …).
Insert into ideas table with:
- status = "pitched".
- embedding and embedding_dim.
Handle uniqueness constraints for slug and id.

Step 6 — Notify:

Respond to the calling client with:
- duplicate: false
- idea_id
- title
- brief
- task_link

Deliverables:

Minimal REST API:
- POST /ideas → dedupe, brief, task creation, store idea.
- GET /ideas/:id
- GET /ideas?status=...
LLM and embedding providers pluggable via config.
Unit tests for the dedupe function with synthetic examples at similarity <0.4, around 0.4, >0.4 to validate behavior.

Base the similarity + embedding logic on established RAG/SQLite vector patterns as in the RAG + SQLite material and adapt to this idea-table schema.²³

11) AI Usage and Cost Tracking — Implementation Prompt

You are implementing a centralized AI usage logger + cost reporter.

Requirements:

Core design:

Provide a small library (Python or Node) that wraps any LLM API call.
For each call, log a JSON object to an append-only JSONL file ai_usage.log.
Provide a small CLI (report) that reads the JSONL (and optional SQLite mirror) and prints cost summaries.

Logging structure:

Each log line is a single JSON object:

{
  "timestamp": "ISO8601",
  "model": "model-name",
  "tokens": { "input": number, "output": number, "total": number },
  "taskType": "string",
  "description": "string",
  "costEstimate": number,
  "source": "tracker-name"
}

timestamp: UTC ISO8601.
taskType: e.g., "crm-ingestion", "x-research", "image-gen", "business-analysis".
source: arbitrary string identifying which wrapper produced this (e.g., "backend-api", "cli-tool").

Cost calculation:

Maintain a config file pricing.json mapping model families to prices per 1M tokens:
- Anthropic:
  - Opus: input 15, output 75
  - Sonnet: input 3, output 15
  - Haiku: input 0.8, output 4
- OpenAI:
  - GPT-4: 30 / 60
  - GPT-4 Turbo: 10 / 30
  - GPT-3.5 Turbo: 0.5 / 1.5
  - o1: 15 / 60
- Google:
  - Gemini Pro: 10 / 30
  - Gemini Flash: 0.3 / 1.2
  - Gemini 1.5 Pro: 1.25 / 5
- xAI:
  - Grok: 2 / 10
- Default: 1 / 3
Implement a function:
- estimateCost(modelName, inputTokens, outputTokens):
  - Normalizes modelName to family (e.g. "gpt-4o-mini" → "gpt-4", "claude-3-opus" → "opus").
  - Uses pricing.json to compute:
    - (inputTokens / 1_000_000) * inputPrice + (outputTokens / 1_000_000) * outputPrice.

Storage:

Always append to ai_usage.log (JSONL).
Optionally mirror to SQLite ai_usage.db:
- logs(id, timestamp, model, input_tokens, output_tokens, total_tokens, task_type, description, cost_estimate, source).
- Provide a flag/env to turn SQLite mirroring on or off.

Reporting CLI:

Command: ai-cost report [--days N] [--model X] [--task-type Y].
Reads JSONL (and optionally SQLite for speed).
Implement filters:
- --days N: only include events from last N days.
- --model X: filter by model substring.
- --task-type Y: filter by exact or prefix match.
Produce reports:

Overall summary: - Total calls, total tokens (input/output/total), total cost.
By model: - Table with: model, calls, input_tokens, output_tokens, total_tokens, cost. - Sorted by cost descending.
By task type: - Same fields, grouped by taskType, sorted by cost.
By day: - Last 10 days, each with date, calls, tokens, cost.
Trend: - Over last 30 and 90 days, compute daily or weekly totals; print as simple text table.

Routing suggestions:

In the report, compute:
- For each taskType:
  - Share of total cost (percentage).
- For each log:
  - If model is a frontier model (Opus, GPT-4 family) AND total_tokens < 2000 AND description looks like formatting-only / extraction (use simple heuristics: contains "format", "extract", "summarize"), flag as candidate for cheaper model.
Output:
- “High-cost workflows (>25% total spend):” — list taskTypes exceeding 25% of total cost.
- “Potential downgrade candidates (frontier model for simple task):” — list sample log lines with suggestion to switch to cheaper model.
- Suggest caching for patterns where:
  - Same taskType + similar description repeated many times; e.g., group by (taskType, normalized description) and show those with high counts.

Integration pattern:

Provide a wrapper function, e.g. for Python:

async def call_llm_with_tracking(client, model, messages, task_type, description, source="backend"):
    # calls client.chat.completions.create(...)
    # reads usage.prompt_tokens, usage.completion_tokens
    # computes costEstimate
    # appends JSONL line
    # returns the original response

Analogous helper in TypeScript.

Draw from JSON logging and cost-tracking patterns seen in existing open-source cost loggers and JSON logging guides.⁵⁶⁷

If you tell me which language + infra you want (e.g., “Python 3.11, FastAPI, sqlite-vec, Gemini + OpenAI mix”), I can turn any one of these into a fully wired starter repo spec with directory layout, key modules, and a first-pass schema + migration script. ⁸⁹¹⁰¹¹¹²¹³¹⁴¹⁵¹⁶

⁂

were all of the prompts expanded?

No.

In my last message I only expanded three of your eleven specs into implementation prompts:

1. Personal CRM Intelligence
1. Knowledge Base (RAG)
1. AI Usage and Cost Tracking

Use cases 3, 4, 5, 6, 7, 8, 9, 10 are still in their original form and haven’t been turned into detailed “hand this to a coding agent” prompts yet.¹⁷ ¹⁸¹⁹²⁰²¹²²²³²⁴²⁵²⁶²⁷²⁸

⁂

EXPAND Use cases 3, 4, 5, 6, 7, 8, 9, 10

Here are focused, implementation-ready prompts for Use Cases 3–10 that match the style of the ones you already have. Each is self-contained so you can drop it into a coding assistant.

3) Content Idea Pipeline — Implementation Prompt

You are a senior backend engineer. Implement a content idea pipeline service that researches topics, dedupes ideas, and creates tasks in a PM tool.

Tech & storage:

Language: Python 3.11 (FastAPI + SQLAlchemy) or Node 20 + TypeScript (Express + Prisma).
Database: SQLite content_ideas.db.
All external API keys from env vars.

Schema:

Table ideas:
- id TEXT (PK, format YYYY-MM-DD-NNN).
- date DATE.
- type TEXT ("short" | "long").
- title TEXT.
- slug TEXT UNIQUE (URL-friendly kebab-case).
- summary TEXT (pitch text).
- tags TEXT (comma-separated).
- status TEXT ("pitched" | "accepted" | "rejected" | "produced" | "duplicate").
- response TEXT (my feedback).
- embedding BLOB.
- embedding_dim INT.
- created_at DATETIME.
Indexes on date, status, and slug.

Step 0 — API surface:

HTTP endpoint POST /ideas/preview:
- Input: { idea: string, type?: "short" | "long", tags?: string[] }.
- Returns either a duplicate rejection or a “passes dedupe” brief + recommended task payload.
HTTP endpoint POST /ideas/commit:
- Input: { idea: string, type?: "short" | "long", tags?: string[], overrideDuplicate?: boolean }.
- Performs same logic as preview, but if not duplicate (or override true), creates DB row and PM task.

Step 1 — Research:

Given the idea text:
- If configured, call an X/Twitter search provider (stub compatible with an OpenClaw “x-search” skill).²⁹
- Query the KB service from Use Case #2 over HTTP with the idea text as query.
- Optional: simple web search provider wrapper with search(query) → [{title, url, snippet}].
Capture research results in memory:
- tweets: [{url, text}]
- kb_sources: [{id, url, title}]
- web_results: [{title, url}]
Do not persist research by default; it is referenced only in the brief and task body.

Step 2 — Semantic dedupe:

Generate an embedding for the new idea using a pluggable embedding provider (Gemini or OpenAI; same abstraction as RAG KB).³⁰³¹
For all existing ideas:
- Semantic similarity:
  - Load embeddings into memory and compute cosine similarity in.
- Keyword similarity:
  - Tokenize idea text into normalized terms.
  - For each existing idea, compute:
    - Title overlap score (0–1) × 0.3.
    - Summary overlap score (0–1) × 0.2.
    - Tag overlap score (0–1) × 0.2.
  - Aggregate to keyword score in.
- Combined:
  - combined = semantic * 0.7 + keyword * 0.3.
Hard gate:
- If any idea has combined >= 0.4, treat this as duplicate:
  - Return JSON:
    - duplicate: true
    - matched: { id, title, slug, similarity: combined, status }
    - explanation: string.
  - Do not insert into DB unless overrideDuplicate is true on /commit.

Step 3 — Brief assembly (if not duplicate):

Generate a concise brief:
- 2–4 sentences, no title/hook/script.
- Explain:
  - The angle.
  - Why it’s worth producing.
  - Ideal format (short vs long).
- Include bullet list of relevant links:
  - Selected tweets URLs.
  - KB source URLs.
Ensure the brief is plain text / markdown-safe.

Step 4 — Task creation:

Implement TaskManager abstraction with drivers:
- AsanaTaskManager, LinearTaskManager, NotionTaskManager, TodoistTaskManager.
Choose provider via TASK_MANAGER=asana|linear|notion|todoist env var.
For passing ideas, create a task:
- title: idea title.
- description: the brief + related links.
- labels/tags: mapped from tags.
Return task_url or ID from provider.

Step 5 — Store idea:

Generate ID:
- YYYY-MM-DD = today.
- NNN = zero-padded daily sequence (001, 002, …) for that date.
Ensure slug uniqueness (append -2, -3, … on conflict).
Insert into ideas with:
- status = "pitched".
- embedding and embedding_dim.
- tags stored as comma-separated list.
On duplicate override, set status = "pitched" and optionally store the matched original in response.

Step 6 — Notify:

Response from /commit:
- If duplicate: 409-style JSON with match info.
- If new:
  - id, slug, title, status, task_url.

Implement tests for the dedupe function with synthetic examples around the 0.4 threshold.³²³³

You are a backend engineer. Implement a cost-optimized X/Twitter research service that answers “What are people saying about [topic]?” with tiered API usage.

Tech & config:

Language: Python 3.11 or Node 20 + TS.
No DB required initially; cache files in local disk (optionally SQLite if cheaper).
Config via env:
- Tier 2 provider API key (e.g. TwitterAPI.io/SocialData).
- Tier 3 official X API credentials.
- Cache directory.

Tiered providers:

Tier 1: FxTwitter API for single-tweet lookups (no auth).²⁹
Tier 2: Paid provider:
- Must support search, profile lookup, user tweets, and thread expansion.
Tier 3: Official X API v2:
- Use as fallback with rate limiting (≥350ms between requests).

Query decomposition:

Input: a natural language question.
Use a lightweight LLM or rules to break into 2–4 sub-queries:
- Different angles: e.g., “use cases”, “criticisms”, “open source alternatives”.
Enforce:
- Limit total queries to max 4.
- Deduplicate very similar sub-queries.

Core operations:

Single tweet lookup:
- Try Tier 1 → if fail/blocked/incomplete, Tier 2 → then Tier 3.
Search:
- Tier 2 → Tier 3.
Profile lookup:
- Tier 2 → Tier 3.
Thread expansion:
- For high-engagement tweets (e.g. top 10 by engagement), expand thread via Tier 2 → Tier 3.

Filtering and ranking:

Filter by timeframe:
- Default last 7 days; allow overridable param.
Remove:
- Retweets (keep original).
- Exact-duplicate texts.
Compute engagement score:
- engagement = likes + retweets + replies (adjust fields to provider schema).
Basic spam filtering:
- Drop tweets with:
  - Suspicious repetition (same link + template text).
  - Very low engagement in combination with promotional keywords ("giveaway", "promo", "discount", etc.).
Keep a final set of ~30–100 tweets for synthesis.

Caching:

Cache search results by normalized query + timeframe:
- Key: hash of (query, timeframe).
- Store: tweets JSON + timestamp.
- TTL: 1 hour.
- If cache hit and not expired, return cached tweets instead of re-calling APIs.

Usage logging:

Maintain one log file per tier:
- logs/tier1.log, logs/tier2.log, logs/tier3.log.
Each entry:
- timestamp, tier, operation (search, lookup, thread), params summary, estimated cost.
For Tier 2 and 3:
- Keep approximate cost per call (configurable via env).

Output synthesis:

For a user query:

Decompose question → 2–4 queries.
Run tiered searches with caching.
Collect and filter tweets.
Compute narratives using LLM: - Identify 3–5 key narratives. - Identify sentiment (positive/negative/mixed). - Extract 5–10 notable tweets with links. - Extract 2–3 contrarian or minority takes.

Output JSON:

{
  "narratives": [{ "title": "...", "description": "..." }],
  "sentiment": "positive|negative|mixed",
  "notable_tweets": [{ "url": "...", "text": "...", "engagement": { "likes": 0, "retweets": 0, "replies": 0 } }],
  "contrarian_takes": [{ "url": "...", "text": "..." }]
}

Provide:

POST /social/x/research endpoint:
- Body: { "question": string, "timeframe_days"?: number }.
Configurable logs directory and cache directory. Use the OpenClaw “x-search” skill pattern and cost-optimized search strategies as inspiration, but implement a standalone service.³⁴²⁹

5) YouTube Analytics + Competitor Tracking — Implementation Prompt

You are a data engineer. Implement a YouTube analytics + competitor tracking service with daily metrics and chart generation.

Tech & storage:

Language: Python 3.11.
Use YouTube Data API + YouTube Analytics API.
Database: SQLite youtube_analytics.db.
Charts: matplotlib (dark theme), PNG output.

Schema:

videos:
- id TEXT (YouTube video ID, PK).
- title TEXT.
- published_at DATETIME.
- thumbnail_url TEXT.
- duration_seconds INTEGER.
daily_stats:
- video_id TEXT (FK → videos.id).
- date DATE.
- views INTEGER.
- watch_time_minutes REAL.
- avg_view_duration REAL (seconds or ISO string, pick one and document).
- impressions INTEGER NULLABLE.
- ctr REAL NULLABLE.
- subscribers_gained INTEGER.
- PK: (video_id, date).
competitors:
- channel_id TEXT (PK).
- name TEXT.
competitor_stats:
- channel_id TEXT (FK → competitors.channel_id).
- date DATE.
- subscribers INTEGER.
- video_count INTEGER.
competitor_uploads:
- channel_id TEXT.
- video_id TEXT.
- title TEXT.
- published_at DATETIME.
- views INTEGER.
- PK: (channel_id, video_id).

Data collection (daily cron):

For my channel:
- Input: MY_CHANNEL_ID env var.
- Fetch channel’s videos and maintain videos table (incremental).
- For each day:
  - Use Analytics API to fetch:
    - Views, estimated minutes watched, average view duration, impressions, CTR, subscribers gained.
  - Upsert into daily_stats.
For competitors:
- Config: COMPETITOR_CHANNEL_IDS comma-separated env var.
- For each competitor daily:
  - Fetch subscriber count and video count → competitor_stats.
  - Fetch recent uploads (e.g., last 30 days or last N videos) with title, publish date, views → competitor_uploads.

Derived metrics:

7-day moving average for daily views per video and channel-wide:
- Precompute or compute in queries.
Subscriber-to-view conversion rate:
- subscribers_gained / total_views on a given day or period.
Views-per-video trend:
- Time-series of per-video average views.

Chart generation (matplotlib, dark theme):

Use a dedicated module charts.py with:
- generate_trend_chart(video_id, output_path):
  - Line chart of daily views for the video, fill under the line.
- generate_top_videos_chart(start_date, end_date, top_n, output_path):
  - Horizontal bar chart of top N videos by views in the period.
  - Color-code bars by short vs long-form (e.g., duration <60s).
- generate_daily_channel_chart(start_date, end_date, output_path):
  - Daily total channel views with 7-day moving average overlay.
Formatting:
- Dark background, readable grid and axis labels.
- Numbers formatted with commas, readable date labels.
- Save to designated charts/ directory.

API & CLI:

CLI commands:
- collect-my-channel (daily).
- collect-competitors (daily).
- charts trend <video_id>.
- charts top --start YYYY-MM-DD --end YYYY-MM-DD --top 10.
Optionally, HTTP endpoints:
- GET /videos/top?start=...&end=....
- GET /charts/trend/:video_id (serves PNG).
Schedule via cron externally (e.g., 0 3 * * * python -m yt_analytics collect-my-channel).

Guard for rate limits, use pagination, and log all API errors with enough detail for debugging.³⁵³⁶

6) Nightly Business Briefing (Multi-Perspective AI Council) — Implementation Prompt

You are building an AI council pipeline that turns normalized signals into nightly recommendations.

Tech:

Language: Python 3.11.
LLM provider: configurable (Anthropic, OpenAI, etc.).
Storage: SQLite business_council.db.

Signal ingestion:

Define a JSON structure for signals:

{
  "source": "string",
  "signal_name": "string",
  "value": "number|string",
  "confidence": 0-100,
  "direction": "up|down|flat",
  "category": "string",
  "sample_events": [ ... ]
}

Implement adapters for sources:
- YouTube (from Use Case #5).
- CRM health (from Use Case #1).
- Project management backlog.
- Social metrics, sales pipeline, operations/cron reliability.
Normalize all adapters to this structure and dump into a list nightly.
Trim to top 200 signals by confidence with up to 4 sample events per source.

DB schema:

runs:
- id INTEGER PK.
- run_date DATE.
- status TEXT.
recommendations:
- id INTEGER PK.
- run_id INTEGER FK.
- title TEXT.
- description TEXT.
- evidence TEXT (JSON array of signal refs).
- impact INTEGER.
- effort INTEGER.
- confidence INTEGER.
- priority REAL.
- filtered_out BOOLEAN.
policy:
- id INTEGER PK (single row).
- w1 REAL (impact weight).
- w2 REAL (confidence weight).
- w3 REAL (effort weight).

Phase 1 — Draft (LeadAnalyst persona):

Call a high-end model with:
- System prompt describing LeadAnalyst (weekly/monthly outlook scoring, constraints).
- Input: signals (compact summary) and past 3 runs’ recommendations (optional).
Output (JSON):
- weekly_outlook 0–100.
- monthly_outlook 0–100.
- blended_outlook 0–100.
- recommendations: list of:
  - title, description, evidence_refs, impact, effort, confidence.
Validate and coerce fields into expected ranges.

Phase 2 — Parallel review (4 personas):

Personas:
- GrowthStrategist.
- RevenueGuardian.
- SkepticalOperator.
- TeamDynamicsArchitect.
For each persona, call LLM in parallel with:
- Draft recommendations.
- Signals summary.
- Persona-specific instructions (what to care about, when to reject/change).
Expected JSON per reviewer:
- reviewer_name.
- key_findings: list of strings.
- votes: for each draft recommendation:
  - title, stance (support|revise|reject), adjustments to impact|effort|confidence (optional).
- new_recommendations: zero or more additional recs in same structure as draft.

Phase 3 — Consensus (CouncilModerator persona):

Inputs:
- Draft recommendations.
- All 4 reviews.
LLM output:
- Final normalized recommendation list:
  - For each: title, description, evidence refs, impact, effort, confidence, consensus_notes.
Fallback:
- If consensus call fails, fall back to draft recs.
- If any reviewer fails, treat as stub with error message.

Priority scoring and filtering:

From policy table, load:
- w1 (default 0.4), w2 (0.35), w3 (0.25).
Compute:
- priority = impact * w1 + confidence * w2 + (100 - effort) * w3.
Hard filter:
- Remove recommendations that explicitly say “publish now” or equivalent.
- Detect via simple keyword scan in title/description.
Store final recs in recommendations table.

Output:

Nightly run writes:
- JSON summary file.
- DB entries.
Provide CLI:
- run-council to execute full pipeline.
- show-latest to print ranked recommendations with priority and consensus notes.
Optionally send summary to Slack/Matrix/Telegram via webhook.

Use OpenClaw multi-agent council patterns as conceptual inspiration, but implement as explicit LLM calls with strict JSON schemas.³⁷³⁸

7) CRM/Business Tool Natural Language Access — Implementation Prompt

You are implementing a natural-language interface to a CRM (HubSpot/Salesforce/other).

Tech:

Language: Node 20 + TypeScript or Python 3.11.
Integrate with one CRM first (HubSpot recommended), but keep the interface pluggable.
Authentication: API key or OAuth from env.

Supported objects & operations:

Contacts: search, create, update, list, get by ID.
Companies: search, create, update, list.
Deals: search, create, update, list, query by pipeline stage.
Owners: list.
Associations:
- Contacts ↔ Companies.
- Deals ↔ Contacts.
- Deals ↔ Companies.
- For HubSpot, support association type IDs 1, 3, 5 (configurable).

NL interface:

Expose HTTP POST /crm/nl:
- Input: { "query": string }.
Pipeline:

Intent classification: - Use either rules or an LLM (cheap model) to classify intent: - lookup, create, update, list, associate.
Entity extraction: - Extract object type (contact/company/deal), key fields (name, email, etc.), filters (stage, owner).
Validation: - If required fields missing, respond with clarifying questions instead of hitting CRM.
Execution: - Map to CRM API calls via a CrmClient interface.
Presentation: - Return clean human-readable summaries, not raw JSON.

Examples:

“Find the contact for Jane Doe at Acme” → search contacts with name and company.
“Add a new contact: John Smith, john@foo.com, at FooCorp” → create contact.
“Update Jane Doe’s title to VP Marketing” → search then update.
“Show all deals in negotiation stage” → list deals filtered by stage.
“Link Jane Doe to Acme Corp” → contact-company association.

Response formatting:

Contacts:
- Name, email, phone, company, role, last activity date (if available).
Deals:
- Name, amount, stage, close date, last modified.
Companies:
- Name, domain, owner, lifecycle stage.

Implement:

CrmClient with:
- searchContacts, createContact, updateContact, listContacts, getContactById.
- Similar for companies and deals.
- associateContactCompany, associateDealContact, associateDealCompany.
Intent & extraction using:
- Lightweight LLM call with JSON output (intent + slots), or a robust regex/rule layer plus LLM fallback.

Add:

GET /crm/schema endpoint:
- Lists available fields/properties for each object (via CRM API call).
Error handling and rate limit handling.

Use best practices from typical NL-to-CRM assistants and OpenClaw CRM skills, but implement all adapter code directly against the official CRM REST API.³⁹³⁷

8) AI Content Humanization — Implementation Prompt

You are implementing a text humanizer that rewrites AI-ish text to sound more natural.

Tech:

Language: Python or Node.
Use a single LLM (cheap model) with strong instruction prompt.
Provide a simple HTTP API and CLI.

API:

POST /humanize:
- Input: { "text": string, "channel"?: "twitter" | "linkedin" | "blog" | "email", "explainChanges"?: boolean }.
Output:
- { "rewritten": string, "notes"?: [{ "before": string, "after": string, "reason": string }] }.

Step 1 — Detection:

Implement a detection function that:
- Scans for overused phrases:
  - “delve”, “landscape”, “leverage”, “it’s important to note”, “in conclusion”, “game-changing”, “revolutionary”, “transformative”.
- Looks for:
  - Repetitive sentence beginnings.
  - Excessive hedging (“worth noting that perhaps”, etc.).
  - Too-regular paragraph length or bullet patterns.
- Provide this detection summary to the LLM as context (counts + examples).

Step 2 — Rewrite:

LLM system instructions:
- Replace vague qualifiers with specific, concrete language.
- Vary sentence length and rhythm.
- Use contractions and natural phrasing where appropriate.
- Remove filler, keep core message.
- Keep semantics intact, do not invent facts.
Prompt structure:
- Provide original text.
- Provide detection summary.
- Provide channel and channel guidelines:
  - Twitter: ≤280 chars, punchy, direct.
  - LinkedIn: professional, conversational, no fluff.
  - Blog: relaxed, can include light personal phrasing, but no fake anecdotes.
  - Email: clear, action-oriented, friendly but concise.
- Request JSON output with rewritten and optionally notes if explainChanges is true.

Guardrails:

Never change numbers, dates, or explicit commitments.
Preserve URLs, code blocks, markdown, and hashtags.
If channel is Twitter, ensure length ≤280 chars (count plain text).

CLI:

humanize <file> → prints rewritten text.
humanize --channel=linkedin to tune tone.

Use OpenClaw’s content editing/humanization skills as conceptual reference, but build a focused humanizer with clear IO and detection.⁴⁰⁴¹

9) Image Generation + Iterative Editing — Implementation Prompt

You are implementing an image generation + iterative editing workflow around an image generation API.

Tech:

Language: Node 20 + TS or Python.
Image provider: pluggable (DALL·E, Stable Diffusion API, Flux, etc.).
Storage: local images/ directory; optional metadata DB (SQLite).

Core flow:

Maintain a sessions table (or JSON file) to track context:
- id, created_at, state (JSON with current prompt, style, constraints, history).
API:
- POST /image/start:
  - Input: { "description": string } (subject, style, mood, colors, any text).
  - Creates a new session, generates 1–3 initial variants.
- POST /image/iterate:
  - Input: { "session_id": string, "feedback": string }.
  - Uses previous state + feedback to refine and generate new variants.
- POST /image/edit:
  - Input: { "session_id"?: string, "image_id": string, "instructions": string }.
  - Applies editing (background change, composition, etc.) via img2img/inpainting.

Generation details:

For each generation or edit:

- Save resulting images to disk (`images/<session>/<variant>.png`).

- Store metadata:
    - Prompt used, seed (if exposed), provider/model, parent image (for edits).

Track:
- Final selection:
  - POST /image/accept:
    - Input: { "session_id": string, "image_id": string }.
    - Marks that variant as final in metadata.

Context tracking:

Session state stores:
- Original user description.
- Last accepted or current best prompt.
- A running list of user feedback messages.
When generating new variants:
- Construct a new prompt by combining:
  - Original description.
  - Past constraints.
  - Most recent feedback instructions.

Output:

For each API call returning images:
- Return:
  - session_id
  - array of { image_id, preview_url_or_path }.

Keep provider interface abstract (ImageProvider.generate, ImageProvider.edit) so you can swap DALL·E vs SDXL etc. Later you can plug this into OpenClaw as a skill.⁴²³⁵

10) Task Management from Meetings + Chat — Implementation Prompt

You are building a task extraction and approval system from meeting transcripts and chat.

Tech:

Language: Python 3.11 or Node 20 + TS.
External:
- Transcript input (file upload or webhook).
- Task manager (Todoist / Asana / Linear / Notion), via adapter.

Schema:

SQLite tasks_from_meetings.db:
- extracted_items:
  - id INTEGER PK.
  - source_type TEXT ("meeting" | "note" | "direct").
  - source_id TEXT (e.g., meeting ID or note ID).
  - description TEXT (max 150 chars).
  - assignee TEXT.
  - is_owner BOOLEAN.
  - todoist_title TEXT (for owner tasks).
  - status TEXT ("pending" | "approved" | "rejected" | "created" | "failed").
  - task_external_id TEXT NULLABLE.
  - created_at DATETIME.
  - updated_at DATETIME.

Input sources:

Meeting transcripts:
- Upload endpoint POST /meetings/:id/transcript (raw text or file).
Notes:
- POST /notes with { "text": string }.
Direct commands:
- POST /tasks/direct with { "text": string } (e.g., “remind me to X by Friday”).

Extraction:

Use a fast LLM with explicit JSON schema:
- For transcripts and notes:
  - Ask LLM to produce an array of:

{
  "description": "max 150 chars, concrete",
  "assignee": "string",
  "is_owner": true|false,
  "todoist_title": "max 120 chars or null"
}

- Provide rules:
    - No vague items (“think about”, “discuss later”).
    - Only actionable tasks with clear next step.
    - `todoist_title` only when `is_owner` is true.

Store extracted items with status = "pending".

CRM cross-reference (optional):

If Use Case #1 CRM exists, call it to enrich assignee with company/role, but keep this as optional metadata only.

Approval flow:

GET /tasks/pending → list pending items grouped by source_id.
UX flow (handled by client or CLI, but backend must support):

Show numbered list of tasks.
Accept input indicating: - “all”, “none”, or selected IDs (e.g., [1,3,5]).
Editing: - PATCH /tasks/:id to modify title/description/due date before creation.
Confirm: - POST /tasks/approve with selected ids.

Task creation:

Once approved:
- Call task manager adapter:
  - For Todoist: use REST API to create tasks with title, description, due date, project.
- Update status:
  - created if API success + store task_external_id.
  - failed if API errors; leave for retry.
Retry mechanism:
- Simple CLI or endpoint POST /tasks/retry-failed.

Direct task creation:

For tasks/direct:
- Use a small LLM or parser to extract:
  - Task description.
  - Due date/time (natural language parsing).
- Confirm with user (or parameter autoCreate: boolean).
- Create directly in the task manager (skip extraction pipeline but still log to DB with source_type = "direct").

Output:

When tasks are created, respond with:
- tasks: [{ id, description, status, external_link }].

Take inspiration from OpenClaw meeting-followup automations, but implement a conservative, approval-gated pipeline that never auto-creates tasks without confirmation.³⁷³⁹

If you tell me your preferred base stack (e.g., “Python, FastAPI, SQLite-vec, Gemini + OpenAI”), I can collapse any one of these into a repo layout (folders, key modules, first migrations) tailored to OpenClaw skill integration. ⁴³⁴⁴⁴⁵⁴⁶

⁂

1) Personal CRM Intelligence​

2) Knowledge Base (RAG) — Save Anything, Recall It Later​

3) Content Idea Pipeline (Research → Dedupe → Project Management)​

4) Social Media Research System (Cost-Optimized)​

5) YouTube Analytics + Competitor Tracking​

6) Nightly Business Briefing (Multi-Perspective AI Council)​

7) CRM/Business Tool Natural Language Access​

8) AI Content Humanization​

9) Image Generation + Iterative Editing​

10) Task Management from Meetings + Chat​

11) AI Usage and Cost Tracking​

1) Personal CRM Intelligence — Implementation Prompt​

2) Personal Knowledge Base (RAG on SQLite) — Implementation Prompt​

3) Content Idea Pipeline — Implementation Prompt​

11) AI Usage and Cost Tracking — Implementation Prompt​

were all of the prompts expanded?

EXPAND Use cases 3, 4, 5, 6, 7, 8, 9, 10

3) Content Idea Pipeline — Implementation Prompt​

4) Social Media Research System (X/Twitter, Cost-Optimized) — Implementation Prompt​

5) YouTube Analytics + Competitor Tracking — Implementation Prompt​

6) Nightly Business Briefing (Multi-Perspective AI Council) — Implementation Prompt​

7) CRM/Business Tool Natural Language Access — Implementation Prompt​

8) AI Content Humanization — Implementation Prompt​

9) Image Generation + Iterative Editing — Implementation Prompt​

10) Task Management from Meetings + Chat — Implementation Prompt​

Footnotes​

1) Personal CRM Intelligence

2) Knowledge Base (RAG) — Save Anything, Recall It Later

3) Content Idea Pipeline (Research → Dedupe → Project Management)

4) Social Media Research System (Cost-Optimized)

5) YouTube Analytics + Competitor Tracking

6) Nightly Business Briefing (Multi-Perspective AI Council)

7) CRM/Business Tool Natural Language Access

8) AI Content Humanization

9) Image Generation + Iterative Editing

10) Task Management from Meetings + Chat

11) AI Usage and Cost Tracking

1) Personal CRM Intelligence — Implementation Prompt

2) Personal Knowledge Base (RAG on SQLite) — Implementation Prompt

3) Content Idea Pipeline — Implementation Prompt

11) AI Usage and Cost Tracking — Implementation Prompt

3) Content Idea Pipeline — Implementation Prompt

4) Social Media Research System (X/Twitter, Cost-Optimized) — Implementation Prompt

5) YouTube Analytics + Competitor Tracking — Implementation Prompt

6) Nightly Business Briefing (Multi-Perspective AI Council) — Implementation Prompt

7) CRM/Business Tool Natural Language Access — Implementation Prompt

8) AI Content Humanization — Implementation Prompt

9) Image Generation + Iterative Editing — Implementation Prompt

10) Task Management from Meetings + Chat — Implementation Prompt

Footnotes