All insights
Practice AI Product Building Architecture Knowledge Systems

Metadata consumed by LLMs needs trigger specifications, not human summaries

When an LLM scans metadata to decide what to invoke, the description should specify when to activate — not summarize what the thing does — because LLMs are a fundamentally different consumer than humans

@trq212 (Thariq) — Lessons from Building Claude Code: How We Use Skills · · 5 connections

When Claude Code starts a session, it builds a listing of every available skill with its description and scans this listing to decide “is there a skill for this request?” This means the description field is not a summary — it is a trigger specification. Writing “Process content into graph nodes” tells the model what the skill does; writing “Use when you have a URL or article to extract insights from” tells it when to activate. The difference is the same as In agent-native architecture, features are prompts — not code: you are programming the model’s routing behavior through natural language.

This principle generalizes beyond skills to any metadata consumed by LLMs: API descriptions, tool schemas, system prompt routing tables. The insight from CLAUDE.md should be a routing table, not a knowledge base — that CLAUDE.md should be minimal IF-ELSE conditionals — is the same pattern applied to project configuration. Designing metadata for its actual consumer (an LLM doing pattern-matching) rather than its historical consumer (a human reading documentation) is a quiet but high-leverage shift in Context is the product, not the model thinking. The flip side of this consumer shift: when the consumer can infer, Inference capability lowers input fidelity requirements — smart listeners make imprecise input work — not just for metadata format, but for every input surface the LLM touches.