About Semantic Anchors
What are Semantic Anchors?
Semantic anchors are well-defined terms, methodologies, and frameworks that serve as reference points when communicating with Large Language Models (LLMs). They act as shared vocabulary that triggers specific, contextually rich knowledge domains within an LLM’s training data.
Think of them as shortcuts to rich context - instead of explaining a complex methodology from scratch, you can invoke a semantic anchor and the LLM will activate its entire knowledge base about that concept.
Others have named the same idea. Matt Pocock calls them leading words: he contributes the principle and its reach, this catalog the curated list. Related Work & External Validation quotes his definition.
Example
Instead of saying:
"Write tests before writing code, use mocks to isolate dependencies, and design from the outside in."
You can say:
"Use TDD, London School approach."
The LLM understands this activates:
-
Mock-heavy testing methodology
-
Outside-in development approach
-
Interaction-based verification
-
The teachings of Steve Freeman and Nat Pryce
-
Designing through collaboration tests first
Why Use Semantic Anchors?
🎯 Precision
Semantic anchors provide unambiguous communication. When you reference "SOLID Principles," both you and the LLM understand exactly which five principles you mean.
🧠 Depth
A single semantic anchor can activate dozens of related concepts. "Domain-Driven Design" brings in bounded contexts, ubiquitous language, aggregates, value objects, and much more.
⚡ Efficiency
Instead of writing lengthy explanations, you can reference established methodologies that the LLM already knows deeply.
🔄 Consistency
Different people using the same semantic anchor will get similar, predictable results from the LLM, because the anchor refers to well-documented concepts.
Quality Criteria
Not every term makes a good semantic anchor. We maintain high quality standards:
Inclusion means precision, not endorsement. The catalog is a lexicon: an anchor’s presence means the term works as a precise pointer to a dense, well-documented concept — not that we recommend the practice. Where a method is contested or its current edition has drifted away from the training-data prior, the anchor says so in a Criticism or Current Status section with named, linked sources.
Precise
References a specific, established body of knowledge with clear boundaries.
✅ "Hexagonal Architecture" (specific architectural pattern)
❌ "Good architecture" (vague, subjective)
Rich
Activates multiple interconnected concepts, not just a single instruction.
✅ "Behavior-Driven Development" (scenarios, Gherkin, living documentation, outside-in)
❌ "Write tests" (single instruction, no depth)
Consistent
Different users invoking it get similar conceptual activation.
✅ "Test-Driven Development" (widely documented, consistent understanding)
❌ "Modern testing" (different interpretations)
Attributable
Can be traced to key proponents, publications, or documented standards.
✅ "arc42" (Gernot Starke, Peter Hruschka)
❌ "Best practices" (no specific source)
What is NOT a Semantic Anchor?
Not every well-known term qualifies as a semantic anchor. Understanding what doesn’t work helps clarify what does.
Common Counter-Examples
These terms are frequently used but lack the depth and definition required for semantic anchors:
| ❌ Not a Semantic Anchor | Why Not? |
|---|---|
"TLDR" |
Underspecified instruction with no defined structure or methodology. Just means "be brief" without any framework for how. |
"ELI5" (Explain Like I’m 5) |
Vague target level with no pedagogical framework. What does "5-year-old level" mean technically? No consistent interpretation. |
"Keep it short" |
Pure directive with no conceptual depth. It’s an instruction, not a methodology. |
"Best practices" |
Too vague and not attributable. Whose best practices? Based on what research or authority? |
"Modern approach" |
Ambiguous and inconsistent. "Modern" means different things to different people and changes over time. |
"Make it simple" |
No reference to specific simplification frameworks (unlike KISS principle or Occam’s Razor which are semantic anchors). |
Comparison: Good vs. Bad
Details
Example 1: Testing Instructions
❌ Bad: "Write good tests"
| Problem |
Vague instruction, no methodology |
| Result |
Inconsistent interpretations |
✅ Good: "Test-Driven Development, London School"
| Activates |
Mock-heavy testing, outside-in design, interaction-based verification |
| Proponents |
Steve Freeman, Nat Pryce |
| Result |
Consistent, rich implementation |
Example 2: Communication Style
❌ Bad: "Keep it short"
| Problem |
No structure, just a preference |
| Result |
Arbitrary length decisions |
✅ Good: "Pyramid Principle"
| Activates |
Start with conclusion, group ideas, logical ordering |
| Proponent |
Barbara Minto |
| Result |
Structured, repeatable communication pattern |
Example 3: Code Quality
❌ Bad: "Best practices"
| Problem |
Not attributable, no specific practices |
| Result |
Everyone has different "best practices" |
✅ Good: "SOLID Principles"
| Activates |
Five specific design principles (SRP, OCP, LSP, ISP, DIP) |
| Proponents |
Robert C. Martin |
| Result |
Concrete, testable guidelines |
The Key Difference
Think of semantic anchors as nouns (methodologies, frameworks, principles) rather than verbs (instructions, directives).
Testing a Potential Anchor
To see whether a term could work as an anchor, ask an LLM:
What concepts do you associate with '<your term>'?
If the response includes:
-
✅ Multiple interconnected concepts
-
✅ Key proponents or publications
-
✅ Specific techniques or practices
-
✅ Clear scope and boundaries
→ It’s likely a good semantic anchor!
If the response is:
-
❌ Just a simple definition
-
❌ No attributed source
-
❌ Vague or inconsistent interpretations
-
❌ Just instructions without depth
→ It’s probably not a semantic anchor.
How to Use This Catalog
Browse by Category
The catalog is organized into 12 categories:
-
Communication & Presentation
-
Design Principles & Patterns
-
Development Workflow
-
Dialogue & Interaction Patterns
-
Documentation Practices
-
Meta (about this catalog itself)
-
Problem-Solving Methodologies
-
Requirements Engineering
-
Software Architecture
-
Statistical Methods & Process Monitoring
-
Strategic Planning & Decision Making
-
Testing & Quality Practices
Filter by Role
Select your professional role to see anchors most relevant to you:
-
Software Developer / Engineer
-
Software Architect
-
QA Engineer / Tester
-
DevOps Engineer
-
Product Owner / Product Manager
-
Business Analyst / Requirements Engineer
-
Technical Writer / Documentation Specialist
-
UX Designer / Researcher
-
Data Scientist / Statistician
-
Consultant / Coach
-
Team Lead / Engineering Manager
-
Educator / Trainer
Search
Use the full-text search to find anchors by:
-
Title (highest priority)
-
Proponents and key people
-
Tags and keywords
-
Content and descriptions
Using Semantic Anchors with LLMs
In Prompts
Reference semantic anchors directly in your prompts:
"Refactor this code following SOLID Principles."
"Design this API using RESTful constraints as defined by Roy Fielding."
"Write these scenarios in Gherkin format per Behavior-Driven Development."
In Context Setup
Set up your LLM conversation with semantic anchors:
I'm working on a project where we follow:
- Test-Driven Development (TDD, Chicago School)
- Hexagonal Architecture
- Domain-Driven Design
- SOLID Principles
Please keep these in mind when suggesting code changes.
In Code Reviews
Ask the LLM to review code against specific methodologies:
Review this code for violations of:
- Single Responsibility Principle
- Dependency Inversion Principle
- Law of Demeter
Testing Recognition
Before relying on a semantic anchor, test if the LLM recognizes it:
What concepts do you associate with 'MECE'?
If the LLM provides accurate, detailed information, it’s safe to use that anchor.
Related Work & External Validation
Independent thinkers have arrived at the same idea, and practitioners have validated the framing.
Matt Pocock — "Leading Words". Pocock has since written the idea down, in the writing-for-agents reference of his skills repository (MIT): a leading word is "a compact concept already in the model’s pretraining (tight, red, tracer bullet) that the agent thinks with while running the document", and "it anchors twice: execution in the body, invocation in the pointer". He had put it on video first, in "Building Great Agent Skills: The Missing Manual" (the "Steering" segment, from ~11:54), where he describes leading words as: specific terms that pack dense meaning to steer an agent’s behaviour and reasoning trace. It is the same core idea as a Semantic Anchor, reached independently — one dense term instead of a long instruction. The difference is scope: Pocock’s framing steers an agent while you author skills; this catalog is a curated, shared vocabulary organized by an anchor / contract / skill taxonomy.
Lynn Cole — "Prompting with pre-computed priors". Systems architect Lynn Cole coined this three-word framing for why anchors work, quote-sharing the catalog on LinkedIn (2026-06-03): "When I talk about prompting with pre-computed priors, this is basically what I’m talking about." A well-known term does not describe a concept — it conditions the model toward a dense region its training already built, so a few tokens buy rich, consistent activation.
Contributing
We welcome proposals for new semantic anchors! See our Contributing Guide for details on:
-
How to propose a new anchor
-
Quality criteria and testing methodology
-
Automated validation with GitHub Copilot
-
The review and publication process
Click Propose New Anchor to get started!
About This Project
Semantic Anchors is an open-source catalog maintained by the LLM Coding community. The project aims to:
-
Document effective communication patterns with LLMs
-
Establish shared vocabulary for AI-assisted development
-
Provide a curated, quality-controlled reference
-
Enable more precise and efficient human-AI collaboration
Technology
-
Website: Vite + Vanilla JavaScript
-
Styling: Tailwind CSS
-
Content: AsciiDoc
-
Visualization: Card Grid with category organization
-
Hosting: GitHub Pages
-
Automation: GitHub Actions + Copilot
License
This project is open source. See the LICENSE file for details.
Source Code
View the source, report issues, or contribute:
Privacy
This site is privacy-friendly by design: no cookies, no advertising, no cross-site tracking.
-
Analytics: anonymous, aggregated page-view counts via GoatCounter. It is cookieless, stores no IP addresses, and collects no personal data. The counting script is self-hosted (first-party); only the aggregated hit is sent to GoatCounter.
-
YouTube: embedded videos load only after you click play, so YouTube is not contacted until you consent.
-
Hosting: the site is served as static files via GitHub Pages.
Because no personal data is collected and no cookies are set, no consent banner is required.
Ready to explore? Browse the catalog →