About Semantic Anchors

Two-hour live coding session with Johannes Rabauer and Ralf D. Müller (May 2026). Read Johannes' session summary on rabauer.dev.

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.

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

Semantic Anchors activate rich, interconnected knowledge domains from the LLM’s training data.

Simple Instructions just tell the LLM what to do, without providing conceptual framework or methodology.

Think of semantic anchors as nouns (methodologies, frameworks, principles) rather than verbs (instructions, directives).

Testing a Potential Anchor

Before proposing a new semantic 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

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.

Independent thinkers have arrived at the same idea, and practitioners have validated the framing.

Matt Pocock — "Leading Words". In "Building Great Agent Skills: The Missing Manual" (the "Steering" segment, from ~11:54), Pocock describes leading words: 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 →