mycelium-hq/ai-brain-starter/insights

When the user types /weekly or /monthly, generate an insight report from their recent journal entries.

Language

Generate the entire report in the language the user writes in. If Spanish, all sections — coach, therapist, panel, floor notes — are in Spanish.

Spanish floor aliases: Asco (1) · Vergüenza (2) · Bochorno (3) · Culpa (4) · Apatía (5) · Resignación (6) · Confusión (7) · Soledad (8) · Aburrimiento (9) · Duelo (10) · Decepción (11) · Herida (12) · Miedo (13) · Frustración (14) · Deseo (15) · Rabia (16) · Desprecio (17) · Orgullo (18) · Valentía (19) · Esperanza (20) · Neutralidad (21) · Disposición (22) · Aceptación (23) · Razón (24) · Confianza (25) · Compasión (26) · Humildad (27) · Pertenencia (28) · Amor (29) · Gratitud (30) · Entusiasmo (31) · Asombro (32) · Alegría (33) · Paz (34)

Floor wikilinks in the report use Spanish aliases in Spanish: [[Miedo]], [[Valentía]] etc.

For /weekly -- read all journal entries from the current calendar week (Monday-Sunday). If today is Monday or Tuesday, default to the previous week (since there's barely any data yet). The user can specify "this week" to override.

For /monthly -- read all journal entries from the current calendar month (1st-last day). If today is the 1st-3rd, default to the previous month. The user can specify "this month" to override.

Journal entries are in: [VAULT_PATH]/Journals/

CRITICAL: How to find entries by date

DO NOT grep thousands of files. Use the journal index instead.

Step 0: Load the journal index

Read [VAULT_PATH]/⚙️ Meta/journal-index.json (or [VAULT_PATH]/Meta/journal-index.json on vaults without an emoji-prefixed Meta — the same folder build-journal-index.py writes to). Structure: {"total": N, "last_updated": "YYYY-MM-DD", "entries": [{file, date, floor, floor_level, floor_arc}, ...]}. Access entries via idx["entries"], then filter by entry["date"].

floor_arc is present only on entries that moved, and build-journal-index.py already stores it as a real list (e.g. ["Fear", "Frustration", "Courage"]) — read it straight from the index for the section 0e movement report instead of re-grepping frontmatter. If no entry in the period carries it, the field is genuinely absent from those entries; do not infer arcs.

If the index doesn't exist or is more than 7 days old, rebuild it first. Note this check measures age, not completeness — a freshly built index can still be missing entries written after it. The daily-journal skill rebuilds the index every time it writes an entry, which is what keeps this guard honest; if entries are missing here, that step is the first thing to check:

/usr/bin/python3 "[VAULT_PATH]/Meta/scripts/build-journal-index.py"

Step 1: Filter entries by date range

From idx["entries"], filter where entry["date"] starts with the target YYYY-MM (monthly) or falls within the target Mon-Sun range (weekly).

Floor counting — primary vs. arc. Each entry has one primary floor (where it landed). Entries that moved also carry floor_arc, the ordered path of floors they passed through. Compute BOTH views and name which one a number is: (a) landed-floor distribution counts the primary floor once per entry; (b) floors-touched distribution expands floor_arc — count +1 for every floor in the arc, and an entry with no arc contributes just its primary floor. Do NOT collapse an arc to a single item, and treat a legacy list-form floor: [A, B, C] the same way (expand it, never count as one). Verify by running a Python script against the index, never hand-counting.

Step 2: Read ONLY the matching files

Read the full content of each matching file. Do NOT read files outside the date range. With the index, you're reading 5-15 files instead of searching the entire vault.

Step 2b: Pull RescueTime + session time data (if available)

If the RescueTime MCP is connected: Try calling mcp__rescuetime__get_daily_summary for each day. If the MCP is disconnected or returns errors, note "RescueTime unavailable for this period" in the report and skip all RescueTime-dependent sections. Do NOT silently omit. For weekly, also call mcp__rescuetime__get_productivity_trend with days: 7.

If a Time Tracking file exists (check CLAUDE.md for the path, typically ⚙️ Meta/Time Tracking.md): Read it and filter entries for the period. This shows what categories were worked on during Claude Code sessions (Writing, Business, Vault, Personal, Admin). Merge with RescueTime app data for a combined picture: RescueTime shows which apps were used, session logs show what purpose they served.

Add to the report if data is available:

• Average daily Productivity Pulse for the period
• Total productive vs. distracting hours
• Top 3 apps by time
• Session time breakdown by category
• Notable gaps or mismatches (e.g., "12h in Obsidian but only 3h tagged as Writing in sessions")

Step 2e: Token usage report (weekly + monthly, optional)

If the vault has scripts/token-usage-report.py, run it to surface real per-session token consumption + estimated USD cost from Claude Code session JSONLs:

# /weekly: 7-day window
VAULT_ROOT="<VAULT_PATH>" python3 "<VAULT_PATH>/scripts/token-usage-report.py" --days 7 --top 10
 
# /monthly: 30-day window
VAULT_ROOT="<VAULT_PATH>" python3 "<VAULT_PATH>/scripts/token-usage-report.py" --days 30 --top 20

The script writes ⚙️ Meta/Token Usage Report.md. Read it and surface a compact block in the report. If Opus cost share >60% or Sessions ≥60 turns >3, surface as a coach line in Section 3 (model-routing or session-length drift). Single-session cost outliers (>$200) get one bullet in Section 2.

This replaces guess-work with real numbers from ~/.claude/projects/<vault-hash>/*.jsonl (the only ground-truth source for token consumption — Claude Code does not surface this in any UI). Inspired by JuliusBrussee/caveman's /caveman-stats.

Step 2f: Drift compression candidates (weekly + monthly, optional)

If the vault has scripts/compress-vault-doc.py, run the compression-candidate sweep on docs flagged by Drift Audit:

VAULT_ROOT="<VAULT_PATH>" python3 "<VAULT_PATH>/scripts/compress-vault-doc.py" --auto-from-drift --dry-run

If candidates show >2KB savings, surface as a compact block. If <2KB, skip silently.

Step 2g: Baseline + anomaly computation (LEAD-WITH SIGNAL)

The reason this skill exists is to surface insight, not to summarize. A report that says "you had 6 Courage entries" is data. A report that says "Courage was 25% in the prior three months, dropped to 3% this month" is signal. That's the lead.

If the vault has monthly-baseline.py, run it for the target period. Check both scripts/ and the Meta scripts folder — on emoji-prefixed vaults it lives at ⚙️ Meta/scripts/monthly-baseline.py, the same place build-journal-index.py is invoked from above:

VAULT_ROOT="<VAULT_PATH>" python3 "<PATH_TO>/monthly-baseline.py" --month YYYY-MM --pretty

The script outputs floor distribution shifts ≥3pp from baseline, word-frequency anomalies ≥2× or ≤0.5× baseline, numeric metric deltas ≥10%, activity deltas, top people mentions, and missing-data flags. Use this output as the FIRST DATA SECTION (sections 0a/0b/0c below). Don't bury it under "Month at a glance." Anomaly-led framing means the reader sees what's different before they see what's present.

Step 2c: Data availability check

Before writing the report, check which data sources exist for the target period:

• Time Tracking file: does it have entries for this month?
• Deep Work Chain: does it have entries for this month?
• Decisions folder: do any decision files fall in this period?
• Skill usage log: any entries for this period?
• RescueTime MCP: is it connected?

If a data source has no entries for the period, skip that section silently. If 3+ data sources are missing, add a one-line note at the top: "Note: some tracking systems started after this period. Sections that depend on them are omitted."

Report Structure

REPORT OPTIMIZATION FUNCTION: Optimize for INSIGHT (anomaly + delta + counterfactual + said-vs-did), NOT for COMPLETENESS (cover every section). A great report surfaces 3-5 things you didn't already know. Sections 0a, 0b, 0c are the load-bearing ones. Sections 1, 1b, 6 are appendix material. Don't lead with summary content. If a section has nothing genuinely surprising, write one short line and move on rather than padding.

The audit shaping every section: would this observation surprise the reader? If no, it's summary not insight. Cut it or compress it.

0a. Anomalies + deltas (LEAD WITH THIS)

From the Step 2g baseline output. Surface the floor shifts, word-frequency spikes, numeric metric changes, and activity deltas — but synthesize them, don't just paste the table. Format as 3-5 bullet points:

• "Courage was 25-49% in the prior three months. Dropped to 3% this month. Hope/Excitement/Gratitude filled the space. The center of gravity shifted from white-knuckle pushing to open-arm receiving."
• "[Person X] mentioned 32× more than baseline. Their arc dominated everything else."
• "Health steps dropped 42%. Body got quiet while the emotional/professional center got loud."

Each bullet names the data, the magnitude, AND the hypothesis the data invites. Don't stop at "X happened" — say "X happened, here's what it might mean."

0b. Said vs. did (counterfactual check)

Pull commitments from the period:

• Decision Log entries (⚙️ Meta/Decisions/*.md) where outcome is blank or stale
• Journal verbatim "I will" / "I'm going to" / "by [date]" statements
• Current Priorities deadlines that were active during the period

For each commitment: what was the outcome? Format as a 2-column comparison. Surface gaps explicitly. A missed deadline or stalled decision is signal, not an error to skip.

This is the section that converts "summary of what happened" into "report card on what was said." Without this, the skill produces narrative without accountability.

0c. Hidden connections (graph + co-occurrence)

For the period, surface:

• People → floor correlations (top 3 people from baseline output, mean floor of entries mentioning each)
• Topic clusters → floor (e.g., "raise" entries averaged Fear; "consulting" entries averaged Excitement)
• Day-of-week patterns if visible
• One non-obvious co-occurrence the GRAPH_REPORT.md flags (run /graphify query if needed)

Goal: surface 1-2 connections invisible from sequential reading. The graph sees aggregate patterns the diary doesn't.

0d. Body track (health-mcp)

The body has its own data and its own arc. When biometric / cycle / sleep / nutrition / lab data is available, it answers questions journals alone can't: which Floor-low days were physiology and which were content; whether the recovery score's "rest more" was the right prescription or whether the actual signal was "eat enough"; whether a Floor pattern this month is anniversary-coupled to the same month two years ago; whether a nutrient deficiency is masquerading as a low-mood pattern.

If the `health` MCP is not registered or returns errors, skip this entire section silently. Graceful degradation, never block the main report.

Tools to call (weekly)

• health_weekly_rollup(week_start) — HRV / RHR / sleep / steps / workout aggregates + recovery_trend
• health_sleep_regularity(week_start, week_end) — bed/wake variance, mean latency, nap count, regularity_score
• health_nutrition_summary(week_start, week_end) — daily macros + under_fuel_signal
• health_cycle_context(today) — current phase + cycle-day + irregularity
• health_floor_correlation("HKQuantityTypeIdentifierHeartRateVariabilitySDNN", days=30, vault_root) — HRV vs Floor over 30d
• health_lab_panel(today, lookback_days=180) — most recent lab values per marker with status (low / in_range / high)

Tools to call (monthly only — additional)