Rules, Skills, MCP, Workflows, and Memory in AI coding agents: a field guide built from real tasks

Theme: serene-rose

I switch between Claude Code, Codex, and Pi-Bolt, and I often run into this situation: I just want the AI to help write a page, but the configuration first throws out a list of terms, like I need to pass an exam before getting service.

Take "implement a page from a Figma design" — MCP can handle connecting to the design, Skill dictates how images are processed, Workflow arranges the order of confirmation and execution, Rules restrict which files cannot be touched, and Memory keeps conventions needed next time.

They can be used together, with roughly this division of labor:

Concept	Main problem it solves	Example in development
Rules	Which conventions must always be followed within scope?	No unauthorized commits; interface errors must not be disguised as success
Skill	What method to follow for this type of task?	Processing design images, debugging page issues, compiling delivery reports
MCP	How to connect external tools and data via a unified protocol?	Reading browser, design, document services
Workflow	What to do first, what later, under what conditions to pause?	Show frames first, only render the full film after confirmation
Memory	What old information is worth saving and retrieving later?	User preferences, confirmed decisions, special limits of an environment

Naming across products also overlaps. A Skill can contain a Workflow, and some clients may put rule files under a "Memory" menu. To judge what it does, you have to look at load timing, maintenance method, and execution behavior; recognizing only menu names can misidentify things.

The Agent mentioned later is an AI assistant that can read and write files and call tools; the host refers to the client that runs it.

1. Start with processing design images

When developing mini programs, I often need to export assets from Figma, compress PNGs, upload to Tencent Cloud COS, copy the URL, and put it back into the code. Before I even start writing the page, I've already become a courier for images.

When a page has several images, I have to repeat this operation multiple times. Later I turned it into an image-auto-upload Skill with two scripts, one to compress PNGs and one to upload to COS, then connected asset processing to page development.

The full process is written in: "I wrote a Claude Code Skill, no more manual image cropping and COS uploads".

At the time, I used Figma MCP to read the design. How images are compressed, where they're uploaded, and how links are returned is explained by the Skill; confirming the asset list before uploading is the Workflow for this task. Secrets not appearing in code and logs suits staying in long-term rules.

The scripts that actually call the compression service and COS SDK. The AI judges which steps the current task needs and runs them through host tools.

If existing scripts can complete a task, and the Agent can run commands, you can use it this way first. No need to wrap every script in an MCP just to fill out the configuration. Maintaining an extra service before images are even uploaded isn't a good deal.

The old article used the approach of cleaning up source images after successful upload. Now for newcomers designing a similar flow, I would first keep source files, verify remote results, then clean up per convention. Even if secrets are placed in an uncommitted environment file, guard against logs, screenshots, and tool output carrying them out.

2. Rules: write down what gets corrected repeatedly

If you're just starting with AI programming, I'd write a few rules first.

"Don't fix other problems on the side", "Don't count pre-existing workspace changes as this round's work", "If tests weren't run, say they weren't run" — these requirements may have been said many times. When I just want to add a button, I don't expect a surprise refactor of half the repository.

Such requirements fit into long-term instruction files. Claude Code commonly uses CLAUDE.md; Codex and Pi commonly use AGENTS.md. The client decides how files are discovered and at what scope they load.

You can start with a few rules in the project:

# Project collaboration conventions

- Check the workspace before modifying; preserve changes unrelated to the current task.
- Use existing components and dependencies; explain reasons before adding new dependencies.
- On interface failure, keep the error information; don't fake success with empty data.
- Run relevant checks after modifications, and record passed, failed, and not run items.
- Without explicit authorization, don't stage, commit, or push code.

Each rule corresponds to a concrete behavior. When problems occur, it's easy to check which rule wasn't followed. I'd rather write these; whether to first grant the AI a "world-class engineer" title can wait.

Don't let every convention go to work with every task

Preferences that apply to all personal projects go at user level; team-shared build commands and directory conventions go at project level; conventions that only concern the API directory should be limited to that scope as much as possible.

For example, Claude Code can put path-based rules in .claude/rules/api.md:

---
paths:
  - "src/api/**/*.ts"
---

When modifying API calls, follow existing request wrappers.
Don't repeatedly concatenate server addresses in page components.

This is Claude Code-specific syntax; for other tools, check their supported methods.

Splitting into multiple files also requires checking how they load. If the main file directly imports all conventions, the model may still read a lot each time. To reduce irrelevant context, you need path scoping or on-demand read mechanisms supported by the client; just moving files around isn't enough.

Rules need cleanup over time. When a project switches from npm to pnpm, old commands should be updated; temporary constraints added for debugging should be reviewed after the fact.

For actions truly not allowed, saying "forbidden" in Markdown is just an instruction. Permissions, sandboxes, command checks, and CI can intercept at the appropriate stages; what exactly they can block needs verification. Writing "strictly forbidden" three times in a file doesn't automatically add a gate.

3. Skill: for this type of work, follow this next time

When unsure how to write a Skill, I first use skill-designer to structure it. It helps sort out the division of applicability, entry points, and reference materials. In agents like cc, pi, codex, you can request like this:

Download skill-designer

/skill-designer

Help me organize "debugging page issues" into a Skill.
First confirm applicable scenarios and inputs, distinguish read-only analysis from code modification.
List handling methods when connections fail, and checkpoints before delivery.
Explain what goes in the entry, what splits into reference docs, and what fits as scripts.

This is a Skill I use myself; it needs to be installed where the client can discover it. Invocation syntax differs across tools; comparison below.

Once a draft is out, still test with real tasks. Check whether it triggers incorrectly, misses steps, and can honestly stop after failure. A tidy directory and being reliable in actual work are two separate checks.

Which tasks deserve a Skill?

When the same set of requirements starts being pasted repeatedly, or a rework leaves a reusable method, I consider making a Skill. Next time, at least I don't have to dig through chat history.

Image upload, code review, debugging certain interface issues can all be organized. First clarify the task entry and completion criteria, then decide which files are needed.

A common directory looks like:

page-check/
├── SKILL.md
├── references/
│   └── checklist.md
└── scripts/
    └── check-output.mjs

SKILL.md explains when to use it and what steps to follow. Detailed checks can go into references, and stable repetitive computation and validation into scripts. A Skill can exist without scripts; no need to create a row of empty folders to look professional.

A first Skill that states trigger conditions and deliverables is good enough

This is a simplified page-check example to show the writing style, not yet a validated general debugging tool:

---
name: page-check
description: Debug display and interaction issues on a running page. Applies when the user asks to reproduce a page failure; not used when only reading code.
---

1. Identify the target page, running environment, and the anomaly the user sees.
2. Read the project's startup and verification instructions, then open the actual page.
3. Record reproduction steps; check relevant DOM, console, and network requests.
4. Compare against code to locate the cause. Without modification authorization, only give analysis conclusions.
5. After obtaining modification authorization, fix and re-test following the original steps.
6. Deliver the cause, scope of changes, verification results, and unverified items.

When browser connection fails, state the blocker; don't write code inference as actual reproduction.
Detailed checks in references/checklist.md; read when entering page inspection.

It states what to do and how to handle connection failure or lack of modification authorization.

The description should include applicable and non-applicable cases. "Optimize development experience" is too broad; the model can't decide when to use it. With a broad scope, even asking a command might trigger a full physical exam.

"Progressive disclosure" means reading as you go

In Pi-Bolt, the model first sees the Skill's name, description, and path, and reads the full text after deciding to use it. The text can direct it to read corresponding detail materials at a certain step.

Codex and Claude Code also adopt on-demand loading, with differences in fields, discovery rules, and context budgets.

When I made the miniature animation Skill, I separated style, reference image processing, motion checks, audio, and export. Designing scenes didn't require reading the full encoding spec; read it at final rendering.

Download miniature animation Skill

In the article about Skill vs. Prompt and the Xinjiekou miniature animation, I wrote: "Splitting files isn't enough; the entry must clearly state read timing."

As for "is a Skill really a Prompt" — the body is of course still instructions for the model. What I save is the description, materials, templates, and scripts for this type of task, plus when to read them. Changing the file name won't give the model an extra brain.

4. MCP: configure it when external integration is needed

MCP stands for Model Context Protocol. You can understand it as a protocol for clients to connect to tools and data services. A browser service can provide abilities to read pages and inspect requests; a document service provides search and reading; a design tool service provides design information.

After a successful connection, debugging methods, target environment, login state, and permissions still need confirmation. A browser tool can open pages; what to do next—reproduce the issue, inspect requests, or compare code—still needs a methodology.

When is it worth installing

When you want the AI to directly inspect running pages, read designs, or query document services, see if a mature MCP integration exists.

If it's just reading local files, running tests, processing a few images, and the client can already read files and run commands, use existing capabilities first. CLI, SDK, HTTP APIs may all satisfy the need.

This desktop app I developed with Tauri has an easy pitfall: when bridging to inspect the actual UI via MCP, the dev build must be started with the dev-mcp feature. Ordinary dev commands can also open the app, but the bridging ability isn't compiled in. The window looks fine, but the connection just doesn't work—perfect for questioning life.

Such startup requirements fit in a project Skill, so subsequent verification reads the description first.

Connect one read-only service and actually query once

For example, Codex can configure the official documentation MCP in ~/.codex/config.toml:

[mcp_servers.openaiDeveloperDocs]
url = "https://developers.openai.com/mcp"

After configuration, check connection status, then have it query a doc and verify the returned content and source. This official read-only documentation service won't gain access to your database or cloud account.

Claude Code and Pi have different formats and locations; configure per their docs, don't paste TOML verbatim into JSON.

Some MCPs connect via remote URLs; others require starting a local server program communicating through standard input/output, often called stdio. The latter may depend on Node, Python, etc., and involve server installation and file access authorization.

After a name appears in the list, continue checking whether the client read the config, whether the service connected, whether needed tools are callable, and whether results come from the correct environment. Being able to read public pages doesn't mean access to logged-in backends; querying a test database doesn't mean permission to write the production database.

For browsers especially, see which window and session it connects to. I habitually reuse the visible browser to confirm the environment. Whether it launches another browser and which connection modes are supported depends on the specific service.

Chrome DevTools MCP: when inspecting a page, don't log me out

I previously encountered that opening a new AI session popped up a Chrome connection authorization; letting the AI open a webpage switched away from the tab I was viewing. Switching to a separate browser split the login state. I wanted it to inspect a page, but first I had to arrange a seat for it.

The complete configuration and scripts at the time are in: "chrome-devtools-mcp always asks for authorization and hijacks tabs? Here's how I configured it step by step".

That was practice on macOS, Codex CLI, and official package 1.12.0, addressing these issues:

Problem encountered	Solution at the time
Standalone browser lacks daily login state	Used `--autoConnect` to connect the daily Chrome and enable the remote debugging it requires
New sessions repeatedly establish connections and pop authorization	Reused the official CLI's persistent connection via a custom adapter script
New pages hijack the current tab	Adapter script forces background page creation, not activating tabs when switching tool context
Project config hardcodes personal paths	Put Node and launcher personal paths in user-level config, clean up old entries in the project

--autoConnect handles choosing the connection target; the custom quiet launcher forwards calls, reuses the connection, and constrains background operations. Here "quiet" is extra adapter code; no official "quiet switch" covers all these things.

Creating pages in background uses background: true; selecting the task page but not stealing foreground uses bringToFront: false. Besides writing rules to remind, I also fixed these two parameters in the adapter script to reduce omissions.

First connection still requires user permission. After Chrome, the connection, or the persistent process restarts, authorization may be requested again. The client approving tool calls and Chrome allowing remote debugging are two layers of permission; the former cannot replace the latter.

After configuration, test in a new AI session: whether it reuses the original process, whether it can open pages in background, whether the original tab remains selected. Succeeding once in the current session doesn't verify cross-session reuse. Also, don't kill the shared process after every task.

In this configuration, MCP provides browser operations, accompanying Skill describes usage, Rules constrain not to touch user's existing tabs, and adapter code handles connection reuse and fixed parameters. The launcher depends on internal modules of a specific package version; upgrades require joint review and can't be directly applied to all systems.

The more services installed, the more context cost to consider. Tool definitions, call results, and logs can all take space; some clients support tool discovery or lazy loading, so actual cost can't be counted just by number of MCPs. Keep services the current task will use; connection problems are also easier to find.

5. Workflow: write out order and confirmation conditions

Some products call repeatable Markdown steps "Workflow"; others provide workflow engines that save state and execute branches. Organizing a set of steps within a Skill is also designing a workflow.

Thus, a Skill can contain a Workflow: the former is a capability package, the latter describes the execution process. Facing a specific product, check which features are called Workflow.

The street view in the image is illustrative; the actual work is in the previously cited Xinjiekou animation answer. The order I used:

Read reference image, confirm style requirements
Generate four actual sample frames of the same animation
Wait for my confirmation of the current version
Run checks, then render the full film
If visuals or story change, re-confirm

"Let me see first" is too vague. Look at concept art or actual frames? Does approving the vehicle model count as approving the whole film? After changing a shot, is the old approval still valid? If a compliment comes with authorization for the entire film, that's too generous a discount.

Later I added approval records and version checks; before rendering, a program checks whether approval corresponds to the current version. Markdown explains the order to follow; code checks reject requests that don't meet conditions at designated execution entry points.

Development tasks can also be organized this way:

Reproduce the issue and record evidence
Confirm cause and scope of changes
Fix and add relevant tests
Re-test following original steps
Check diff, deliver verification results

Confirmation points go at steps that expand scope, incur cost, overwrite data, or affect external systems. If I have to stop five times to approve a one-line copy change, I can't stand it; parts that can be done continuously, let them run continuously.

When unattended operation, fixed branches, or reliable retries are needed, parts suitable for deterministic execution can be given to scripts, CI, or workflow engines, leaving judgment steps to the AI. A natural-language checklist can't necessarily bear these requirements alone.

6. Memory: next time don't make me explain from scratch

Days later, in a new session, I still want the AI to find previously confirmed conventions: a project temporarily can't upgrade dependencies, an environment can only start in a specific way, or analysis first and code modification only after authorization.

Such information can be saved as Memory. Stable preferences, confirmed decisions, and still-valid environment limits suit long-term retention. Which file was read today, or a test not yet run, fits better as daily logs or task progress. Collecting everything permanently ends up with searching notes within notes.

After saving, also test whether it can be retrieved

The file being called MEMORY.md doesn't mean the model reads it fully every time, nor does it prove content correctness. Check which parts the client loads, whether there's on-demand retrieval, how soon new records take effect, and how old info is modified or deleted.

In Pi-Bolt, I used the pi-memory extension to separate long-term records, daily logs, and to-dos, providing tools for read, write, retrieval, and forgetting. Search also relies on an optional qmd retrieval tool; semantic search for similar content requires corresponding indexes and models. That's my extension setup; installing Pi itself doesn't include this whole memory suite by default.

Claude Code has its own auto memory, differing in write method and purpose from manually maintained CLAUDE.md. Switching to Codex, check what the corresponding version and configs support. Both can read Markdown, but automatic memory sync is still far off.

In a client with memory capability configured, you can request like this:

Remember: in this project, without explicit authorization, don't stage or commit code.
Save as a project long-term convention, tell me where it was written.
Don't store test accounts, secrets, or this round's temporary logs in long-term memory.

Then switch to a new session, ask it what the convention is, where it read it from, and inspect the saved file. Don't relax just because it said "remembered"; my own memory isn't good enough to guarantee that.

Leave scope and reasons, and remember to clean up

A dependency constraint can be recorded like:

Scope: current project's payment dependency.
Conclusion: keep current version for now.
Reason: new version compatibility not yet verified.
Re-evaluate: after compatibility verification, confirm whether to upgrade.

This is illustrative; actual reasons and approvers must come from real discussions, not let the model make up a pleasant reason. When decisions or environments change, update or delete old records; otherwise the same mistake resurrects across sessions with memory.

Rules and memory intersect. "No unauthorized push" can be saved as a personal preference or written as a long-term rule to follow. Memory emphasizes saving and recall; rules emphasize what you want it to obey.

Production operations still require re-verification. Memory can hint at last time's situation, but today's environment may have changed.

7. Commands, scripts, Hooks—what do they each manage?

The same slash entry point, across different tools, can have different mechanisms underneath.

Pi's Prompt Template can turn a frequent prompt into /review. If you just want to avoid pasting a review prompt, a template suffices; if you need reference materials and a full handling method, consider a Skill.

Claude Code has merged custom Commands into the Skills usage system; the old directory remains compatible. Don't assume all /name entries are the same mechanism.

Scripts execute fixed logic. File summarization, data transformation, format validation—work with clear results, I'd rather the Agent call existing scripts than reason from scratch each time.

Hooks execute configured commands or checks when an event occurs, suitable for reminders or interception at designated stages. Which entry points a Hook covers requires verification against host implementation. Writing "check before tool calls" in a Skill doesn't automatically generate a Hook; installing a Hook doesn't mean all operations are safely isolated.

Plugins can package Skills, connections, and other resources for distribution. Pi extensions can also register tools or respond to events, extending host capabilities. Use them when the task at hand needs these capabilities; no need to decorate the editor into a tool exhibition in advance.

8. How to land on Pi, Codex, Claude Code?

Common local entry points below. ~ is the user home directory; configs in project directories apply to that project. Loading behavior is still affected by version and settings.

Tool	Common instruction file	Common Skill location	Explicit invocation example
Claude Code	User-level `~/.claude/CLAUDE.md`, project-level `CLAUDE.md`	User-level `~/.claude/skills/`, project-level `.claude/skills/`	`/page-check`
Codex	User-level `~/.codex/AGENTS.md`, project-level `AGENTS.md`	User-level `~/.agents/skills/`, project-level `.agents/skills/`	`$page-check`, also selectable from `/skills`
Pi (I use Pi-Bolt)	User-level `~/.pi/agent/AGENTS.md`, project-level `AGENTS.md`	Supports `~/.agents/skills/`, project `.agents/skills/`, etc.	`/skill:page-check`

I run pi-bolt locally, refreshing with /reload after modifying Skills. Upstream Pi, Pi-Bolt, different versions, and installed extensions have differences; what works on my machine may not all be default bare Pi.

Claude Code currently also conditionally supports reading AGENTS.md, affected by version, whether the project already has CLAUDE.md, and related settings. When sharing conventions across tools, verify actual load sources; for compatibility, you can include shared content in CLAUDE.md via @AGENTS.md.

Share content as much as possible, handle integration differences separately

I try to have multiple tools read the same Skill, placing entities in a shared directory and creating links for tools that need dedicated entries, avoiding copying three copies that each grow different personalities. Check existing files before creating links; don't overwrite.

Content still needs review. Claude Code-specific fields and hardcoded tool names may not apply in Codex or Pi. Task descriptions, reference materials, and ordinary scripts are relatively easy to share; host-specific behaviors need adaptation.

My earlier "Claude Code basics sharing" compiled experience with Rules, Skill, MCP, and shared directories; check against current version docs.

Occasionally check which file is actually being read

My own Sessions Viewer aggregates Skill and MCP configuration, used to inspect entity directories and reference relationships. Multiple entry points for the same Skill and several diverged copies of content need separate handling.

Project source · Release download

MCP servers with the same name may also have different parameters. The token in the image is the estimated context cost of definitions; configuration status doesn't prove the current session is connected; still verify with an actual call. You can inspect files directly instead of management UIs.

9. After installing, how to verify?

Use the same set of images as a comparison: first give requirements directly, then with the Skill, see whether steps are missed and results are easier to verify. Also try missing secrets, existing files, upload failure—whether it stops where it should.

After the normal flow works, continue testing false triggers, tool disconnects, and users changing requirements mid-task. These situations are more likely to expose design flaws.

Downloaded Skills should be reviewed together with referenced files and scripts; MCP services also need source and permission verification. A manual saying "safe" can't guarantee the actually executed code. Test in a test directory, test account, or suitable isolated environment first; pay particular attention to deletions, overwrites, uploads, and credential reads.

I made a wrap-up report Skill called ask-report-html. Because long tasks always made me re-read records to find what changed, what was tested, what wasn't verified—more like detective work than debugging.

Specific design and installation in this hands-on answer about ask-report-html.

The Skill handles content and generation method; rules say when to call it; Workflow requires organizing at the delivery stage. When continuing in a new session, saved task records help restore progress.

Without browser verification, write "not run". Generating an HTML file doesn't prove business passes; a pretty report can't sign for checks not run. Like cleaning files after successful upload, completion criteria must be verifiable.

I'll keep watching whether repeated explanations and rework decrease, whether failures leave enough information, and whether results are easier to verify. How many tools are installed doesn't replace these judgments.

10. Want to try today? Where to start?

Pick a small task at hand, first use the existing Agent. Where it makes you repeatedly explain, or where a step always needs manual handoff, add corresponding configuration.

When the same requirement always gets corrected, write a rule; when a type of task repeatedly requires explaining steps, organize a Skill. When existing capabilities can't get external information, add MCP. When long tasks show confirmation conditions and failure branches, write out the Workflow. When returning after a while still requires re-explaining confirmed info, consider saving to memory.

Concretely:

Write a short project instruction with only frequently used conventions.
Turn an already-done, repeatable task into a Skill with clear scope and deliverables.
For external integration, connect only one service and verify actual return results.
Add confirmations for steps that spend money, overwrite files, or affect external systems; test whether it stops on failure.
In a new session, check whether key conventions are retrievable; update stale info.

Doing the first two steps is already good. Add more when tasks need it, so that instead of getting the AI to write code, you end up with a new job maintaining configuration.

Summary

In one development task, Rules keep long-term conventions, Skill preserves methods for this type of work, MCP connects tools and data, Workflow conveys order and confirmation conditions, and Memory helps the next session retrieve confirmed info. They can work together, or you can use just one or two.

Whether it's used well still depends on whether the task misses steps, results are verifiable, and errors honestly stop. Trying one real small task beats checking boxes against a configuration list.

Two Skill attachments

skill-designer download: helps you organize a Skill's applicable scenarios, content structure, and checkpoints.
Miniature animation Skill download: the skill used in the Xinjiekou case; preview frames first, confirm, then render.