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