Download .skills/pi-history-ingest/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does pi-history-ingest live?
The publisher keeps it at https://github.com/Ar9av/obsidian-wiki.
Which agents can use pi-history-ingest?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.
>
name: pi-history-ingest
description: >
Ingest Pi coding-agent session history into Obsidian as distilled knowledge. Use for importing or mining ~/.pi/agent/sessions or Pi conversation logs; use wiki-agent for targeted topic-only recall.
Pi History Ingest — Session Mining
You are extracting knowledge from the user's Pi coding agent sessions and distilling it into the Obsidian wiki. Pi sessions are stored as structured JSONL with a tree layout — your job is to follow the active branch, extract durable knowledge, and compile it.
Session knowledge closure: Pi session files are the only factual source for this skill. Do not add background knowledge from model training, other tools, package docs, local files, or the current conversation unless that fact appears in the selected session entries. If outside context seems useful, mark it as an open question or skip it — never present it as extracted session knowledge.
This skill can be invoked directly or via the router ().
wiki-history-ingest
/wiki-history-ingest pi
Before You Start
Writing profile: Before drafting or rewriting natural-language Markdown, read and apply the Writing Profile Resolution section in llm-wiki/SKILL.md. Framework schema, provenance, safety, and operation-specific requirements take precedence.
WRITING.md preferences apply only to newly drafted or rewritten natural-language Markdown; preserve source content and structured records.
Resolve config — follow the Config Resolution Protocol in llm-wiki/SKILL.md (inline @name override → walk up CWD for .env → global config → prompt setup). This gives OBSIDIAN_VAULT_PATH and PI_HISTORY_PATH (defaults to ~/.pi/agent/sessions)
Read .manifest.json at the vault root to check what has already been ingested
Read index.md at the vault root to understand what the wiki already contains
Ingest Modes
Append Mode (default)
Check .manifest.json for each source file. Only process:
Files not in the manifest (new sessions)
Files whose modification time is newer than ingested_at in the manifest
Use this mode for regular syncs.
Full Mode
Process everything regardless of manifest. Use after wiki-rebuild or if the user explicitly asks for a full re-ingest.
Pi Data Layout
Pi stores sessions under ~/.pi/agent/sessions/ (or the path set by PI_CODING_AGENT_SESSION_DIR).
~/.pi/agent/sessions/
├── --<cwd-path>--/ # Working directory with / replaced by -
│ └── <timestamp>_<uuid>.jsonl # Session JSONL file
└── ...
The session filename contains an ISO timestamp and UUID. The parent directory encodes the working directory where the session was created.
Session JSONL Format
Each .jsonl file is a sequence of JSON objects. The first line is always a session header; subsequent lines are tree entries with id and parentId.
As you parse, build a private evidence ledger before writing any wiki page. Each durable fact or decision you may write must carry at least one source reference:
pi:<session-file-basename>#<entry-id>
If an entry lacks an id, use pi:<session-file-basename>:line<N> from the JSONL line number. Keep the cited text snippet or summarized observation next to the reference while drafting so you can verify claims before writing.
Skip / noise filters
thinking content blocks — internal reasoning, not durable knowledge
Image content blocks — skip unless the user explicitly asks for image transcription
Raw tool outputs longer than 500 chars — summarize the outcome
Token accounting (usage fields) — metadata only
Repeated plan echoes or status updates
Critical privacy filter
Session logs can include injected instructions, tool payloads, and sensitive text. Do not ingest verbatim.
Remove API keys, tokens, passwords, credentials
Redact private identifiers unless relevant and user-approved
Summarize bash outputs that contain paths, environment variables, or secrets
Do not quote raw toolCall arguments verbatim if they contain sensitive data
Step 3: Cluster by Topic
Do not create one wiki page per session.
Group knowledge by stable topic across many sessions
Split mixed sessions into separate themes
Merge recurring patterns across dates and projects only when each pattern member has evidence ledger references
Use the cwd from the session header to infer project scope
Use session_info.name as a topic hint when available
Drop any cluster whose key claims cannot be traced back to the selected session files
Step 4: Distill into Wiki Pages
Route extracted knowledge using existing wiki conventions:
For each impacted project, create/update projects/<name>/<name>.md.
Writing rules
Distill knowledge, not chronology
Avoid "on date X we discussed..." unless date context is essential
Preserve session-specific decision context when it explains why an approach was chosen; do not flatten it into generic tool advice.
Add summary: frontmatter on each new/updated page (1–2 sentences, ≤ 200 chars)
Add confidence and lifecycle fields to every new page:
base_confidence: 0.42
lifecycle: draft
lifecycle_changed: <obsidian-wiki memory now --date>
Leave lifecycle unchanged on update.
Add provenance markers using the convention in llm-wiki:
Extracted claims use no inline marker by default, but must have a nearby source reference comment.
^[inferred] when synthesizing patterns across multiple sessions or inferring from tool calls.
^[ambiguous] when sessions conflict or a compaction summary contradicts later turns.
Add a source reference comment near every extracted paragraph or bullet:
- Durable fact from the session.
Multiple sources are comma-separated. These comments are the audit trail; do not omit them for extracted claims.
Add/update provenance: frontmatter mix for each changed page.
Mark provenance per the convention in llm-wiki:
compaction and branch_summary entries are pre-distilled — treat as mostly extracted, with source reference comments.
Conversation distillation is mostly ^[inferred] — you're synthesizing from dialogue, and it still needs source references to the turns that support the synthesis.
Use ^[ambiguous] when the user changed their mind across sessions or when compaction summaries disagree with later conversation turns.
Source verification gate
Before writing any page, verify the draft against the evidence ledger:
Every claim (extracted / ^[inferred] / ^[ambiguous]) has at least one pi:... source reference; extracted claims must use a nearby `` comment.
Every source reference points to a selected session file and an entry on the active branch (or a cited compaction / branch_summary).
Proper nouns, tool names, command names, filenames, URLs, package names, and error strings in claims appear in the cited entry text or command fields. Use literal search (grep/rg) on the session file for distinctive strings when in doubt.
If a claim cannot be verified, either delete it or mark it ^[inferred] / ^[ambiguous] with the supporting source refs; never leave unverifiable content without one of these markers (unmarked implies extracted).
Do not write facts learned from the model's training data or the current agent session unless they are explicitly present in the Pi session evidence.
Update index.md, log.md, and hot.md with one locked call:
obsidian-wiki memory sync PI_HISTORY_INGEST \
sessions=<sessions> pages_updated=<pages_updated> \
pages_created=<pages_created> mode=<mode> \
--takeaways "Ingested 12 Pi sessions across 3 projects; surfaced patterns in CLI tooling and API design."
Never hand-edit index.md, log.md, or hot.md — the command takes the lock that keeps a parallel writer from dropping your update. --takeaways is the one-line conceptual summary that used to go in Recent Activity;
omit it to leave the previous takeaways untouched.
See .skills/llm-wiki/references/MEMORY.md for the full procedure.
Privacy and Compliance
Distill and synthesize; avoid raw transcript dumps
Default to redaction for anything that looks sensitive
Ask the user before storing personal or sensitive details
Keep references to other people minimal and purpose-bound
Reference
See references/pi-data-format.md for field-level parsing notes and extraction guidance.
QMD Refresh After Vault Writes
QMD is a search index, not the source of truth. If $QMD_WIKI_COLLECTION is empty or unset, skip this step. Run it only after this skill has written or rewritten vault markdown. If QMD refresh fails, do not roll back the vault changes; report the QMD status separately.
Use $QMD_CLI if set; otherwise use qmd.
${QMD_CLI:-qmd} update
If the output says vectors are needed or embeddings may be stale, run:
${QMD_CLI:-qmd} embed
Verify the collection with either:
${QMD_CLI:-qmd} ls "$QMD_WIKI_COLLECTION"
or, when a specific page path is known:
${QMD_CLI:-qmd} get "qmd://$QMD_WIKI_COLLECTION/<page>.md" -l 5
Record one of:
QMD refreshed: update + embed + verified
QMD refreshed: update only + verified
QMD skipped: QMD_WIKI_COLLECTION unset
QMD skipped: qmd CLI unavailable
QMD failed: <short error summary>
How do I install pi-history-ingest?
Download .skills/pi-history-ingest/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does pi-history-ingest live?
The publisher keeps it at https://github.com/Ar9av/obsidian-wiki.
Which agents can use pi-history-ingest?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.