plastic-labs/codex-honcho · Archived

honcho-memory

Persistent cross-session memory via Honcho — recall what you know about the user before working, and save durable insights after.

First seen Jun 26, 2026

Installation

$ npx skills add plastic-labs/codex-honcho --skill honcho-memory

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 39
License LICENSE
Default branch main
Open issues 2
Status Archived

Skill metadata

Parsed from SKILL.md frontmatter.

LicenseMIT

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 1,738 B
  • docs SUMMARY.md 152 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1 installs

SKILL.md

Honcho memory

You have a persistent memory of this user that survives across sessions, backed by Honcho. The codex-honcho hooks already inject relevant context at the start of each turn, and they record the conversation automatically. This skill is for the times you should reach for memory actively.

When to pull memory

Before non-trivial work, query memory instead of guessing:

  • The task touches the user's preferences, conventions, or past decisions
  • You're about to make an assumption you could instead verify ("which package manager?", "how is auth done here?")
  • The user references something from "before" or "last time"

Use the Honcho MCP tools:

  • search — semantic lookup over past messages
  • getpeercontext / get_representation — the current model of the user
  • chat — ask a natural-language question about the user ("what's their testing style?")

When to save memory

After you learn something durable, persist it with create_conclusions:

  • A decision with rationale ("chose SQLite over Postgres — embedded, zero-setup")
  • A stable preference ("prefers small, focused PRs")
  • A non-obvious gotcha or root cause worth remembering
  • A convention specific to this codebase

Keep each conclusion to one concise statement with the why. Review with list_conclusions before adding near-duplicates.

When not to bother

Skip memory for throwaway or purely mechanical tasks — running a build, answering a general knowledge question, trivial edits. Don't narrate that you checked memory; just use it.