local-conversation-history

Local Conversation History — router

This skill decides which skill runs. It does not parse history itself, does

not own commands for a single provider, and never re-implements what an executor

already does. If you find yourself explaining flags for one provider, you are in

the wrong skill — hand off and stop.

Route by platform × action

Establish two things before routing: which platform the conversation lived

on, and whether the user wants evidence (what was said/done) or

resumption (take the work forward).

| Platform | Read evidence | Continue the work |

|---|---|---|

| Claude Code | daymade-claude-code:read-claude-code-history | daymade-claude-code:continue-claude-code-work |

| OpenAI Codex | daymade-claude-code:read-codex-history | daymade-claude-code:continue-codex-work |

| Kimi CLI | read-claude-code-history, with the Kimi scope named — see Provider scope | no continuation skill exists |

Resumption always follows a read. The continuation skills require a verified

read receipt; routing straight to them without one is a defect, not a shortcut.

When the platform is not stated — a bare session ID, "pick up where we left

off" — do not guess it. Identify it first: try the Claude Code exact-session

lookup in read-claude-code-history, then the Codex rollout locator in

read-codex-history. Only a lookup that returns a verified identity decides

which continuation skill runs; a plausible-looking ID prefix does not.

Provider scope — the job only this entry point routes

Each executor defaults to its own provider, so a request that spans providers

never widens by itself. Naming the scope is this skill's whole job. It has

two axes, and they use different flags — conflating them is the failure this

section exists to prevent.

| Cross-provider need | Route to | Name this scope |

|---|---|---|

| Inventory — "what have I been working on", "list my recent chats", session titles/dates/IDs | read-claude-code-history, its bundled inventory | --source all, or --source kimi for Kimi alone |

| Content search — "did we ever discuss X", find the conversation containing a quote, file, or tool result | read-claude-code-history, its bundled full-event search | add --codex and --kimi to the Claude search; each is a separate store the Claude registry never covers |

| Ranked recall — the same question when the wording may have drifted, or the sweep has no session ID, date, or project to bound it | read-claude-code-history, its optional hybrid recall index | The index states which providers it holds; read the coverage line it prints instead of assuming it spans all three |

Both readers ship the same inventory command and its --source already defaults

to all — but each reader's own task table pins it to that reader's provider

(--source claude, --source codex), so the default never fires on its own.

Search is the mirror image: it is Claude-only unless the other two stores are

added explicitly.

Order the last two rows rather than picking one. A cross-provider content

search is the expensive shape: it reads every event of every store, so the cost

scales with the whole corpus rather than with the question. When an index exists

and covers the providers in scope, recall answers in about a second and returns

leads — sessions, dates, projects — that turn the exhaustive scan into a bounded

one. Run it first, then scan only what the index does not hold. Skip straight to

search when the request needs an exhaustive guarantee, because ranked recall

returns top-K candidates and can never support an absence claim.

The index is optional. On a machine that never built one, recall exits non-zero

saying the index does not exist — that is a routing signal, not a failure to

report: fall back to the search row and say the sweep ran unindexed.

Kimi CLI has no other entry anywhere — no dedicated skill exists for either

axis, so both routes above land in read-claude-code-history, which documents

its own Kimi home resolution.

Let the executor own every flag beyond provider scope: --all-projects,

--recursive, date bounds, --include-archived, --include-subagents,

--include-automated, output format, and every detail of how each store is

parsed. This skill names which providers are in scope and nothing else.

Intent decides the route — the word "history" does not

| The user's requested result | Route |

|---|---|

| A list of conversations: titles, dates, session IDs | The inventory row under Provider scope, or the matching reader when one platform is named |

| The conversation where a topic, quote, file, or tool result appeared — "find that old chat", "did we ever discuss X" | The search row under Provider scope, never an inventory. Listing titles is not searching content, and a title match is not evidence the content exists |

| Their own raw inputs in chronological order, verbatim | The matching reader's verbatim-input path. Preserve duplicates and session boundaries; duplicates are part of the ledger, not noise |

| Picking work back up from an identified session | The matching continuation skill, after a read |

The requested output wins over the background motivation. If someone explains a

problem and then asks for a window of their own raw inputs, return that window —

the explanation's topic clues do not convert the request into a content search.

Invariants that survive routing

• Completeness. A Claude inventory's source set is indivisible: the

auto-discovered active homes (~/.claude, profile homes, the current

CLAUDE_CONFIG_DIR) plus every archive registered in

~/.claude/history-sources.json. Never call a conversation absent unless the

output shows the registered archives were covered. An unavailable required

archive is a configuration error, not permission to return a partial answer.

--claude-home is a diagnostic override and can never back a completeness

claim.

• Self-match. The current session records the user's question and this

agent's own commands, so it matches almost any query about itself. Exclude the

current session ID before treating a hit as historical evidence.

• Zero results are not absence. Ranked recall and a bounded search both

return nothing for wording that exists under different words. Widen, or say

what was searched — do not convert an empty result into "it never happened".

• A zero has three causes and only one of them is "no history". The other

two are a home that was never found and a scope that excluded everything, and

none of the three looks different in an empty table. This bites Kimi hardest:

its documented default home is not where every install puts it — a desktop

client can bundle the CLI inside its own runtime and keep sessions there — and

its sessions belong to their own workspaces, so a default run inside some other

repository returns nothing on a store full of conversations. Rule out both

before reporting absence: name the home that was actually read, and say what

project scope was in effect. The inventory prints a diagnostic line when a home

is missing, so quote it when it appears — but a located home that yields

zero prints no diagnostic at all, and the search path prints none in either

case, so never treat a silent empty result as the reader confirming absence.

read-claude-code-history owns how to locate a home and which scope flags the

inventory needs.

Do not

• Do not run provider-specific parsing, SQLite, rg, jq, or JSONL pipelines

here. Every one of those belongs to an executor that already handles its

store's schema, archives, and failure modes.

• Do not copy an executor's flags into this file beyond the three that name

provider scope (--source, --codex, --kimi) — those are this skill's own

subject. Every other flag changes on the executor's schedule; copying one here

makes this file drift silently and then teach the wrong command.

• Do not route to a continuation skill to answer a question about the past.

Reading is evidence; continuing changes the world.