wiki-agent

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

.agents/skills/claude-history-ingest

.agents/skills/code-understand

.agents/skills/codex-history-ingest

.agents/skills/copilot-history-ingest

.agents/skills/cross-linker

Audit 0.4.1 · source sha 8bcf57f68146 · 31 Oct 2026Report an issue or request a re-scan

• Publisherar9av GitHub userOwner of the repository this skill is read from
• Source folderar9av/obsidian-wiki/.skills/wiki-agentThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdict8bcf57f68146A new audit runs when the source changes
• Repository statusNot archivedLast push 4 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Search one AI agent's raw history for a specific topic, ingest only matching sessions, and return a synthesized answer. Use for targeted cross-agent recall; use wiki-history-ingest for bulk archival ingestion.

---
name: wiki-agent
description: >
  Search one AI agent's raw history for a specific topic, ingest only matching sessions, and return a synthesized answer. Use for targeted cross-agent recall; use wiki-history-ingest for bulk archival ingestion.
---

# Wiki Agent — Targeted Cross-Agent History Search + Ingest

You are doing a **query-driven targeted ingest** from one specific AI agent's raw conversation history. The user is typically working in a *different* agent right now and wants to pull in context from another agent's past sessions.

This is not bulk ingest. You find sessions about a specific topic, extract the relevant blobs, distill them into the wiki, and return a synthesized answer the user can act on immediately.

## Command Routing

Parse the invocation to determine the target agent and optional query:

| Command | Target | Example |
|---|---|---|
| `/wiki-claude [query]` | Claude Code history | `/wiki-claude "how did I set up auth middleware"` |
| `/wiki-codex [query]` | Codex CLI history | `/wiki-codex "rust ownership patterns"` |
| `/wiki-hermes [query]` | Hermes agent history | `/wiki-hermes "memory architecture"` |
| `/wiki-openclaw [query]` | OpenClaw history | `/wiki-openclaw "project planning approach"` |
| `/wiki-copilot [query]` | Copilot chat history | `/wiki-copilot "test strategy for API routes"` |
| `/wiki-pi [query]` | Pi agent history | `/wiki-pi "how did I refactor the auth module"` |

If no query is given, default to **recent sessions mode**: ingest the last 5 unprocessed sessions from that agent and return a summary of what was found. This is equivalent to a focused `wiki-history-ingest` for that agent only.

## 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.

1. **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`.
2. Read `$OBSIDIAN_VAULT_PATH/.manifest.json` → know what's already ingested.
3. Read `$OBSIDIAN_VAULT_PATH/hot.md` if it exists → warm context on recent wiki activity.

---

## Step 1: Locate the Agent's History Root

| Agent | Default path | Config override |
|---|---|---|
| `claude` | `~/.claude` + `~/Library/Application Support/Claude/local-agent-mode-sessions/` | `CLAUDE_HISTORY_PATH` in `.env` |
| `codex` | `~/.codex` | `CODEX_HISTORY_PATH` in `.env` |
| `hermes` | `~/.hermes` | `HERMES_HOME` in env or `.env` |
| `openclaw` | `~/.openclaw` | `OPENCLAW_HOME` in `.env` |
| `copilot` | `~/.copilot` | `COPILOT_HISTORY_PATH` in `.env` |
| `pi` | `~/.pi/agent/sessions` | `PI_HISTORY_PATH` in `.env` |

If the history root doesn't exist, stop and tell the user: "No `<agent>` history found at `<path>`. Have you run `<agent>` on this machine? You can set a custom path with `<CONFIG_VAR>` in `.env`."

---

## Step 2: Build Session Inventory

Use the **cheapest index source** for each agent — don't open session files until you know which ones are relevant.

### Claude
```
Primary index:   ~/.claude/projects/  (directories = projects, files = sessions)
Session files:   ~/.claude/projects/*/*.jsonl
Desktop index:   find ~/Library/Application Support/Claude/local-agent-mode-sessions -name "local_*.json"
Signal fields:   sessionId, cwd, startedAt, title (in local_*.json)
```
Build a list of sessions: `{path, project_dir, modified_at, already_ingested}`.

### Codex
```
Primary index:   ~/.codex/session_index.jsonl
Session files:   ~/.codex/sessions/**/rollout-*.jsonl
Signal fields:   thread_id, name/title, updated_at (in session_index.jsonl)
```
Read `session_index.jsonl` as the inventory. Each line: `{thread_id, name, updated_at}`. Map thread IDs to rollout files by matching directory names.

### Hermes
```
Primary index:   ~/.hermes/memories/*.md  (fast to scan)
Session files:   ~/.hermes/sessions/**/*.jsonl
Signal fields:   file names, memory titles, first 3 lines of each memory
```
Scan memory filenames first (they're often titled by topic). Fall back to session listing.

### OpenClaw
```
Primary index:   ~/.openclaw/workspace/memory/MEMORY.md  (structured long-term memory)
Daily notes:     ~/.openclaw/workspace/memory/YYYY-MM-DD.md
Session index:   ~/.openclaw/agents/*/sessions/sessions.json
Session files:   ~/.openclaw/agents/*/sessions/*.jsonl
```
Read `MEMORY.md` sections first — it's the pre-compiled summary of everything. Daily notes give recency signal.

### Copilot
```
Primary index:   session filenames / directory listing
Session files:   varies by client (VS Code: ~/.copilot/sessions/*.jsonl or similar)
Signal fields:   session timestamps, file names
```

### Pi
```
Primary index:   ~/.pi/agent/sessions/--<cwd>--/ directories
Session files:   ~/.pi/agent/sessions/--<cwd>--/<timestamp>_<uuid>.jsonl
Signal fields:   cwd (decoded from dir name), session_info.name, timestamp in filename
```
Scan session directories first. Decode `--<cwd>--` to get the working directory. Read the first line (session header) and any `session_info` entries for the session name. No separate index file — the filesystem is the index.

---

## Step 3: Score Sessions Against the Query

If a query was given, score each session in the inventory without opening full session files:

1. **Name/title match** — does the session name or thread title contain the query terms? Score: +3
2. **CWD/project match** — does the working directory suggest the right project? Score: +2
3. **Recency** — apply exponential time decay with a 90-day half-life, as a multiplier on the match score rather than a bonus added to it:

   ```
   base  = name_match(3) + cwd_match(2)
   score = base * (0.35 + 0

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

1. 2026-10-31
   !CAUTION B 89 / 100

   first audit · source 8bcf57f68146

Questions about wiki-agent

• github.com/ar9av/obsidian-wiki/tree/main/.skills/wiki-agent — the audited source at commit 8bcf57f68146 and every finding aboveObserved · 31 Oct 2026

Spotted something wrong? Report a correction · Methodology