Rules vs. Skills vs. Workflows vs. Integration Protocols vs. Memory in AI Coding Tools

Switching between multiple AI coding tools, developers often run into a familiar situation: they only want help implementing a page, but the configuration area suddenly presents a row of terms—rules, skills, workflows, integration protocols, memory—as if passing an exam is required before doing the actual work. These concepts are not marketing jargon. They represent different levels of responsibility in an AI collaboration system. Confusing them can lead to redundant configuration or even unpredictable behavior. Below, a single recurring task—“implement a page based on design specifications”—is used to explain each concept in detail.

1. Start with a decision framework

These concepts should not be distinguished only by the names used in product menus. Different tools use highly overlapping naming. A “skill” may contain a complete workflow inside it; a client may even place constraint-style rules under a “memory” menu. A more reliable way to classify them is to evaluate three dimensions:

• Loading timing: When does it enter the AI’s context? Is it always present in every conversation, or is it loaded only when a certain type of task is triggered?
• Maintenance method: Is it a declarative list, a reusable procedure, or a dynamic record created during interaction?
• Execution behavior: Does it define boundaries, provide methods, orchestrate steps, or store and retrieve information?

Using these three criteria makes the boundaries between the five concepts much clearer.

2. Responsibility boundaries of the five concepts

Rules: Persistent constraints within a defined scope

Rules answer the question: “Within a certain scope, which agreements must always be followed?” They are declarative and persistent, and they do not depend on a specific task type. Examples include “do not commit code without authorization,” “do not disguise an API error as a successful response,” and “do not delete the test directory.” Rules define behavioral red lines. They usually do not explain “how to do it”; they specify what “cannot be crossed.”

# Rule example (declarative)
- Do not run git commit / git push without explicit authorization
- When an API returns an error, raise an exception; do not return a fake success state
- Any configuration change affecting production must first request human approval

Skills: How to approach a class of tasks

Skills answer the question: “When facing this type of task, what method should be used?” They encapsulate procedural knowledge and are loaded only when relevant tasks appear. Examples include “process exported design images,” “troubleshoot page style misalignment,” and “prepare delivery reports.” A skill often already contains fixed steps and checklist items, so it can contain a workflow. This is a common source of naming overlap.

Integration Protocols (MCP-like): Standardized access to external tools and data

This type of mechanism answers the question: “How can external tools and data sources be connected through a standardized protocol?” It does not itself generate business logic. Instead, it provides a common channel that allows AI to access external resources such as browsers, design files, and document services. It can be understood as a “standard interface layer” between AI and the external world. It solves connectivity and data retrieval, not how to complete a specific task.

Workflows: Sequence and pause conditions

Workflows answer the question: “What should be done first, what should be done next, and under what conditions should execution pause?” They focus on orchestration: dependencies between steps, branching decisions, and checkpoints that require human confirmation. For example, “first output key style frames, then render the full set only after confirmation” is a typical gated workflow. A workflow can exist independently or be referenced by a skill.

Memory: Information saved and retrieved across sessions

Memory answers the question: “Which old information is worth saving and retrieving later?” It deals with persistence: user preferences, confirmed key decisions, and special constraints of a particular environment. The difference from rules is this: rules are predefined constraints agreed by a team or project, while memory is dynamically accumulated during interaction and reused later in the form of facts and preferences.

3. How the five concepts collaborate in one task

Return to the task of “implementing a page based on design specifications.” All five concepts can appear together, each playing its role:

Concept	Problem it solves	Role in this task
Integration Protocol	How to connect to external data	Import design exports and assets
Skill	How to do this type of task	Define image slicing, naming, and mapping conventions
Workflow	Sequence and pause points	Build the style skeleton first, then complete interactions after confirmation
Rules	What must be followed within scope	Do not modify shared components, and do not commit without authorization
Memory	What information to save for reuse	Remember design conventions, color palettes, and confirmed decisions

The collaboration chain is roughly as follows: the integration protocol brings design data in → the skill guides how to parse and process these assets → the workflow controls the rhythm of “skeleton first, details later” and pauses at confirmation points → the rules maintain safety boundaries throughout the process → the memory stores the design agreements confirmed in this task for reuse next time.

4. Practical recommendations

First, load on demand instead of keeping everything active. Rules and a small number of high-frequency skills can remain loaded. Other skills and workflows should enter the context only when triggered, saving context budget and reducing interference.

Second, classify by dimension rather than by menu name. When a configuration item is unclear, use the three criteria—loading timing, maintenance method, and execution behavior—to determine which category it belongs to, instead of trusting the menu label.

Third, define boundaries and prevent overlapping responsibilities. If a skill already contains step orchestration, there is no need to attach an equivalent workflow outside it. If a constraint is already expressed by rules, there is no need to duplicate it in memory.

Understanding the differences among these five concepts is essentially understanding the layered design of AI collaboration: the constraint layer (rules), the method layer (skills), the connectivity layer (integration protocols), the orchestration layer (workflows), and the persistence layer (memory). When these five layers are organized with clear responsibilities, configuration becomes less like memorizing for an exam and more like a clear, maintainable, and scalable engineering collaboration setup.