Gemini History Analyzer
Extract, categorize, and analyze Google Takeout ZIP exports of Gemini Apps activity. The skill handles:
- Extraction (with Chinese/Unicode filename support)
- Content categorization and topic analysis
- User profile extraction from conversation patterns
- Domain-specific keyword search with context verification
- PII/sensitive content detection
- Structured report generation with optional memory file creation
Quick Judgment: Meeting Transcripts vs Prompt-Response
Before full analysis, sample 3-5 files to determine the conversation type:
| Signal | Meeting Transcript | Prompt-Response |
|---|
| Speaker labels | "张三:"、"李四:"、"Speaker 1:" | "User:"、"Assistant:"、"You:" |
| Content pattern | Discussion flow, turn-taking, small talk | Q&A, instruction→output |
| Length distribution | Variable, lots of short turns | Longer assistant responses |
| File naming | Often Chinese, meeting-style titles | English, topic-based titles |
The analysis approach differs:
- Meeting transcripts → topic categorization, speaker analysis, decision tracking, user profile extraction
- Prompt-response → usage pattern analysis, capability assessment, interest domain mapping
Step 1: Extract the ZIP
Google Takeout files contain Chinese/Unicode filenames. macOS unzip corrupts these — always use unar.
# Install unar if missing
brew install unar 2>/dev/null || true
# Extract to a target directory
unar -o <output-dir> -q "<takeout-zip-path>"
The standard structure:
Takeout/
└── My Activity/
└── Gemini Apps/
├── *.txt # Conversation transcripts
├── *.html # Web-format backups (rare)
├── *.png/jpg # Images from conversations
├── *.mp3/mp4/wav # Audio/video attachments
├── *.pdf # Uploaded/shared documents
├── *.xlsx/docx # Office documents
└── *.zip # Nested archives (animation frames, etc.)
Step 2: Inventory and Categorize
Run a full inventory before reading any single file:
# Count by extension
find <extract-dir> -type f | sed 's/.*\.//' | sort | uniq -c | sort -rn
# List all txt files (these are the primary content)
find <extract-dir> -name "*.txt" -type f | sort
# Get total size per type
find <extract-dir> -type f -exec du -sh {} \; | sort -rh | head -30
Build a table of:
- Total file count, total size
- Breakdown by file type (txt count/size, media count/size, etc.)
- Date range if file timestamps are meaningful
Step 3: Sample and Classify
Read 3-5 txt files spread across the file list (not just the first few — timestamps/file sizes may cluster by type). For each:
- Read the first ~100 lines to determine conversation type
- Identify language (Chinese/English/mixed)
- Classify topic area at a high level
- Note speaker count and pattern
Use this sample to decide the analysis strategy for the remaining files.
Step 4: Full Content Analysis
For each txt file, read and extract:
4a. Metadata
- Title (filename minus hash suffix)
- Approximate duration (from transcript timestamps)
- Speaker count and identities
- Language mix (Chinese % / English %)
4b. Topic Classification
Assign primary + secondary topics. Default categories (adjust based on actual content):
- Software Development
- AI/LLM Tools & Workflows
- Infrastructure/Cloud/DevOps
- Business/Strategy
- Product/Design
- Team/HR/Personnel
- Finance/Investment (this is often the target of analysis)
- Legal/Compliance
- Personal/Other
4c. Key Findings Per File
For each file, capture:
- Main discussion points (3-5 bullets)
- Decisions made or action items
- Notable quotes (verbatim, with context)
- Relationships mentioned (people, companies, projects)
Step 5: Domain-Specific Keyword Search
When looking for content in a specific domain (finance, legal, etc.):
- Design keyword list with AND/OR logic — e.g., finance:
stock OR investment OR fund OR portfolio OR 股票 OR 投资 OR 基金, but also domain-specific terms like EPS, P/E, dividend, arbitrage
- Grep every txt file for each keyword batch
- Read surrounding context (10 lines before/after each match) — keyword matching alone produces massive false positives. "Investment" can mean business strategy, "option" can mean UI choice, "fund" can mean insurance feature
- Classify each match as:
- Definite hit (the conversation is about this domain)
- False positive (same word, different meaning)
- Ambiguous (needs deeper reading)
- Re-read full files for definite + ambiguous hits
Never stop at grep output — context verification is mandatory.
Step 6: Generate Report
Report Structure
# Gemini History Analysis Report
**Source**: <zip filename>
**Date analyzed**: <today>
**Extraction size**: <N files, N MB>
## 1. Content Overview
- Total conversations: N
- Conversation type: [Meeting Transcripts | Prompt-Response | Mixed]
- Language distribution: X% Chinese, Y% English, Z% Mixed
- Date range: <earliest> to <latest>
- Media attachments: N images, N audio, N video
## 2. Topic Distribution
| Category | Count | % | Notes |
|----------|-------|---|-------|
| ... | | | |
## 3. Key Findings
(Bulleted, organized by significance)
## 4. Domain-Specific Analysis
(If user requested finance/legal/etc. keyword search)
- Matches found: N
- Confirmed relevant: N
- False positives: N (with examples of what caused them)
## 5. Notable Documents
Non-txt files worth attention: PDFs, spreadsheets, etc.
## 6. Valuable Quotes
Verbatim quotes that capture key insights
## 7. PII / Sensitive Content
(Flag if detected — do NOT include the actual PII in the report)
- File: <name>, Type: <resume/background-check/etc.>, Risk: <high/medium/low>
Step 7: Memory File Generation (Optional)
If the user wants to persist findings as project memory (like .claude/projects/<path>/memory/):
When to generate memory files
- User explicitly asks ("build user profile", "remember this")
- The analysis reveals reusable insights about the user's preferences, workflows, or constraints
- The project has a memory system (check for existing
memory/MEMORY.md)
Memory file types to offer
- User profile (
user-profile.md) — if conversations reveal user's role, preferences, personality
- Feedback/Workflow (
feedback-*.md) — if conversations reveal proven workflows, dos/don'ts
- Project context (
project-*.md) — if conversations reveal ongoing projects, decisions, constraints
Memory writing protocol
- Follow the project's existing memory format (check other memory files for frontmatter conventions)
- Include
originSessionId or source tag pointing back to the analysis
- Update
MEMORY.md index with new entries
- Never duplicate what's already in memory — update existing files instead
Step 8: Cleanup
# Remove extracted files after analysis complete (user confirms)
rm -rf <extract-dir>
Critical Pitfalls (From Real Usage)
1. ZIP extraction: ALWAYS use unar
macOS unzip silently corrupts Chinese filenames — files become garbled paths, many fail to extract. brew install unar + unar -o <dir> <zip> handles everything correctly.
2. Keyword search: grep is step 1, not the answer
Keyword matching on "stock", "investment", "fund", "option", "portfolio", "trading" produced matches in 80%+ of files in a real analysis — every single one was a false positive. These words appear in software development contexts constantly. Always read surrounding context for every match.
3. Know what you're reading
Gemini Takeout txt files are NOT the original Gemini prompt-response pairs. They can be:
- Meeting transcripts exported by 飞书妙记 (Feishu Miaojii) and then uploaded to Gemini
- Manual notes copy-pasted into Gemini
- PDF/article text pasted for analysis
Read the first ~100 lines of each file before assuming its nature.
4. PII is likely present
Resumes, background check forms, contact lists — these routinely appear in conversation history. Flag them, do NOT include their contents in reports. If creating memory files or wiki pages, ensure PII is summarized, not copied.
5. Large files need triage
A 63KB transcript is a 2-hour meeting. Don't read the whole thing unless it's flagged as highly relevant. Read the first 10% + last 10% for gist; read fully only if keyword hits or topic relevance warrant it.
6. Parallel reads for scale
For 100+ files, spawn parallel sub-agents to read and summarize in batches (10-15 files each). Merge results. One agent reading all files sequentially will exhaust context.