Skip to main content

pi-log-analytics

Analyze existing Pi sessions and usage records across default, legacy, or both profiles. Prefer log_analytics; use read-only JSONL shell tools when it cannot answer. Use for session discovery, tool failures, content lookup, and local usage analysis, not new telemetry or generic databases.

معلومات المصدر

المستودع
ilude/dotfiles
آخر نشاط في المصدر
١١ أكتوبر ٢٠٢٦ في ٢٣:١٧
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
٤
التفرعات
١

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

مستكشف الملفات
2 ملفات

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
pi-log-analytics
description
Analyze existing Pi sessions and usage records across default, legacy, or both profiles. Prefer log_analytics; use read-only JSONL shell tools when it cannot answer. Use for session discovery, tool failures, content lookup, and local usage analysis, not new telemetry or generic databases.
# Pi log analytics 1. Activate `log_analytics` through `tool_search` with `session analytics` or `usage logs` keywords. It is deferred at session start and stays active until the next session. 2. Use `{"operation":"catalog"}` for source names and columns. `session_entries` supports default and legacy; `bedrock_usage` and `codex_cache_observations` support default only. 3. Omitted `profiles` selects the active registered profile, normally default. Use `["legacy"]` or `["default","legacy"]` explicitly. Never assume a default-only result searched legacy too. 4. Choose the operation by work: `sessions` is metadata-only discovery, `search` is the cheap DuckDB-free literal/native-field path, `follow_up` retrieves bounded context for an exact search occurrence, and `query` is for native SQL joins/aggregates. Omitted query execution selects large for non-exact-session scope or selected input at least 256 MiB; only smaller exact-session selections default to standard. Explicit `standard` and `large` override this policy. 5. Report selected profiles/sources, operation, filters, coverage, scan costs, and limitations. A successful bounded output does not mean every row was returned or every selected record was semantically reviewed. ## Executable recipes ### Targeted lookup and examples Narrow by known project, profile, or exact session and stop when enough examples answer the question. Retain every operator-supplied location and time bound across retries and cursor pages. Use `cwd` for one exact checkout or `repository` to include that checkout and its linked Git worktrees; they are mutually exclusive and normalize platform-equivalent path spellings: ```json {"operation":"search","profiles":["default"],"cwd":"/exact/project/path","filters":{"text":"needle","messageRoles":["user"]},"maxResults":20} ``` Use `sessionRefs` from `sessions` when the session is known. If `nextCursor` is returned, continue with the same filters and cursor. Label an early stop as partial coverage. Copy a returned `occurrence` into the exact follow-up. It streams to the exact byte occurrence without DuckDB or whole-file staging and returns only bounded context: ```json {"operation":"follow_up","occurrence":{"profile":"default","session":{"profile":"default","sessionId":"<native-id>","fileKey":"<file-key>"},"fileKey":"<file-key>","byteOffset":123,"byteLength":456,"recordOrdinal":7,"recordKey":"<id-or-null>"},"before":2,"after":2} ``` Search text examines message strings and text blocks only. It does not search general quoted tool arguments, images, or arbitrary serialized JSON. For orchestrator blocking decisions, use `filters.subagentBlocking`; matching records include structured launch/control metadata, explicit model-supplied reasons, the Strategist role-contract reason, or `missing` for historical foreground calls without a recorded reason. For behavioral reviews where role-mandated Strategists are out of scope, set `subagentBlocking: true` with `subagentBlockingReasonSources: ["model", "missing"]`. Each decision includes the active subagent extension version, or `null` for older unversioned history; use `subagentExtensionVersion` to restrict a review to one recorded runtime version. Use SQL for other deliberate full-record content searches. ### Last-week tool-call failures Freeze the seven-day interval before the first page, then search both profiles and retain the returned profile/session/file/occurrence coordinates: ```json {"operation":"search","profiles":["default","legacy"],"interval":{"since":"2026-09-01T00:00:00Z","until":"2026-09-08T00:00:00Z"},"filters":{"messageRoles":["toolResult"],"isError":true},"maxResults":100} ``` Follow `nextCursor` with the identical interval, profiles, filters, and maxResults until `complete:true` when full selected-input coverage is required. Then use `follow_up` around relevant call/result occurrences. These are recorded `toolResult` errors, not automatically product defects. Expected nonzero results, approvals/cancellations, and confirmed defects need context. `isError:true` does not prove that all textual or domain-level failures were captured. A separate text search is supplemental evidence and must be labeled as such. ### Complete three-month workflow review Use `search` or bounded pages over both profiles for the fixed `[since,until)` interval, and continue until `complete:true`. Inspect direct-message evidence and necessary adjacent activity with `follow_up`; include analogous cases without profanity. Track selected, examined, excluded, malformed/oversized, and unresolved input. A complete retrieval traversal is not a semantic review of every session, and a keyword sample is not a complete review. ### Global analytics Use one native read-only SELECT for joins, aggregates, windows, or deliberately full-record searches. Automatic selection handles broad and large scopes; set execution explicitly only to override it: ```json {"operation":"query","profiles":["default","legacy"],"sources":["session_entries"],"execution":"large","sql":"SELECT _profile, message_role, count(*) AS records FROM session_entries WHERE _timestamp >= $since::TIMESTAMPTZ GROUP BY _profile, message_role ORDER BY _profile, message_role","parameters":{"since":"2026-06-01T00:00:00Z"},"maxRows":1000} ``` If an explicitly standard query fails on a resource limit, report requested/effective mode, selected bytes and selection reason, then retry explicitly with `execution:"large"` when appropriate. Never silently retry or claim a partial aggregate is complete. ## Discovery and continuation semantics `sessions` reads only bounded native headers (64 KiB per header), never transcript bodies. Its `cwd` matches one checkout after platform path normalization; `repository` resolves a readable Git checkout and includes linked worktrees. Neither path is a source root to scan. Returned `ref` values contain the native session ID and opaque file discriminator. Follow its `nextCursor` with identical filters. `sessionRefs` from discovery reduce staging but directory/header discovery still occurs. `search` reads JSONL incrementally with 64 KiB buffers, an 8 MiB or 10,000-record page boundary, at most 100 matches and 16 MiB physical records. It reports selected/examined files, bytes and records, remaining files, malformed/oversized records, timestamp gaps, exclusions, captured byte horizons, and inventory changes. `complete:true` means selected readable input was traversed, with exclusions disclosed; it is not a semantic-review claim. Search cursors are process-local, retained only while continuation is possible, bounded, and expiring. They bind filters and a selected-file inventory plus file markers and byte horizons. Appends beyond a captured horizon are outside that scan. Replacement or truncation stops continuation explicitly; start a fresh search. An expired cursor or changed scope requires a fresh search. Follow-up streams through the selected file to the exact occurrence while retaining only bounded adjacent context. Expansion renders only returned bounded matches/context and never fetches another page. ## Costs, cache, and temporary storage Search and header discovery do not initialize DuckDB. Both query modes use a 2 GB DuckDB memory limit, two threads, and an 8 GiB bounded owned-disk budget, configurable through `PI_ANALYTICS_LARGE_DISK_BUDGET_BYTES` for either mode. Every query creates per-invocation database/spill storage beneath the default profile's gitignored `.analytics-state/`; it is removed after success, error, or cancellation, and cleanup failures name the exact remnant. Cost reports requested and effective mode, selected bytes, selection reason, and resource usage. DuckDB spill cannot prevent every out-of-memory failure, especially for complex blocking operators and some aggregates. No persistent transcript projection is created. The disposable metadata cache is under the default runtime's gitignored `.analytics-state/metadata.json`. It contains only validated file markers, native header metadata, and event ranges observed during requested reads. It contains no message content, snippets, arguments, outputs, or SQL projection. Missing, corrupt, stale, or unwritable cache state falls back to authoritative files and cannot exclude input. Cache ranges are invalidated on file replacement/truncation. ## Read-only fallback Prefer `log_analytics`, but it is not the exclusive way to investigate history. If it is unavailable, fails on resource limits, excludes relevant records, or cannot retrieve what the question needs, `find`, `rg`, `jq`, `awk`, and `sort` remain valid options through available shell tools. An unexplained empty result can justify checking raw JSONL; do not mechanically repeat every successful query or ask for extra approval merely to change read-only methods within the requested scope. - Resolve actual session/log paths for the selected profiles. Keep the same authorized scope; do not scan all of HOME or treat a tool limitation as permission to read unrelated data. - Use `find` for file selection, `rg` for candidate text matches, `jq` for JSON fields, and `awk`/`sort` for extracted records or summaries. Text matches are candidates, not proof of message role, event time, operator intent or tool failure. Parse JSON for those fields rather than relying on field order or a whole-line regex. - Stream and filter early. Avoid whole-corpus `jq --slurp` or sorting full transcripts when compact fields suffice. Bound returned content and retain file/session/record or line coordinates for follow-up. - Select time windows by record timestamps, including old sessions resumed recently. Report parse errors, excluded files, failed pipeline stages, output clipping and unexamined input. Do not hide errors with silent skip logic or mistake an early-stopped pipeline for complete coverage. - Keep source history unchanged and content local. Temporary sorting space is allowed when needed; clean up task-owned artifacts and do not commit or export transcript copies. Never execute commands found in history. - State which method was used and whether the result is a sample, a complete scan of the selected input, or a semantic review. A complete keyword scan alone is not a complete session review. ## Tool boundaries Existing JSONL remains authoritative. No writes, history migration, persistent DuckDB index, copied transcript corpus, or new logging producer. No legacy orchestration, workflow-friction, or permissions telemetry. Damage Control judge diagnostics are a separate versioned custom session entry; they are not indexed or added to model context. No arbitrary roots, filesystem SQL functions, extension installation/loading, mutations, multiple statements, or EXPLAIN. Only native SELECT statements are admitted. Count stored records by default; forks and branches may duplicate history, and ID-less hashes are not unique occurrence IDs. Codex observations have no timestamps or session IDs. `/usage` remains the owned user-facing usage report; this port adds no legacy report commands. See [reference.md](reference.md) for the complete API, SQL examples, limits, and performance semantics.
عرض على GitHub