Local Conversation History logo

Local Conversation History

CommunityPopular
daymade
local-conversation-history

Entry point for local AI conversation history across providers. Routes a request to the one skill that owns it, by platform (Claude Code, OpenAI Codex, Kimi CLI) and action (read evidence vs continue interrupted work), and owns the one job none of them own alone: a single inventory spanning all three providers. Use when the provider is unknown or plural ("our history", "what have I been working on", "which chats did I have"), when the user wants Kimi CLI history at all, when it is unclear whether they need evidence or resumption, or when they ask for this skill by name. Vague recall that names no platform ("we discussed this once, when was it?") belongs here rather than to a single-provider reader, because a Claude-only answer to an unscoped question cannot support an absence claim. When the platform and the action are both already clear, load that executor skill directly instead — except Kimi CLI, which has no reader or continuation skill of its own and always routes through here.

Overview

Publisherdaymade
Repositoryclaude-code-skills
Skill namelocal-conversation-history
Stars
1.4K
Forks
219
Bundled files
Instructions only
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by daymade on GitHub. Read the source before you install it.

Installation

Install the Local Conversation History AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/daymade/claude-code-skills.git /tmp/claude-code-skills
mkdir -p .claude/skills
cp -r /tmp/claude-code-skills/daymade-claude-code/local-conversation-history .claude/skills/local-conversation-history
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Local Conversation History in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Local Conversation History on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Local Conversation History is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

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

PlatformRead evidenceContinue the work
Claude Codedaymade-claude-code:read-claude-code-historydaymade-claude-code:continue-claude-code-work
OpenAI Codexdaymade-claude-code:read-codex-historydaymade-claude-code:continue-codex-work
Kimi CLIread-claude-code-history, with the Kimi scope named — see Provider scopeno 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 needRoute toName this scope
Inventory — "what have I been working on", "list my recent chats", session titles/dates/IDsread-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 resultread-claude-code-history, its bundled full-event searchadd --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 itread-claude-code-history, its optional hybrid recall indexThe 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 resultRoute
A list of conversations: titles, dates, session IDsThe 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, verbatimThe 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 sessionThe 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.

Frequently asked questions

What does the Local Conversation History AI skill do?

Entry point for local AI conversation history across providers. Routes a request to the one skill that owns it, by platform (Claude Code, OpenAI Codex, Kimi CLI) and action (read evidence vs continue interrupted work), and owns the one job none of them own alone: a single inventory spanning all three providers. Use when the provider is unknown or plural ("our history", "what have I been working on", "which chats did I have"), when the user wants Kimi CLI history at all, when it is unclear whether they need evidence or resumption, or when they ask for this skill by name. Vague recall that na...

Why use Local Conversation History on TypingMind?

Because you install it once and use it with any model. Local Conversation History is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Local Conversation History in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/daymade/claude-code-skills/tree/main/daymade-claude-code/local-conversation-history. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Local Conversation History?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Local Conversation History?

As many as you like. As long as a model supports skills, you can use Local Conversation History with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Local Conversation History AI skill free?

Yes. It is published on GitHub by daymade under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇