Skip to main content
Glama

get_briefing

Provides coding agents a one-shot briefing with project context, previous session recap, relevant memories, and symbol locations before code changes.

Instructions

⭐ DEFAULT-FIRST for coding agents on any repo where hivelore init ran: call this BEFORE changing source or project config for the current goal (unless the developer explicitly opts out). One-shot onboarding: everything relevant in a single call under a token budget.

PROGRESSIVE DISCLOSURE — after this, drill down only if needed: mem_relevant_to / mem_search (compact lists) → mem_get (full body + anchors).

RETURNS (in order of priority): 0. action_required — ⚠️ HANDLE THIS FIRST if non-empty (see protocol below)

  1. last_session — recap of the previous session (goal, what was done, next steps)

  2. project_context — .ai/project-context.md (auto-generated from code-map if template)

  3. module_contexts — relevant .ai/modules//context.md based on files being edited

  4. memories — ranked team memories relevant to your task

  5. symbol_locations — file:line:kind for any requested symbols (no grep needed)

  6. setup_warnings — actionable warnings if setup is incomplete

  7. decay_warnings — memories not read in >90 days (consider reviewing)

⚠️ ACTION_REQUIRED PROTOCOL — MANDATORY: If action_required[] is non-empty, STOP and for each item:

  1. Show the developer the exact developer_message field verbatim

  2. Wait for explicit human confirmation ('yes', 'go ahead', 'oui', etc.)

  3. Only then proceed with any code changes NEVER act autonomously on cross-repo breaking changes, dep bumps, or contract diffs.

KEY PARAMETERS: task — what you are about to do (1–2 sentences) — ALWAYS provide this files — files you are about to edit — surfaces anchored memories symbols — symbol names to look up in the code-map (e.g. ['PaymentService']) format — 'full' (default) | 'compact' (1-line) | 'actions' (bullet-first excerpts) budget_preset — 'quick' | 'balanced' | 'deep' — scales max_tokens/memories/module contexts

EXAMPLE USAGE: get_briefing({ task: 'add a Stripe payment integration', files: ['src/payments/'], symbols: ['PaymentService'] })

CONFIDENCE LEVELS in memories: authoritative — human-validated, tested evidence with recent verification trusted — validated; freshness decays since verification, not retrieval low — proposed, hypothesis, or aging evidence; reads do not prove truth unverified — draft (unverified: true flag set)

Replaces 4–5 separate tool calls. Prefer this first; use mem_search / mem_get only for follow-up.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskNoWhat you are about to do, in 1–2 sentences. Used to rank relevant memories semantically.
filesNoProject-relative file paths the agent is currently looking at or about to edit
trackNoIncrement read_count on returned memories
formatNoOutput format: 'full' returns memory bodies (honors token budget via truncation); 'compact' returns a 1-line summary per memory (call mem_get for detail); 'actions' squeezes bodies to actionable bullet lines — fewer tokens vs full.full
symbolsNoSymbol names to look up in the code-map (e.g. ['PaymentService', 'TenantFilter']). Returns the file(s) exporting each symbol so agents don't need to grep. Requires `hivelore index code` to have been run.
semanticNoUse semantic ranking when a task is provided (requires `hivelore embeddings index`).
max_tokensNoApproximate token budget for the entire briefing. Each section is allocated a share and truncated to fit.
session_idNoStable harness session ID; isolates consultation and context delivery.
max_memoriesNoCap on memories surfaced regardless of token budget
budget_presetNoShortcut token budget: 'quick' minimizes tokens/skip module CONTEXT slices; 'balanced' mirrors historical defaults; 'deep' uses a larger briefing. When set, overrides max_tokens, max_memories, and include_module_contexts.
context_resetNoSet after compaction to restore context without resetting task attribution.
deterministicNoIgnore machine-local usage/impact signals so repeated evaluations rank the shared corpus reproducibly.
include_staleNoInclude stale memories (excluded by default — they may be outdated)
memory_scopesNoRestrict the candidate corpus to selected scopes. Omit to include every scope.
min_semantic_scoreNoFloor for semantic-only memory hits (cosine). The default (0) is not 'keep everything': on a corpus large enough to characterize a distribution, an adaptive floor at the corpus mean+½σ is applied so the undifferentiated mass of weak hits is trimmed while the top hit is always kept. Set an explicit value to raise the bar further; it never lowers the adaptive one. Has no effect on memories matched via anchor/module/literal — those are always kept.
dedupe_project_contextNoToken saver (default ON): skip re-emitting the project-context body if an identical copy was already sent within the last few minutes this session (the agent still has it). Set false to always include it.
include_module_contextsNoInclude the `.ai/modules/<name>/context.md` slices inferred from `files` (default ON). Set false to keep the briefing to project context + memories. Overridden by `budget_preset` when that is set.
include_project_contextNoInclude the `.ai/project-context.md` body (default ON). Set false when the agent already has the project overview and you only want the module/memory layers — see `dedupe_project_context` for the automatic, session-aware version of the same saving.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.65.0
    • addedInput schema / properties / context_reset
      Added value: +{
      +  "description": "Set after compaction to restore context without resetting task attribution.",
      +  "type": "boolean"
      +}
    • removedInput schema / properties / max_memories / exclusiveMinimum
      Removed value: -0
    • addedInput schema / properties / max_memories / minimum
      Added value: +0
    • addedInput schema / properties / session_id
      Added value: +{
      +  "description": "Stable harness session ID; isolates consultation and context delivery.",
      +  "type": "string"
      +}
  2. Changed1 schema field changedv0.57.8
    • changedInput schema / properties / min_semantic_score / description
      Previous value: -"Drop semantic-only memory hits whose cosine score is below this threshold. Useful to avoid weakly-related noise when the task is short or the corpus is broad. Has no effect on memories matched via anchor/module/literal — those are always kept. Try 0.25–0.4 for stricter matching."New value: +"Floor for semantic-only memory hits (cosine). The default (0) is not 'keep everything': on a corpus large enough to characterize a distribution, an adaptive floor at the corpus mean+½σ is applied so the undifferentiated mass of weak hits is trimmed while the top hit is always kept. Set an explicit value to raise the bar further; it never lowers the adaptive one. Has no effect on memories matched via anchor/module/literal — those are always kept."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does so thoroughly: it documents the token-budget behavior, the mandatory action_required stop-and-confirm protocol, confidence-decay semantics, dedupe behavior, and the fact that it replaces 4-5 calls. Nothing material about behavior is left implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the default-first directive and uses clear section headers, so it is navigable despite its length. However, the heavy ALL-CAPS emphasis and dense multi-section layout make it longer and louder than strictly necessary for an 18-param tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description takes on the burden of explaining returns and does so with a prioritized RETURNS list plus an in-description behavior protocol. For a high-complexity tool with 18 params, the definition is complete enough for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3. The description adds value beyond the schema by keying the highest-priority parameters (task, files, symbols, format, budget_preset) and by instructing 'task — ALWAYS provide this', which is a usage requirement the schema does not encode since no parameter is required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource with explicit scope: 'One-shot onboarding: everything relevant in a single call under a token budget.' It clearly distinguishes itself from siblings by declaring itself the default-first entry point and positioning mem_search/mem_get as follow-ups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('call this BEFORE changing source or project config for the current goal'), an opt-out condition ('unless the developer explicitly opts out'), and names alternatives ('Prefer this first; use mem_search / mem_get only for follow-up'). The progressive-disclosure ladder is spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.