AWS Builder Center

Builder Center

Semantic Anchors + Kiro Steering: Name It, Don't Describe It

Semantic Anchors + Kiro Steering: Name It, Don't Describe It

Semantic Anchors are established method names like "Clean Architecture" or "Cockburn Use Case" that trigger complete conceptual knowledge inside LLMs — no plugins needed. By embedding these terms in Kiro steering files, teams create persistent, shared conventions that saves you input tokens.

Jörn Krüger

Solution Architect | Full Stack Developer | Technical Founder
"Expelliarmus!" — one word, and the wand flies out of the opponent's hand. No explanation needed. The spell activates the entire concept. Semantic Anchors work the same way for AI-assisted coding: a single established term triggers a complete body of knowledge that's already baked into the model. This article shows how to make that effect permanent across your team using Kiro's steering files.

TL;DR

Semantic Anchors are established method names (like "Clean Architecture" or "Cockburn Use Case") that activate rich conceptual knowledge inside LLMs — without plugins or installations. They work with any AI coding tool. Naming a method instead of describing it saves up to 86% of input tokens for that instruction. This article shows how Kiro's steering files make them particularly powerful: persistent, team-wide, and version-controlled.

The Problem: Long Prompts, Short Context Windows

If you've worked with AI-assisted coding, you know the tension: You want precise output, so you write detailed prompts. But detailed prompts eat context. And context is finite.
Here's a real example. To get a properly structured use case from an LLM, you might write:
"Write the requirement 'User logs in' as a structured scenario with the following elements: Primary actor, secondary actors, preconditions, trigger, main success scenario as numbered atomic steps, extensions for alternative paths and error cases referenced by step number, postconditions on success and failure. Keep it at user-goal level — no UI clicks or system internals."
That's 136 tokens. For a single instruction.

The Shortcut: Semantic Anchors

The same instruction, using a Semantic Anchor:
"Write 'User logs in' as a Cockburn Use Case."
17 tokens. Same result. The Cockburn format is already baked into the model's training data — you just need to trigger it.
In fact, the anchor version often produces more complete output. The verbose prompt above misses elements like "Stakeholders & Interests" or "Minimal Guarantees" that are part of the full Cockburn template. The anchor triggers the complete method definition — not just the parts you remembered to describe.
I ran this across 5 common software engineering tasks:
TaskVerbose PromptSemantic AnchorSavings
Architecture Decision Record135 tokens18 tokens87%
Use Case Specification136 tokens17 tokens88%
Commit Message Format112 tokens25 tokens78%
Architecture Refactoring117 tokens11 tokens91%
Test Strategy116 tokens14 tokens88%
Total616 tokens85 tokens86%
The project Semantic Anchors , created by Ralf D. Müller, catalogs over 100 such vendor-agnostic terms across software architecture, requirements engineering, testing, and communication.

Making It Persistent: Kiro Steering Files

Using Semantic Anchors in individual prompts is useful. Making them your team's default vocabulary is where it gets interesting.
Kiro's steering files live in .kiro/steering/ and are automatically included in every agent interaction. They're the perfect place to declare which Semantic Anchors define your project's conventions.
Now, you might think: "Kiro already knows SOLID and writes Given/When/Then by default — why bother spelling it out?" True — many anchors like SOLID, DRY, or Gherkin will probably be chosen without steering. But "probably" is the key word. An LLM's defaults can shift between model updates. If Kiro decides after an update that Gherkin is no longer the best format for acceptance criteria, your specs might suddenly look different — without you changing anything.
Pinning these choices in a steering file turns implicit defaults into explicit contracts. You're not just hoping the model picks the right pattern — you're telling it which one to use.
This also raises an interesting question: how do you find out which "spells" Kiro is currently casting by default? Simple — ask it. Prompt something like "What format would you use for acceptance criteria in this project?" and compare the answer to your team's expectations. If there's a gap, that's an anchor worth adding to your steering file.
Here's what a steering file might look like for a serverless AWS project:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
<!-- .kiro/steering/conventions.md -->
---
inclusion: always
---

# Project Conventions

## Architecture
- Follow Hexagonal Architecture (Ports & Adapters)
- Document decisions as ADR according to Nygard
- Visualize structure using C4 Diagrams (Context + Container level)

## Code Quality
- Apply SOLID Principles
- Eliminate Code Smells (Fowler/Beck)
- Follow the Single Level of Abstraction Principle (SLAP)

## Requirements
- Write features as Cockburn Use Cases (user-goal level)
- Prioritize using MoSCoW
- Validate stories against INVEST criteria

## Testing
- Structure tests according to the Testing Pyramid
- Write acceptance criteria in Gherkin (Given/When/Then)
- Apply TDD Chicago School for domain logic

## Workflow
- Commit messages follow Conventional Commits
- Branching follows GitHub Flow
- Versioning follows Semantic Versioning (SemVer)
Every term in that file is a Semantic Anchor. When Kiro reads this steering file, it doesn't need you to explain what "Hexagonal Architecture" means or how "Conventional Commits" are structured. Those concepts are already baked into the model. You're just telling it which standards apply to this project.

Why This Works Especially Well in Kiro

Three things make Kiro + Semantic Anchors a natural fit:
1. Steering files are always-on context.
Unlike chat history that scrolls away, steering files are injected into every interaction. Your anchors are always active — no need to repeat them.
2. Specs benefit from precise vocabulary.
Kiro's spec workflow (Requirements → Design → Tasks) maps directly to anchors like Cockburn Use Cases (requirements), C4 Diagrams (design), and Thin Vertical Slice (task decomposition). Naming the method in your spec gives Kiro a clear template to follow.
3. Teams share steering files via Git.
Since .kiro/steering/ lives in your repo, the entire team benefits. A new developer joining the project gets the same conventions injected automatically. No onboarding doc needed — the steering file is the onboarding doc.
Bonus for AWS developers: The Semantic Anchors catalog focuses on general software engineering methods, but AWS-specific terms work just as well. Phrases like "AWS Well-Architected Framework", "AWS Serverless", or "Event-Driven Architecture" are so deeply embedded in training data (AWS docs, blog posts, re:Invent talks) that they trigger the same rich context. You can mix both in your steering file:
1
2
3
4
5
## AWS Patterns
- Review architecture against the AWS Well-Architected Framework
- Build services as AWS Serverless (Lambda, API Gateway, DynamoDB)
- Design async workflows as Event-Driven Architecture (EventBridge, SQS, SNS)
- Apply IAM Least Privilege for all service roles
These aren't in the catalog (yet), but they work the same way — because they're established, widely published concepts with deep representation in the model's training data.

Conditional Steering for Different Contexts

You can also use file-match patterns to activate anchors only in specific contexts:
1
2
3
4
5
6
7
8
9
10
11
12
<!-- .kiro/steering/testing.md -->
---
inclusion: fileMatch
fileMatchPattern: "**/*.test.ts"
---

# Testing Conventions

- Follow TDD London School (outside-in, mock collaborators)
- Use Test Doubles according to Meszaros (distinguish Stub, Mock, Spy, Fake, Dummy)
- Structure: Arrange → Act → Assert
- Name tests: should_[expected]_when_[condition]
This steering file only activates when Kiro is working on test files — keeping your main context lean.

The Catch: You Need to Know the Vocabulary

Semantic Anchors reward developers who can name their methods. If you know the term "Hexagonal Architecture", you save 91% of the tokens compared to describing the same concept in prose. If you don't know the name, you write a paragraph about ports and adapters and dependency direction.
Both approaches work. One is just more efficient.
There's a second nuance: Semantic Anchors work best for established, widely published methods. If your team's "Definition of Done" has 12 custom points that differ from the Scrum Guide default, the anchor name alone won't cut it. In that case, use the anchor as a starting point and add your specifics in the steering file:
1
2
3
4
5
- Definition of Done (with additions):
- All items from standard DoD apply
- Security review by AppSec team completed
- Feature flag documented in LaunchDarkly
- Load test passed for p99 < 200ms
A good rule of thumb: if your convention matches the widely known definition, the anchor name is enough. If it diverges, spell out the delta. This keeps your steering file lean — you only write details where your team departs from the standard.
The good news: the Semantic Anchors catalog  is a great way to discover methods you might already be applying without knowing their canonical name.

Getting Started

  1. Browse the Semantic Anchors catalog 
  2. Identify which methods your team already follows
  3. Create a .kiro/steering/conventions.md file listing them
  4. Commit it to your repo
That's it. No installation, no configuration, no dependencies. Just the right words in the right place.
The token measurements were performed using tiktoken (cl100k_base encoding). While Claude uses a different tokenizer, the relative proportions remain consistent:
1
2
3
4
5
6
7
8
import tiktoken
enc = tiktoken.get_encoding("cl100k_base")

verbose = "Write a structured scenario with primary actor, preconditions, numbered atomic steps, extensions for error cases, postconditions. Keep it at user-goal level."
anchor = "Write this as a Cockburn Use Case."

print(f"Verbose: {len(enc.encode(verbose))} tokens") # 136 tokens
print(f"Anchor: {len(enc.encode(anchor))} tokens") # 17 tokens

Resources

# kiro# spec-drivien-development# prompt-engineering
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article