← AltertableCONTENT HISTORY

Update to Altertable

Snapshot Oct 30, 2026 · 00:05 UTC · version 1.10.0

Collection source: downloaded plugin package.

WHAT CHANGED

Supporting file metadata differs

Supporting file metadata differs

Observed in package metadata. These changes alone do not establish a new customer-facing feature.

Save Altertable and check future changes in Following.

Up to 3 plugins free · no card required.

All fields and original values.

Supporting files

Before

Oct 27, 2026 · 01:02 UTC

[]

After

Oct 30, 2026 · 00:05 UTC

[{"relative_path":"agents/openai.yaml","size_in_bytes":125}]

Compare saved observations

Download comparison JSON

SKILL.md text changes

− removed · + added

No SKILL.md text changes between these observations.

Full technical diff · 1 changed fields

changed /included_files

BEFORE
[]
AFTER
[
  {
    "relative_path": "agents/openai.yaml",
    "size_in_bytes": 125
  }
]
Full snapshot data
{
  "description": "Searches and maintains Altertable memories, knowledge entries, repository context, and semantic-model descriptions. Use when reusable business context, definitions, preferences, or model documentation should guide future agent work.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 125
    }
  ],
  "name": "manage-knowledge",
  "skill_md_contents": "---\nname: manage-knowledge\ncompatibility: Requires Altertable MCP server; knowledge and semantic-model writes require read-write access\ndescription: \"Searches and maintains Altertable memories, knowledge entries, repository context, and semantic-model descriptions. Use when reusable business context, definitions, preferences, or model documentation should guide future agent work.\"\nmetadata:\n  author: Altertable\n  requires: \"altertable-mcp\"\n---\n\n# Manage Knowledge\n\nAltertable has distinct context layers. Put information in the layer whose ownership and lifecycle match it.\n\n| Context              | Use                                                                                                           |\n| -------------------- | ------------------------------------------------------------------------------------------------------------- |\n| Semantic model       | Governed measures, dimensions and relations attached to data                                                  |\n| Knowledge entry      | Durable knowledge material intentionally maintained by the organization                                       |\n| Knowledge repository | Extracted knowledge material synchronized from a source git repository (incl. dbt, code, documentation, etc.) |\n| Memory               | High-signal context learned from work that will save effort in later runs                                     |\n\n## Recall Context\n\nUse `search_memory` when prior preferences, metric caveats, entity history, or successful techniques are likely to matter. Each returned memory has its access count incremented, so do not search reflexively when past context cannot affect the task.\n\nMemories are scoped by environment. Their usefulness is driven by importance, recency, and retrieval frequency; related memories may consolidate and stale memories may fade. Treat that as relevance behavior, not as a promise of a particular decay schedule.\n\n## Create Memories\n\nUse `create_memory` for a high-signal fact, decision, Finding, preference, caveat, or reusable technique that is likely to matter later. Skip routine outcomes and details easily recovered from the schema or data.\n\nAttach the source and related entities when available so the memory can be retrieved in context. Follow the live schema for optional importance or scope fields; do not manufacture a scoring or decay policy in the skill.\n\n## Maintain Knowledge Entries\n\n`create_knowledge` and `update_knowledge` require explicit human intent. The title and content must be text the human supplied or text fetched verbatim from a source they explicitly identified.\n\nNever summarize, synthesize, translate, reformat, or infer organization-wide knowledge for these tools. If scope, title, source, or exact content is unclear, ask before writing. Prefer a repository sync when the maintained source already lives in version control.\n\n## Document Semantic Models\n\nUse `document_semantic_model` for a table-level natural-language description and `document_semantic_model_dimension` for a specific dimension. Retrieve the catalog first and pass the exact catalog, schema, table, and projection names.\n\nDescriptions should state business meaning, grain, ownership, and known caveats. Do not encode a governed calculation only in prose when it belongs in a measure, dimension, filter, or relation definition.\n\n## Boundaries\n\n- Do not store secrets or sensitive row values in any context layer.\n- Do not duplicate a semantic definition as a memory.\n- Do not turn one unverified query result into durable organizational context.\n- Do not overwrite maintained knowledge to resolve a temporary contradiction; surface the conflict.\n"
}

SHA-256 of public snapshot: 258f86d4b3d9a302866f930a28c4a1d2eb5963dc919bb16d5115b9276722dcb8