Honeycomb Memory

---
name: honeycomb-memory
description: Use before starting non-trivial work that Honeycomb may already have prior context for (a past decision, a stated convention, where something lives), when a recalled memory should be cited and possibly zoomed into for detail, or after a decision, preference, durable fact, or gotcha emerges that is worth remembering for next time. Searches with hivemind_search/memory_search, zooms a promising hit with hivemind_read, and stores new memories with memory_store using the correct type.
when_to_use: Before re-explaining a convention the user has already stated, before re-deciding something already decided, when the user asks "did we cover this before" or "what did we decide about X", or right after a decision/preference/gotcha is stated in the conversation.
---

# Honeycomb memory

Honeycomb is a cross-harness memory system. It stores decisions, conventions, preferences, facts,
gotchas, and references, and makes them recallable across sessions and across harnesses through a
local daemon exposed here as MCP tools. This skill teaches three behaviors; each points at one of
those existing tools. It never invents a new tool.

## 1. Search before non-trivial work

Before starting a task that plausibly has prior context, e.g. it touches a past decision, a stated
convention, or "where does X live", call `hivemind_search` (or `memory_search`) with a query
describing the task FIRST, rather than asking the user to re-explain something they may have
already told Honeycomb.

- `hivemind_search` runs the hybrid recall (lexical + semantic, degraded-honest) over durable
  memory and returns refs you can zoom into.
- `memory_search` is the direct memory-table search when you already know you want a memory, not a
  broader recall.

This is the token-cheap, model-driven complement to Honeycomb's always-on recall floor: it fires
only when this skill decides it is relevant, not on every turn.

## 2. Cite recalled decisions, and zoom for detail

When a search surfaces a prior decision or convention, cite it in your work rather than silently
re-deciding it. If the hit is a summary and you need more detail, e.g. the exact wording, the
surrounding turns, use `hivemind_read` to zoom the ref down:

- `depth: 1` (the default) resolves to the Tier-2 summary.
- `depth: 2` resolves to Tier-3 raw turns (bounded by the daemon's turn cap).

Do not silently ignore a recalled decision that conflicts with what you are about to do. Surface
the conflict to the user instead of overriding it unprompted.

## 3. Store with the right type

After a decision, a stated preference, or a durable fact emerges in the conversation, e.g. the user
picks an approach, corrects your assumption, or states a fact about the system, call `memory_store`
so it is recallable next time. Classify it using the closed memory-type taxonomy the tool publishes
in its own schema (do not invent a type outside this set):

- `fact` (default): a stable, verifiable truth about the system, codebase, or domain.
- `convention`: how things are done here, idioms and patterns to follow by default.
- `preference`: the user/team's stated way of working, corrections and do/don't guidance.
- `decision`: an architectural or design choice and its rationale, don't relitigate it.
- `gotcha`: a non-obvious trap, failure mode, or constraint to watch out for.
- `reference`: a pointer to an external resource (URL, dashboard, ticket, doc).

Prefer the most specific type over `fact` when the content clearly fits `convention`,
`preference`, `decision`, `gotcha`, or `reference` instead.

## Inert-safe

If the Honeycomb MCP server is not registered in this session, `hivemind_search`, `memory_search`,
`hivemind_read`, and `memory_store` simply are not in the available tool list. This skill has no
effect in that case: do not attempt to work around a missing tool, and do not tell the user memory
is unavailable unless asked.