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.