historic_sql_patterns

A detector for repeated analytical questions that use more than one database table, based on a limited set of historic SQL patterns. It produces structured evidence for a documentation system.

In plain words
What is it for?
Use it to find recurring cross-table analysis, verify the tables and columns involved, and create evidence for durable wiki or semantic-layer documentation.
Why use it?
It turns repeated query behavior into reusable knowledge while requiring join columns to be checked against both tables. This reduces the risk of documenting relationships that are not present in the data.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/kaelio/ktx/historic_sql_patterns
Any agent
npx skills add Kaelio/ktx --skill historic_sql_patterns
Clone the repo
git clone --depth 1 https://github.com/Kaelio/ktx

Made for: Claude Code, Codex.

Per session 28 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 964 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00028 $0.00964
Opus 5 $0.00014 $0.00482
Sonnet 5 $0.00006 $0.00193
Haiku 4.5 $0.00003 $0.00096

Measured 2d ago against content hash 23e3951dbfd1, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

historic_sql_patterns scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

packages/cli/src/skills/historic_sql_patterns/SKILL.md · 90 lines

How it starts

The opening of the file, as written. The whole thing — 90 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Historic SQL Patterns

Use this skill when the WorkUnit raw file is a patterns-input/part-0001.json style shard from the historic-sql adapter. Older staged bundles may still provide root patterns-input.json; when that is the WorkUnit raw file, read it the same way.

Required Workflow

  1. Read the WorkUnit notes first.
  2. Find the single pattern input file listed under the WorkUnit rawFiles section.
  3. Call read_raw_file for that exact raw file path.
  4. Identify recurring analytical intents that span at least two tables and have repeated usage signal.
  5. Emit one pattern evidence object per durable cross-table intent by calling emit_historic_sql_evidence.
  6. Stop after all pattern evidence has been emitted.

Every join column mentioned in pattern descriptions must be verified via entity_details for both sides of the join.

Identifier Verification Protocol

Before writing a wiki page or SL source on any topic:

  1. discover_data({query: "<topic>"}) - see what wikis, SL sources, and raw tables already exist. Prefer updating existing pages over creating new ones.

Before emitting any schema.table or schema.table.column into a wiki body, SL source, tables: frontmatter, sl_refs, or emit_unmapped_fallback:

  1. entity_details({connectionId, targets: [{display: "<identifier>"}]}) - confirm the identifier resolves; inspect native types, FK/PK, and sampleValues.
  2. For literal values from the source, such as status codes or plan tiers, check whether they appear in entity_details sampleValues for the relevant column. If sampleValues is short or the sample may have missed real values, run a sql_execution probe with the same warehouse connection id: sql_execution({connectionId, sql: "SELECT DISTINCT <col> FROM <ref> LIMIT 50"}).
  3. If the candidate identifier still does not resolve, do one of:
    • Use sql_execution({connectionId, sql: "SELECT 1 FROM <ref> LIMIT 0"}). If it errors, the identifier is fictional.
    • Wrap the identifier in [unverified - from <rawPath>] in the wiki body, citing the exact raw path that mentioned it.
    • When recording emit_unmapped_fallback with no_physical_table, include the failing probe error in clarification.
  4. Never copy <schema>.<table> placeholder strings from these instructions into output.

Read the full file on GitHub · 90 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 90 lines · 28 tokens per session scan A 23e3951dbfd1

Subscribe to this mod's changes

historic_sql_patterns is a skill published in the GitHub repository Kaelio/ktx (1,569 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 28 tokens to every session and 964 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other skills, from other repositories

copilotkit-setup

Use when adding CopilotKit to an existing project or bootstrapping a new CopilotKit project from scratch. Covers framework detection, package installation, runtime wiring (managed Intelligence or self-hosted SSE), provider setup, and first working chat integration.

CopilotKit/CopilotKit · 56 tokens

a2ui-renderer

Render A2UI (Agent-to-UI declarative surfaces) in CopilotKit v2. Enable the runtime via CopilotRuntime({ a2ui: {...} }), then enable the provider via . Auto-activates via /info — do NOT manually pass renderActivityMessages. createA2UIMessageRenderer ships from @copilotkit/react-core/v2; low-level primitives…

CopilotKit/CopilotKit · 175 tokens

copilotkit-develop

Use when building AI-powered features with CopilotKit v2 -- adding chat interfaces, registering frontend tools, sharing application context with agents, handling agent interrupts, and working with the CopilotKit runtime.

CopilotKit/CopilotKit · 46 tokens

copilotkit-upgrade

Use when migrating a CopilotKit v1 application to v2 -- updating package imports, replacing deprecated hooks and components, switching from GraphQL runtime to AG-UI protocol runtime, and resolving breaking API changes.

CopilotKit/CopilotKit · 48 tokens

adk-style

Python style and codebase conventions for ADK (Agent Development Kit): private-by-default file visibility, imports, type hints, Pydantic v2 models, formatting, docstrings, logging, async I/O, file and test layout, and unit test structure. Use when writing or editing ADK source or tests, deciding whether a new file or…

google/adk-python · 187 tokens

adk-unit-design

Writes an as-built architecture document for one ADK code unit — purpose, execution flow, data flow, cross-class dependencies, extension points, and the parts that must not change — to docs/design/{topic}/{unit}/index.md. It describes the code as implemented, not a proposed design, and its reader is a developer about…

google/adk-python · 181 tokens