Skills, MCP, Workflows, Rules, and Memory: Responsibilities and Collaboration in AI-Assisted Development

1. The Problem Is Not the Number of Terms, but Unclear Responsibility Boundaries

When switching between AI coding tools, a common confusion appears: you only want the AI to help build a page, but the configuration presents a row of terms first. They all look like settings that “make the AI smarter,” yet they operate at completely different layers. Some enforce constraints, some define methods, some connect to external systems, some orchestrate processes, and some retain information across sessions.

If you understand them only by menu name, it is easy to misidentify them. A Skill can contain a Workflow. A client may place Rules files under a Memory menu. “Tools” exposed by an external access protocol may also be mislabeled as Skills. A more reliable way to judge them is to ask three questions in sequence:

1. Load timing: When is it loaded? Is it always resident, matched by task, registered on connection, or retrieved on demand?
2. Maintenance method: Who maintains it? Is it rule review, skill documentation, protocol contracts, workflow state machines, or memory entries?
3. Runtime behavior: What does it do at runtime? Does it block, choose a method, provide a channel, control order, or supplement context?

This article treats an Agent as an AI assistant that can read and write files and call tools, and the host as the client that runs the Agent. The following two real development tasks place Skill, MCP, Workflow, Rules, and Memory in the same task chain.

2. A Five-Layer Mental Model: Constraints, Methods, Access, Orchestration, and Memory

A unified model can be established first:

• Rules: Answer “which conventions must always be followed within the applicable scope?” They are hard constraints, focused on “what must not be done” and “what must be satisfied.”
• Skill: Answers “for this class of task, what method should be used?” It encapsulates reusable methods, steps, scripts, and checks.
• MCP: Answers “how should external tools and data be accessed through a unified protocol?” It is closer to a channel and contract and does not directly decide business methods.
• Workflow: Answers “what should be done first, what should be done next, and under what conditions should the process pause or roll back?” It focuses on order, state, and approval points.
• Memory: Answers “which old information is worth storing, and how should it be recalled later?” It stores reusable context such as preferences, confirmed decisions, and environment constraints.

Concept	Main problem it solves	Development example	Loading and maintenance	Runtime behavior
Rules	What must always be followed within the applicable scope	Do not commit code without authorization; API errors must not be disguised as success	Project- or session-level loading, versioned review	Validate, block, alert
Skill	What method to use for this class of task	Design-to-page, image processing, page troubleshooting, delivery report	Task-matched loading, documentation plus scripts plus tests	Choose method, call tools, produce results
MCP	How to access external tools and data through a unified protocol	Read design files, logs, documentation, monitoring data	Register capabilities on connection, maintain by contract	Provide call channel and data resources
Workflow	What order, conditional branches, and pause points are required	Generate an asset list first, then batch upload after confirmation	Execute state machine after task trigger	Control order, approvals, rollback
Memory	Which old information should be stored and recalled	User preferences, confirmed decisions, environment-specific constraints	Structured writes, retrieval recall, expiration cleanup	Supplement context, reduce repeated confirmation

The point of this table is not to memorize definitions, but to understand that these concepts are not substitutes for one another. Rules cannot replace Skills, and a Skill is not the same as a Workflow. An external access protocol is not responsible for business judgment, and Memory should not become an unreviewed “universal context.”

3. Real Task 1: Implement a Page from a Design and Handle Assets

Assume the task is to implement a mobile page based on a design. The page contains multiple images, which need to be compressed, uploaded to object storage, and then have their access URLs backfilled into the code. In the past, this kind of task easily became manual transport: export assets, compress, upload, copy URLs, paste them back into code. Before the page is even started, the person has already become a “courier” for images.

In this task, the five concepts can divide responsibilities as follows:

1. MCP handles access to design data
   The Agent reads design nodes, layers, text, and asset references through an external context access protocol. MCP’s responsibility is to “get the data,” not to decide how images should be compressed or when they should be uploaded.

2. Skill handles the asset processing method
   The Skill defines how to generate an asset list from design nodes, how to compress images, how to call the object storage service to upload them, how to backfill returned URLs into the code, and how to perform page self-checks. A Skill can include scripts: one script compresses images, and another uploads to object storage. The Agent determines which steps the current task needs and then runs the scripts through host tools.

3. Workflow handles order and confirmation points
   A reasonable flow is: read design -> generate asset list -> human confirms list -> compress and upload -> backfill URLs -> implement page -> self-check -> deliver. The key point is “confirm the asset list first, then batch upload.” If the list contains naming conflicts, abnormal dimensions, or unclear authorization, the Workflow should pause instead of continuing execution.

4. Rules handle hard constraints
   For example: do not commit code without authorization; secrets must not appear in code or logs; API errors must not be disguised as success; shared configuration files must not be modified. Rules should be able to block noncompliant operations.

5. Memory handles reusable conventions
   For example: the object storage directory prefix convention for the project, confirmed asset naming rules, special limitations of a certain environment, and the user preference to “provide a list first, then execute.” Sensitive secrets should not be written to Memory; only non-sensitive references or environment variable names should be stored.

A simplified pseudocode example is as follows:

def run_design_to_page(task):
    rules = load_rules(scope=task.project)
    memory = recall(task.user, task.project)
    skill = match_skill("design_to_page")
    workflow = skill.workflow
    design = read_design_source(task.design_ref)  # read via external access protocol
    assets = skill.plan_assets(design)
    workflow.checkpoint("asset_list_confirmation", assets, require_confirm=True)
    for asset in assets:
        url = skill.compress_and_upload(
            asset,
            prefix=memory.object_prefix,
            secret_ref=memory.secret_ref
        )
        task.code.replace_asset(asset.id, url)
    page = skill.build_page(design, task.code)
    assert rules.check(task.diff)
    assert skill.self_check(page)
    remember(task.project, "asset_directory_convention", assets.layout)

This pseudocode reflects the boundaries: the external access protocol reads the design, the Skill handles compression, upload, and backfilling, the Workflow handles the confirmation point, Rules handle validation and blocking, and Memory provides non-sensitive conventions.

4. Real Task 2: Page Troubleshooting and Delivery Report

The second task: a page intermittently errors in a certain environment, and it needs to be troubleshooted and summarized in a delivery report. Here too, no single capability can complete the work.

• Rules set the baseline first: API errors cannot be packaged as success; critical logs cannot be deleted; production configuration cannot be changed without confirmation; fixes must include verification results.
• Skill provides the troubleshooting method: reproduce first, then collect logs and network information, inspect cache, permissions, and boundary conditions, and finally provide a fix plan and regression checklist. The delivery report Skill defines the report structure: symptoms, reproduction steps, root cause, changes, verification evidence, and risk notes.
• Workflow controls the rhythm: reproduce -> locate -> fix -> regression -> report. High-risk fixes need to pause for confirmation, and failed regression should return to the locate stage rather than going directly to delivery.
• MCP connects to log services, monitoring alerts, or documentation services so the Agent can read external evidence. It only provides data and a call channel; it does not judge root causes for the Agent.
• Memory records “a certain environment has special cache limitations,” “this user prefers to see the root cause before changes,” and “the confirmed regression scope,” reducing repeated communication.

This type of task shows that a Workflow is not just a “step list”; it needs state, conditions, and pause points. Rules are also not prompt decoration; they should be able to truly block incorrect behavior.

5. When Names Overlap, How to Determine What a Configuration Really Is

Naming overlap is common. When judging a configuration, do not look only at the menu name. Look at three dimensions:

1. Load timing
   Rules are usually resident or effective within a project scope; Skills are matched by task type; external access registers capabilities on connection; Workflows enter a state machine after a task is triggered; Memory is retrieved and recalled on demand.

2. Maintenance method
   Rules require review and versioning; Skills require documentation, scripts, and tests; external access requires interface contracts and permission management; Workflows require state definitions and exception paths; Memory requires structured key-value data, source labeling, and expiration policies.

3. Runtime behavior
   Rules perform validation and blocking; Skills perform method selection; external access performs data reading or tool calls; Workflows perform ordering and pausing; Memory performs context supplementation.

Conflict handling also has priorities: hard Rules take precedence over Skill methods, and Skill methods take precedence over temporary Memory; Workflows should pause at high-risk nodes and wait for confirmation; external access must follow least privilege. If information in Memory conflicts with Rules, Rules should prevail. When confirmed decisions change, the Memory entry should be updated and its source annotated.

6. Implementation Checklist: Turn Terms into Engineering Capabilities

Practical recommendations:

• Define Rules before discussing automation. The more capable an Agent is without hard constraints, the greater the risk.
• Turn stable methods into Skills. A Skill should include inputs, steps, scripts, checks, and failure handling.
• Introduce an access protocol only when external systems are needed. Do not add channels just to “look advanced.”
• Use Workflows for tasks that span steps, require approval, or need rollback. Define pause points and failure branches clearly.
• Memory should store only reusable, non-sensitive, explainable information. Secrets, tokens, and private data should not enter Memory.
• Reuse existing scripts first. If a script can complete the task and the Agent can run commands, there is no need to rewrite all logic as complex configuration.
• Keep audit records. Record rule hits, Skill selection, external calls, Workflow state, and Memory sources for later review.

7. Conclusion

The differences among Skill, MCP, Workflow, Rules, and Memory are not about menu names. They are about their responsibilities in the task chain: Rules provide constraints, Skills provide methods, MCP provides external access, Workflows provide orchestration, and Memory provides context. They can be used together, but they cannot replace one another. Validate boundaries with real tasks, and judge the nature of a configuration by load timing, maintenance method, and runtime behavior. Only then can you avoid mistaking one concept for another and move AI-assisted development from temporary prompts to maintainable, auditable, reusable engineering capability.