RDF-backed article collection

The new rules of context engineering for Claude 5 generation models

Anthropic presents a simplification thesis for Claude 5-generation models: remove stale prompt weight, let better models use judgement, and move the right context into Skills, memory, tools, and rich references.

New Context Rules

The collection models seven practices as first-class RDF entities.

Let Claude use judgement

Replace brittle absolute rules with guidance that asks Claude to match surrounding code, local idiom, and user intent.

Use progressive disclosure

Move specialized verification, review, and workflow instructions into loadable skills or tools instead of putting everything upfront.

Use simple tool descriptions

Delete duplicated instructions and let tool descriptions carry the compact information required to use each tool.

Use auto-memory

Rely on automatic memory for relevant durable facts rather than manually encouraging users to write everything to CLAUDE.md.

Use rich references

Give Claude high-fidelity reference artifacts such as code, test suites, HTML mockups, and rubrics rather than only simple plan files.

Try simplifying

Audit accumulated context and remove overconstraint when newer models can use surrounding context and judgement.

Then and Now

Then: give Claude rules; Now: let Claude use judgement

Then: give Claude rulesNow: let Claude use judgement

Older prompt design used strong guardrails such as comment restrictions; the article says newer models can often make the right local judgement without those constraints.

Context Components

System prompt

Product-level instruction surface that tells Claude what product it is operating in and what it is doing.

CLAUDE.md

Repository-level guidance file that should stay lightweight and focus on codebase-specific gotchas.

Skills

Progressively loaded guides for opinionated procedures, verification, and team-specific practices.

Memory

Automatically retained context about the user and work, replacing older manual write-to-CLAUDE.md habits.

References

Rich source artifacts such as files, code, HTML mockups, rubrics, and test suites that Claude can inspect as needed.

Tools

Callable interfaces whose schema, names, parameters, and descriptions should express intended affordances.

Deferred loading

Tooling pattern in which full definitions are searched and loaded only when needed.

FAQ

What is context engineering in this article?

It is the assembly of reusable context from system prompts, Skills, CLAUDE.md files, memory, tools, references, and related surfaces that shape many requests, not only one prompt.

What was Anthropic able to remove?

Anthropic says it removed more than 80 percent of Claude Code's system prompt for models such as Claude Opus 5 and Claude Fable 5 without measurable coding-evaluation loss.

Why can too many rules hurt newer models?

Overlapping and conflicting instructions make the model spend effort reconciling constraints, even when it could infer the right action from user intent and surrounding context.

What replaces rule-heavy guidance?

The article recommends compact guidance that asks Claude to match surrounding code, local conventions, and the current user request.

Why prefer interface design over examples?

Examples can constrain exploration, while well-designed parameters, enumerations, and tool descriptions communicate capabilities without forcing one pattern.

What is progressive disclosure?

It is the practice of loading specialized instructions only when relevant, using skills, deferred tool definitions, or structured reference trees.

How should CLAUDE.md change?

Keep it lightweight, state what the repository is for, and spend the scarce tokens on codebase-specific gotchas rather than facts the agent can discover from the filesystem.

How should skills be written?

Skills should be lightweight, opinionated guides for product- or team-specific practices, split into progressively loadable files when they grow long.

What counts as a rich reference?

Rich references include code, tests, HTML mockups, rubrics, specs, and other high-fidelity artifacts that Claude can inspect directly.

What is the practical action item?

Audit accumulated prompt, skill, and CLAUDE.md context with simplification in mind, using claude doctor where appropriate.

Glossary

Context engineering

Designing the reusable context surfaces that surround an agent across requests, including prompts, memory, skills, files, references, and tools.

Progressive disclosure

Loading task-specific instructions only when they become relevant rather than putting all guidance in the initial context.

Overconstraint

Instruction design that narrows model judgement with too many absolute rules, examples, or duplicated directives.

Deferred loading

A tool or instruction pattern where full definitions are searched and loaded only when the agent needs them.

Rich reference

A high-fidelity artifact such as code, tests, an HTML mockup, or a rubric that communicates intent more concretely than prose alone.

Auto-memory

Automatic retention of relevant user and work context, replacing manual persistence through repository guidance files for many cases.

Tool affordance

Information conveyed by a tool name, schema, parameter type, enumeration, or description that guides how an agent should use it.

Agent harness

The product or runtime context that supplies system prompts, tools, memory, skills, and execution boundaries around a model.

HowTo: Simplify Context Engineering

Step 1

Inventory reusable context surfaces

List every durable context source that can shape the agent before a user prompt is interpreted: system prompt, product prompt, CLAUDE.md files, skills, memory stores, tool descriptions, examples, rubrics, tests, design references, and attached files. For each item, record who owns it, how often it is loaded, and whether it is globally relevant or only useful for a narrow workflow.

Step 2

Classify each instruction by risk and scope

Separate hard safety constraints from preferences, style guidance, operational recipes, and stale guardrails. Keep the hard constraints explicit, but mark broad stylistic rules and older worst-case patches as candidates for simplification when newer models can infer the local answer from surrounding code and user intent.

Step 3

Detect conflict and duplication

Search for repeated guidance across the system prompt, CLAUDE.md, skills, and tool descriptions. If the same rule appears in several places, pick one authoritative home and remove or shorten the other copies so the model does not spend effort reconciling subtly different versions.

Step 4

Replace brittle absolutes with local judgement tests

Turn rules such as always add comments, never add comments, always write a plan, or never write a plan into local judgement criteria: match nearby code, follow the user request, preserve the repository idiom, and explain only when the work benefits from explanation.

Step 5

Move specialized guidance into progressive disclosure

Extract review checklists, deployment steps, verification procedures, domain rules, and rare workflows into skills or linked reference files. The top-level context should point to these resources without carrying their full detail until the agent actually needs them.

Step 6

Redesign tool interfaces before adding examples

Inspect tools as interfaces: names, descriptions, required fields, enums, defaults, validation errors, and return shapes. Improve those affordances first, then keep examples only when they reveal important edge cases that the schema cannot express.

Step 7

Promote rich references over prose summaries

When taste, architecture, or product behavior matters, provide artifacts the model can inspect directly: code, tests, screenshots, HTML mockups, API schemas, rubrics, and prior accepted outputs. Rich references reduce ambiguity and avoid turning long prose into a brittle pseudo-spec.

Step 8

Keep CLAUDE.md focused on repository gotchas

Use CLAUDE.md for the repository purpose, unusual structure, non-obvious constraints, and pointers to deeper resources. Remove instructions the agent can discover cheaply by reading files, package scripts, tests, or existing conventions.

Step 9

Run an evidence-based simplification pass

Use claude doctor or a manual audit to remove context in small batches, then compare behavior on representative tasks. Keep a removed-rule log for high-risk changes so a genuinely useful constraint can be restored with a clearer scope.

Step 10

Re-test after model or tool changes

Repeat the audit when the underlying model generation changes, new tools arrive, or memory behavior changes. Context that was necessary for an older model can become drag for a newer one; context that was safe before may become risky when the agent gains stronger tools.

HowTo: Design Context Surfaces

Step 1

Start with the product boundary

Define what the agent is operating inside: a code editor, terminal, enterprise workspace, support console, research tool, or custom harness. Product boundary determines the system prompt, available tools, acceptable autonomy, and user expectations.

Step 2

Design memory as a scoped service

Treat memory as a service with admission rules, retention scope, provenance, and deletion paths. Save durable preferences and project facts, but avoid turning memory into a dumping ground for transient plans, secrets, raw logs, or facts that should remain in source files.

Step 3

Model skills as just-in-time procedures

Each skill should answer a narrow question: when to use it, what inputs it needs, what files or references it may load, what tools it may call, and what validation proves success. Split long skills into referenced files so only relevant detail enters context.

Step 4

Make tools self-describing

Give tools precise names, concise descriptions, typed parameters, meaningful enums, and clear failure messages. If a tool needs examples to be usable, first ask whether the schema or description is under-specified.

Step 5

Use references for taste and fidelity

For UI, writing style, APIs, architecture, and verification standards, attach or link concrete artifacts. A test suite, HTML mockup, accepted prior output, or rubric can communicate expectations better than a paragraph of abstract preference.

Step 6

Route verification into callable workflows

Move lint, tests, browser checks, review rubrics, deployment probes, and source validation into explicit workflows or skills. This lets the agent discover the right check when needed without carrying every verification detail in the initial prompt.

Step 7

Measure context by decision value

For each context item, ask what decision it helps the agent make and whether that decision appears often enough to justify loading it by default. If the value is rare, make it discoverable instead of global.

Step 8

Keep escape hatches visible

When simplification removes detailed rules, retain a path for recovery: linked references, a doctor command, a validation skill, or a documented owner. The goal is lighter default context, not lost institutional knowledge.

How agent-rdf-memory fares against these guidelines

agent-rdf-memory fares well overall: it already expresses memory as linked, queryable, progressively dereferenceable context rather than a single flat prompt file. The main caution is default context size: the SessionStart hook fixed real reliability failures, but the long-term best shape is intent-selected RDF context packs with full loading reserved for fallback and recovery.

Strong fit: progressive disclosure by RDF manifest

The public preferences graph acts as a manifest of topics and HowTos, while detailed operational guidance lives in linked howto/*.ttl files reached through rdfs:seeAlso. That maps closely to the article recommendation to keep top-level context light and load detailed instructions when relevant.

Strong fit: rich references over prose-only instructions

The system uses Turtle files, ontology terms, entity registries, session graphs, project graphs, scripts, and validation helpers as inspectable references. This is richer than a flat CLAUDE.md because the agent can query and dereference structured artifacts.

Strong fit: durable memory with provenance

Session files, index.ttl, core identity, output-routing values, and provenance-bearing task records implement durable memory without depending only on a free-form Markdown file. This aligns with the article shift from manual CLAUDE.md memory toward automatic memory.

Good fit: context as queryable interface

The ontology-intent route, preferred SPARQL context selection, and validation scripts begin to turn memory from passive text into an interface. The design gives agents typed places to ask which topic, HowTo, or session evidence applies.

Tension: session-start loading can become too broad

The SessionStart hook intentionally injects core.ttl, preferences.ttl, index.ttl, and the latest session before the first turn. That solves reliability failures, but it can drift toward the old put-it-all-upfront pattern unless the SPARQL intent selector becomes the default context-loading path.

Tension: many rules need lifecycle review

The system contains many explicit gates and behavioral rules. That is valuable for high-risk workflows, but the Claude article warns that stale or duplicated constraints can overconstrain newer models. The memory system should periodically audit rules by risk, scope, recency, and observed decision value.

Improvement: expose smaller callable context packs

The RDF model already has enough structure to produce task-specific context bundles, but the interface could be sharper: named queries, doctor reports, and validation commands should expose minimal packs for artifact routing, RDF authoring, identity, KG Explorer, or WebDAV rather than broad memory reads.

Improvement: measure simplification with regression tasks

The memory system records lessons after failures, but it would better match the article if simplification changes were tested against representative tasks: collection generation, DAV/VSP deployment, whoami verification, RDF validation, and KG Explorer repair.

Recommended next moves

Recommendation 1

Make SPARQL-selected context the normal path

Use the intent classifier and ontology routes to load a compact context pack first. Keep full file-based loading as fallback for bootstrap, disconnected endpoints, and recovery mode.

Recommendation 2

Add a context doctor report

Generate a report that lists duplicated rules, stale rules, broad always-on rules, high-risk constraints, and rules whose rdfs:seeAlso target has grown too large. This mirrors claude doctor for RDF memory.

Recommendation 3

Classify rules by risk and load frequency

Tag each rule as safety, routing, style, validation, workflow, or preference, and track whether it belongs in default context, intent-selected context, or recovery-only context.

Recommendation 4

Turn common context packs into named interfaces

Expose named query bundles such as artifact-routing-pack, rdf-authoring-pack, kg-explorer-pack, webdav-vsp-pack, identity-pack, and session-recap-pack so an agent can request the right shape explicitly.

Recommendation 5

Attach regression tasks to simplification

Before deleting or narrowing a rule, run a small task suite that represents the failures the rule was created to prevent. If behavior remains stable, demote the rule from default context to discoverable reference.

Knowledge Graph Explorer

Drag nodes, double-click to unpin, switch into Advanced mode for physics and predicate controls.

0 nodes / 0 links

Explore Knowledge Graph using SPARQL

text/x-html+tr
Run live querySELECT uses text/x-html+tr; DESCRIBE and CONSTRUCT use text/x-html-nice-turtle.

Sources and Attribution

Named graphs

https://linkeddata.uriburner.com/DAV/demos/daas/claude-5-context-engineering-rules-gpt5-chat-1.ttl

Resolver pattern

https://linkeddata.uriburner.com/describe/?url=

Extraction provenance

Source verified from the live Claude page, then transformed into named RDF entities and rendered from the companion Turtle.