Skip to main content
Glama

record_decision

Record development decisions by type (fork, abandoned, discovery, constraint, tradeoff, dependency) with rationale and context. Builds a reasoning changelog from choices and trade-offs.

Instructions

Silently record a decision point during development.

Call this tool when you:

  • Choose between multiple alternatives (type: fork)

  • Try an approach that fails or is rejected (type: abandoned)

  • Find unexpected behavior or limitations (type: discovery)

  • Identify a hard constraint that must be respected (type: constraint)

  • Make an explicit trade-off between competing concerns (type: tradeoff)

  • Select an external library or dependency (type: dependency)

Decisions can be intent-scoped (tied to a specific work unit) or repo-scoped (general knowledge like discoveries and constraints). Omit intentId for repo-scoped decisions.

Decisions are accumulated silently during the session and presented for review before commit. This creates a "reasoning changelog" that captures not just what was done, but why.

IMPORTANT: Include constraintViolations when alternatives are rejected due to architectural constraints.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesType of decision: fork (chose between alternatives), abandoned (tried and rejected), discovery (found unexpected behavior), constraint (identified hard requirement), tradeoff (made explicit trade-off), dependency (selected library/tool)
sourceNoProvenance: user (human-recorded), agent (AI deliberately recorded via this tool — the default), extractor (from thought-chain extraction), infer_history (from commit-history extraction). Most callers leave this as the default.
contextNoWhat we were trying to accomplish when this decision was made
summaryYesBrief summary of the decision (< 100 chars recommended)
surfaceNoWhich ceremony(ies) this decision should be surfaced at, controlling when it interrupts future work. Values: "pre-edit" (per-edit block via pre_edit_decision_check — for correctness/security constraints), "intent-create" (injected at intent-framing time — for design/scalability constraints that must shape the approach, not a keystroke), "stop" (once-per-turn Stop/review gate — aggregate/after-the-fact checks), "recall" (passive; only via get_relevant_context). Omit for ordinary decisions — empty means default type-based routing. Strong-signal-only: set it only when the decision genuinely belongs at a non-default ceremony.
symptomNoObservable symptom that indicates this decision is relevant (e.g., error messages, runtime panics, unexpected behavior). Useful for discovery and constraint decisions.
intentIdNoThe intent ID this decision belongs to. Omit for repo-scoped decisions (discoveries, constraints) not tied to a specific work unit
repoPathYesLocal path to the repository root (enables offline sync)
rationaleYesWhy this decision was made
confidenceNoSelf-rated confidence in the decision. Meaningful only for extractor and infer_history sources — leave null for deliberate recordings.
forkAuthorNoFork attribution; usually resolved by Muninn automatically — pass only for override / testing.
repoOriginNoGit remote origin URL. Auto-detected from repoPath via git if not provided.
supersedesNoDecision IDs that this one replaces. When a later decision supersedes an earlier one, pass the earlier decisionId(s) here so the evolve pipeline can track the lineage.
appliesWhenNoTrigger condition / "How to apply" — populate ONLY when the decision is plainly conditional (e.g. "language is Go", "when running in production", "when working in module X", "when the error is ECONNRESET"). Skip when the rule has no clean activation condition or when the rationale already implies universality. Treat applies_when as load-bearing context the LLM uses at recall time to decide whether the decision is relevant — not a soft hint. Strong-signal-only.
workspaceIdNoWorkspace identifier; usually resolved by Muninn automatically — pass only for override / testing.
alternativesNoOther options that were considered
consequencesNoDownstream implications of this decision
relatedFilesNoFile paths affected by this decision
sourceThoughtIdsNoThought-chain entry IDs this record was extracted from. Only set by the extractor path.
resolvedCollisionNoLayer C audit — set ONLY when this decision records how you resolved a completion-time code collision (i.e. after complete_intent returned resolution_required). Links the decision to the live peer you yielded to or overrode.
constraintsCheckedNoWhich architectural constraints were verified before this decision
constraintViolationsNoAlternatives that were rejected due to constraint violations
Behavior5/5

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

No annotations are provided, so the description fully carries the burden. It discloses that decisions are recorded silently, accumulated during the session, and presented before commit. It also notes behavioral traits like constraintViolations handling.

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

Conciseness5/5

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

The description is structured with clear bullet points and sections. It is concise yet thorough, front-loaded with the purpose, and each sentence adds meaningful information without redundancy.

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?

Given the high parameter count, no output schema, and no annotations, the description is complete in explaining the recording process, scoping, and key fields. It adequately prepares the agent for correct usage.

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?

The input schema already has 100% coverage with detailed parameter descriptions. The description adds value by explaining scoping rules (e.g., omitting intentId for repo-scoped) and emphasizing the constraintViolations parameter, providing context beyond the schema.

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?

The description clearly states 'Silently record a decision point during development.' It lists specific scenarios (fork, abandoned, discovery, constraint, tradeoff, dependency) which precisely differentiates it from sibling tools used for retrieval or other actions.

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?

The description provides explicit guidance on when to call the tool for each decision type, explains intent-scoped vs repo-scoped usage, and highlights important actions like including constraintViolations. It effectively informs the agent of appropriate usage contexts.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CodeAwareness/kawa.mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server