Skip to main content
Glama
vikcena01

continuity

by vikcena01
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Record decision

record_decision

Append a settled decision as a git-versioned markdown note so future sessions can resume without re-deriving it. Use the title to state the durable fact.

Instructions

Append a decision the user has settled. Writes one markdown file plus a git commit; nothing is overwritten or removed, so a mistaken entry is corrected by superseding it rather than by editing. Capture autonomously as you observe it — no permission needed — but only for things a future session could not re-derive; skip restatements and progress narration. How the parameters divide the work: title survives every future projection intact, while body is clipped and, under a tight budget, dropped entirely — so anything that MUST reach a future session belongs in the title, not the body. confidence is rendered beside the claim, so 'tentative' visibly flags an inference a later session should verify before relying on it; leave it unset and it defaults to tentative. One behavioural warning: this writes STRAIGHT to the store and does not go through the reconciler, so it neither de-duplicates nor parks conflicts with frozen claims. Calling it twice with the same title creates two claims. Prefer capture when a turn produced more than one thing, or when the claim might duplicate or contradict an existing one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoThe reasoning behind it. Keep it short: bodies are re-read in every future session and count against the resume budget.
titleYesOne crisp fact, phrased as a statement. This exact text appears in every future resume context, so make it self-contained.
projectNoNamed project in the central store. Omit inside a repo that has .continuity/, where state is found by walking up from the working directory.
confidenceNo'confirmed' when the user stated it plainly; 'tentative' when you inferred it. Defaults to tentative, which is the honest default for an inference.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.1.1
    • addedInput schema / properties / body / description
      Added value: +"The reasoning behind it. Keep it short: bodies are re-read in every future session and count against the resume budget."
    • addedInput schema / properties / confidence / description
      Added value: +"'confirmed' when the user stated it plainly; 'tentative' when you inferred it. Defaults to tentative, which is the honest default for an inference."
    • changedInput schema / properties / project / description
      Previous value: -"Named project (central store). Omit inside a Claude Code repo."New value: +"Named project in the central store. Omit inside a repo that has .continuity/, where state is found by walking up from the working directory."
    • addedInput schema / properties / title / description
      Added value: +"One crisp fact, phrased as a statement. This exact text appears in every future resume context, so make it self-contained."
  2. First observed

TDQS

A5/5.0
Behavior5/5

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

The description richly discloses behavior beyond the sparse annotations: writes straight to the store, bypasses the reconciler, does not de-duplicate, calling twice with the same title creates two claims, nothing is overwritten or removed, and corrections happen by superseding. It also explains how `confidence` renders and defaults. No contradiction with annotations.

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 long but every sentence earns its place: core behavior, usage policy, parameter priority, a behavioral warning, and sibling routing. It is front-loaded with the main purpose and non-destructive guarantee, and stays organized despite its density.

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?

Despite lacking an output schema, the description fully covers the tool's effects, parameter trade-offs, default behavior, caveats, and when to choose an alternative. An agent has everything needed to decide whether to call it and how to construct a correct invocation.

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

Parameters5/5

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

The schema already describes all parameters, but the description adds crucial semantic context: `title` survives every future projection while `body` is clipped and can be dropped entirely; `confidence` is rendered beside the claim and defaults to tentative; `project` is omissible inside a repo with `.continuity/`. This goes well beyond the schema text.

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 opens with 'Append a decision the user has settled,' naming a specific verb and resource, then clarifies the concrete effect: 'Writes one markdown file plus a git commit.' It also distinguishes itself from `capture` by noting it does not de-duplicate or reconcile.

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 is explicit about when to use it ('Capture autonomously as you observe it… only for things a future session could not re-derive'), when not to ('skip restatements and progress narration'), and names the alternative: 'Prefer `capture` when a turn produced more than one thing, or when the claim might duplicate or contradict an existing one.'

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

Deploy Server

Other Tools