Four Core Rules Anthropic Engineers Use to Prompt Claude Code

Anthropic engineers reveal four core rules for using Claude Code: build composable skill systems instead of one-off prompts.
Anthropic engineers shared their Claude Code methodology at the AI Code Summit, centered on shifting from "writing good prompts" to "building skill systems." The four rules include: replace one-off prompts with reusable Skills; skills should contain a tool layer, not just instructions; build small composable skills rather than monolithic ones; and iteratively update skills after each use to create a compound improvement loop. This represents AI tool usage transitioning from a conversational paradigm to an engineering paradigm.
Introduction: Most People Are Using Claude Code Wrong
At the AI Code Summit, Anthropic engineers shared their methodology for actually using Claude Code, revealing a surprising truth: almost everyone is prompting Claude Code incorrectly. After thoroughly studying all materials published by Anthropic engineers, four core rules can be distilled. More importantly, these rules require no technical background to implement.
Claude Code is a command-line AI programming tool launched by Anthropic in 2025 that allows developers to interact directly with the Claude model in the terminal, performing tasks like code writing, debugging, and refactoring. Unlike IDE-integrated tools such as Cursor or GitHub Copilot, Claude Code emphasizes agentic workflows—where AI can autonomously plan and execute multi-step tasks, including reading and writing files, running commands, and searching codebases. The AI Code Summit is a developer conference hosted by Anthropic, focusing on best practices and frontier exploration in AI-assisted programming. Understanding this context helps explain why Anthropic engineers place such emphasis on "skill systems" rather than one-off prompts.

Rule One: Prompt Skills, Not Claude
The Mental Shift from One-Off Prompts to Skill Systems
Most people start from scratch writing a new prompt every time they use an AI coding tool. But the reality is that most of our daily work involves repetitive tasks. Anthropic engineers created the concept of "Claude Skills" for exactly this reason.
According to Anthropic engineer Barry, Skills are defined as "organized file collections that package composable procedural knowledge for agents." In plain language, they're essentially folders—containing standardized methods for completing specific tasks. "Procedural Knowledge" here is a concept from cognitive science, referring to "how-to" knowledge, as distinct from declarative knowledge about "what is." Making procedural knowledge explicit and storing it as files allows AI to follow established processes like an experienced employee, rather than figuring things out from scratch every time.
The Three-Layer Architecture Model
Anthropics divides AI usage into three layers:
- Layer 1: AI Model — The underlying AI capabilities
- Layer 2: AI Agents and Prompts — How most people currently interact with AI
- Layer 3: Skills — The application layer, where work should actually happen
Using a phone analogy: Anthropic is building the phone itself, while users need to create their own "apps." This application layer is Skills. This layered architecture aligns with the classic abstraction hierarchy in computer science—the operating system provides foundational capabilities, applications provide specific functionality, and users accomplish actual work at the application layer. Most people remain stuck at Layer 2, which is like using the command line to directly operate the system every time without installing any applications.
Practical Example
Say you need to reply to an email. The traditional approach is writing a complex prompt every time, describing your tone, style, and writing habits. The Skills approach: simply type /draft email and attach the email you need to reply to. The skill automatically handles everything according to preset rules.
Rule Two: Skills Are More Than Prompts—The Tool Layer Is Key
The Three-Layer Structure of a Skill
A complete Claude Skill contains three internal layers:
Layer 1: Description — Like a label on the folder. Claude checks this description every time it receives a question to decide whether to use that skill. The more specific the description, the more accurately Claude can judge when to invoke it. If described well, you don't even need to explicitly call the skill—Claude will automatically recognize and use it. This mechanism is similar to the "routing" concept in software design—automatically dispatching to the corresponding processing module based on input characteristics, reducing manual intervention.
Layer 2: Instructions — The operations manual followed once the skill is activated; the step-by-step process for completing the task.
Layer 3: Tools — Including code scripts, API calls, reference files, etc. This is where skills truly transcend ordinary prompts.
The Common Mistake Most People Make
Anthropics team member Eric pointed out a common problem: people spend enormous effort writing beautifully detailed prompts but provide the model with extremely crude tools—no documentation, parameters named A and B. It's as absurd as giving an engineer a function with absolutely no documentation and expecting them to use it.
This observation reveals a deeper issue: in the traditional Prompt Engineering paradigm, people compress all intelligence into natural language descriptions, expecting AI to complete complex tasks based solely on text instructions. But in agentic AI systems, Tools are the interface through which AI interacts with the external world. A well-designed tool—with clear function signatures, type annotations, usage examples, and error handling—enables AI to work as efficiently as using a well-designed SDK, rather than guessing intent from ambiguous natural language.
Anthropics engineers do the exact opposite: they focus on the tool layer. For example, creating a domain name checking skill with built-in programmatic verification, so every domain AI recommends has already been validated for availability. Going further, you can have 10 sub-agents simultaneously use this skill, filtering through 10,000+ domains to find the best options. This "parallel sub-agent" pattern reflects the fan-out architecture in AI systems—a coordinator decomposes tasks and distributes them to multiple workers for parallel execution, then aggregates results, dramatically increasing throughput.
Rule Three: Build Composable Skills, Not Customized Monolithic Ones
The Composability Principle
Directly quoting Anthropic's engineering blog positioning: Skills should be Composable, Portable, Efficient, and Powerful.
Composability is a core design principle in software engineering, originating from the Unix philosophy of "do one thing well." Unix tools like grep, sed, and awk each have singular functions, but through pipe composition can accomplish extremely complex tasks. This principle later influenced microservice architecture, functional programming, React componentization, and other modern software design paradigms. Anthropic applying this classic principle to AI skill design essentially brings decades of proven software engineering wisdom to AI workflow orchestration.
Composability means multiple skills can work together, with Claude automatically coordinating which ones to use. The core principle: build small, focused, reusable skills that work together, rather than building one monolithic skill that tries to do everything.
Practical Lesson: From Monolithic Skills to Focused Skills
A concrete anti-pattern: when initially building a content engine, a single /content creation skill was created covering idea generation, script writing, social post drafting, and all other functions. It became unmanageable—every time you wanted to modify the script writing approach, you had to rewrite the entire skill, with no way to determine the blast radius.
This problem is known in software engineering as the "God Object" anti-pattern—a single class or module taking on too many responsibilities, resulting in high coupling and low cohesion, where any modification can produce unexpected cascading effects. The solution is to follow the Single Responsibility Principle, where each module is responsible for only one thing.
The correct approach is splitting into multiple focused skills: /content creation idea research, /YouTube script writer, /LinkedIn post. Each skill has a clear, singular goal and can call each other to form chains.
Three Benefits of Splitting
- Problems are easy to locate — When a focused skill fails, you know exactly where the issue is
- Improvements compound — Update one skill, and all workflows using it automatically upgrade
- Reuse replaces rebuilding — A skill can plug into any workflow without reinventing the wheel each time
Two Advanced Patterns
Pattern One: Save scripts within skills. Barry shared at the AI Engineering Code Summit: they discovered Claude was repeatedly writing the same Python script to style slides, so they had Claude save the script in the skill folder. Next session, it runs the script directly without rewriting it.
This is powerful because code is deterministic—the same input always produces the same output, while AI reasoning is non-deterministic and consumes tokens. In computer science, deterministic means identical inputs necessarily produce identical outputs—a fundamental property of traditional programs. LLM reasoning is inherently probabilistic—even with temperature set to 0, outputs may still have minor variations due to floating-point precision and batching factors. Additionally, each AI inference consumes computational resources (billed per token), while local script execution costs virtually nothing. Therefore, solidifying verified logic as scripts and only invoking AI reasoning when creative judgment is needed is a cost-optimal hybrid architecture strategy. Replacing AI reasoning with code is cheaper, faster, and more repeatable.
Pattern Two: Control invocation permissions. Anthropic built in two flags:
user_invocable: false— Hides the skill from the slash menu, available only to agentsdisable_model_invocation— Only users can run it, the model cannot auto-invoke; suitable for high-risk operations like sending messages or deploying code
This permission control mechanism reflects the "Human-in-the-Loop" design philosophy in AI safety. For irreversible operations (like sending emails, deploying production code, executing financial transactions), the system must ensure a human approval step exists, preventing AI from autonomously executing operations that could cause serious consequences. This is an engineering practice that balances AI autonomy with safety.
Rule Four: Make Skills Smarter After Every Use
The Continuous Improvement Loop
Where Anthropics engineers truly pull ahead is this: their skills don't just "work"—they get better after every use.
Ordinary prompts disappear once you close the chat window. Skills persist, and every use is an opportunity to refine them. The Anthropic engineering team explicitly stated: "Our goal is that Claude working with you for 30 days should be much better than on day one."
This continuous improvement loop is essentially an organizational Knowledge Management practice. In traditional software development, similar concepts include iterative Runbook updates, continuous test case accumulation, and the Post-mortem culture in DevOps. Anthropic has encoded this engineering culture of "learning from mistakes and systematizing" into AI workflows, making every human-AI interaction a data point for system optimization. This parallels the concept of Online Learning in machine learning, except what's being updated isn't model weights but prompt and tool configurations.
How to Do It Concretely
After every skill run, if the output doesn't perfectly match expectations, ask yourself one question: Is this a one-time fix, or should it be permanently written into the skill?
If it's permanent, update the skill—add rules, examples, or edge cases. Most people skip this step: run skill, get output, move on. But the Anthropic engineer workflow is: run skill → get output → update skill, forming a continuous improvement compound loop.
The "compound interest" metaphor here is quite precise. Assuming a 1% improvement after each skill use, after 100 uses the cumulative improvement isn't 100% but approximately 170% (1.01 to the power of 100 ≈ 2.7). This exponential growth effect means that time invested early in skill building and maintenance produces returns far exceeding linear growth later on. This also explains why Anthropic engineers are willing to spend extra time updating skills after each use—they're making long-term investments.
The concrete operation is simple—you can directly tell Claude: "Review the conversation log from my last use of this skill. Can you enhance the skill so this issue is handled automatically, or so the same mistake doesn't happen again?"
This practice of "having AI self-improve its own workflows" is called meta-learning or "learning to learn" in AI research. While this isn't true model parameter updating, by modifying instructions and tools in skill files, it effectively achieves a form of external memory-driven adaptive learning, where system behavior continuously optimizes as experience accumulates.
Summary: Use Claude Code Like an Engineer
The four rules are clear and straightforward:
- Use skills, not one-off prompts — Encapsulate repetitive tasks into reusable systems
- Build tools, not prompt-only skills — Focus investment on the tool layer
- Build composable skills, not customized monoliths — Small and focused, able to call each other
- Update skills after every use — Establish a continuous improvement compound loop
Using Claude Code like an engineer isn't complicated. The core mental shift is: from "writing a good prompt each time" to "building a continuously evolving skill system." This isn't a one-time optimization but a capability accumulation process that grows exponentially over time.
From a broader perspective, these four rules reflect AI tool usage transitioning from a "conversational paradigm" to an "engineering paradigm." In the conversational paradigm, humans are improvisational questioners and AI is a one-time answerer; in the engineering paradigm, humans are system designers and maintainers, and AI is a programmable, configurable, continuously optimizable execution engine. This shift means that future AI productivity gaps will no longer depend on who can write better one-off prompts, but on who can build superior skill systems—which is essentially software engineering capability expressed in a new form for the AI era.
Related articles
TutorialsCursor + Codex Dual-IDE Collaboration: A Practical Methodology for Open-Source Project Customization
A complete methodology for open-source project customization based on real-world experience, detailing the Cursor+Codex dual-IDE workflow, seven-stage process, MVP validation, and AI source code reading techniques.
TutorialsCursor Multi-Agent in Practice: Building a Full-Stack Next.js Blog in 50 Minutes
Build a full-stack blog in 50 minutes using Cursor IDE's multi-Agent mode with Next.js, Clerk auth, and Supabase. Learn the 4-phase AI Agent workflow and key integration pitfalls.
TutorialsBuilding an AI Software Factory from Scratch: A Cursor Engineer's Hands-On Experience with Multi-Agent Collaboration
Cursor engineer Eric shares practical insights on building an AI software factory: automation levels, guardrail design, parallel Agent management, and scaling to 1000+ Agents for 24/7 development.