Borrowing it
Nothing to install: this file belongs to Meridiona/meridian. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/Meridiona/meridian/main/.claude/skills/meridian-etl/SKILL.mdgit clone --depth 1 https://github.com/Meridiona/meridianWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/meridiona/meridian/meridian-etl)<a href="https://agentmods.dev/skills/meridiona/meridian/meridian-etl"><img src="https://agentmods.dev/badge/skills/meridiona/meridian/meridian-etl/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/meridiona/meridian/meridian-etl"><img src="https://agentmods.dev/badge/skills/meridiona/meridian/meridian-etl.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Tool Misuse · line 133 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00031 | $0.01131 |
| Opus 5 | $0.00015 | $0.00566 |
| Sonnet 5 | $0.00006 | $0.00226 |
| Haiku 4.5 | $0.00003 | $0.00113 |
Grade A, and why
meridian-etl scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 13d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 146 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Meridian ETL Skill
How the ETL Works
screenpipe.db (read-only)
│
▼
runner.rs ← src/etl/runner.rs
polls every POLL_INTERVAL_SECS
│
├─ get_frames_since(cursor) ← src/db/screenpipe.rs
│ returns new frames since last processed frame_id
│
├─ detect_boundaries()
│ splits frames into blocks by focused_app change
│
├─ extract_block_context() ← src/etl/extractor.rs
│ OCR samples, window titles, audio snippets, signals
│
├─ upsert active_session ← src/db/meridian.rs
│ (current open block, updated each poll)
│
└─ insert completed app_sessions
(previous blocks, now closed)
Key Concepts
| Concept | What it is |
|---|---|
| cursor | last_frame_id in etl_cursor — marks where ETL left off |
| app-switch boundary | frame where focused_app differs from the previous frame |
| active_session | the currently-open, in-progress session (one row, upserted) |
| app_sessions | completed, closed sessions with final timestamps |
| category / confidence | AI-assigned activity category and confidence score on each session |
| gaps | user_idle or system_sleep periods between sessions |
Running with Verbose Logging
RUST_LOG=debug ./target/release/meridian
RUST_LOG=meridian=trace ./target/release/meridian # trace-level for ETL internals
Useful Debug Queries
# Open the meridian DB
sqlite3 ~/.meridian/meridian.db
# Top apps by time today
SELECT app_name, ROUND(SUM(duration_s)/60.0,1) AS minutes, COUNT(*) AS sessions
FROM app_sessions
WHERE started_at >= date('now')
GROUP BY app_name ORDER BY minutes DESC LIMIT 10;
# Check cursor (last processed frame)
SELECT * FROM etl_cursor;
# Inspect active session
SELECT * FROM active_session;
# Find gaps between sessions (potential missed frames)
SELECT
a.ended_at,
b.started_at,
ROUND((julianday(b.started_at) - julianday(a.ended_at)) * 86400) AS gap_secs
FROM app_sessions a
JOIN app_sessions b ON b.rowid = a.rowid + 1
WHERE gap_secs > 120
ORDER BY gap_secs DESC LIMIT 20;
# Sessions with zero duration (regression check)
SELECT * FROM app_sessions WHERE duration_s = 0;
# Count sessions per day
SELECT date(started_at) AS day, COUNT(*) AS n, ROUND(SUM(duration_s)/3600.0,2) AS hours
FROM app_sessions
GROUP BY day ORDER BY day DESC;
# Category breakdown (today)
SELECT category, COUNT(*) AS sessions, ROUND(SUM(duration_s)/60.0,1) AS minutes
FROM app_sessions
WHERE started_at >= date('now')
GROUP BY category ORDER BY minutes DESC;
# Inspect gaps (sleep / idle periods)
SELECT kind, COUNT(*) AS n, ROUND(SUM(duration_s)/60.0,1) AS total_min
FROM gaps GROUP BY kind;
# Long sessions that may be miscategorised
SELECT app_name, category, confidence, ROUND(duration_s/60.0) AS min, window_titles
FROM app_sessions WHERE duration_s > 600
ORDER BY started_at DESC LIMIT 10;
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 13d ago First seen · 146 lines · 31 tokens per session scan A 0169163d8b0f
meridian-etl is a skill published in the GitHub repository Meridiona/meridian (336 stars, last pushed 7d ago), licensed MIT. It adds 31 tokens to every session and 1,131 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
vscode-doctor
Diagnose slow or freezing VS Code-compatible editors with evidence-first, zero-hardcoded-assumption workflow. Use when the user reports editor lag, typing delay, UI freezes, extension host stalls, file watcher noise, high editor CPU/RSS, uses VS Code/Cursor as a file browser over a large folder, or wants a safe editor…
review-agent-harness
Review whether a repository's coding-agent harness can reliably carry work from intent through controlled execution, verification, delivery, and learning. Use when asked to assess agent readiness, repeated agent failures, Rules/Skills/Hooks/Memory effectiveness, missing validation or recovery loops, or whether a…
codebase-audit
A read-only method for auditing an entire codebase across contracts, data integrity, errors, security, architecture, technical debt, configuration, and caching. It produces prioritized findings and a repair roadmap.
codex-agent
Use when you want a second-opinion review via Codex CLI, cross-verification after another agent implements changes, debugging help, or alternative implementation proposals. Requires Codex CLI to be installed and authenticated.
codex-log-guard
Diagnose excessive Codex local SQLite diagnostic log writes with read-only evidence by default. Use when a user mentions logs2.sqlite, logs2.sqlite-wal, blockloginserts, SSD/TBW wear, or explicitly asks to protect, clean up, verify, or restore Codex diagnostic logging.
contribution-architect
Use when a contributor wants to move beyond simple bug fixes into architectural improvements, technical debt discovery, design proposals, or module ownership opportunities.