How to Make Continue Write a Rule From the Conversation You Just Had (2026 Guide)

Instruction files are written in advance, by someone imagining what an agent will need. That is a reasonable thing to do and it captures the stable stuff — build commands, style, review steps. It systematically misses everything else, because the things that actually trip an agent up are not knowable until it trips.

Continue is clear about what a rule is for: rules "provide system message instructions to the model for Agent mode, Chat, and Edit requests," and "to form the system message, rules are joined with new lines, in the order they appear in the toolbar." A rule is prompt-level configuration, re-sent every request. That framing is accurate, and it explains why writing rules from imagination produces thin ones. You are guessing at the contents of a system message.

The correction is different. It arrives with everything a good rule needs already attached: a specific behavior that was wrong, the right behavior, and — if you say it out loud, which people usually do when they are annoyed — the reason. "Don't use the batch endpoint for reconciliation because it times out over ten thousand rows." That last clause is what makes the rule survive contact with a future decision. A bare prohibition gets overridden the first time it is inconvenient.

The problem has never been that people do not know this. It is that writing it down is a second task, performed at the moment you have the least appetite for a second task. Which is exactly what a tool call is for.

Retyping the constraint every session. This is the default, and it works, in the sense that the code comes out right. What it costs is that the constraint has a half-life equal to your memory of it, and it is invisible to everyone else on the team. The general shape of this problem is covered in how to stop re-explaining context to AI.

One large always-on rules file. Everything learned goes into a single rule with alwaysApply: true. It never fails to be present, and that is the problem — after a few months the model receives several thousand words of accumulated corrections on every request, most irrelevant to the task, and the ones that matter compete with the ones that do not. Keeping less in front of the model is usually the better trade, which we argued in agent memory and keeping less.

Writing it into the README or a design doc. Correct instinct, wrong container. Continue reads rules from .continue/rules; a README is not in the system message unless something puts it there. The knowledge is preserved for humans and absent for the agent.

Trusting the conversation. The correction is right there in the chat, so surely the model has it. It does, for this session. Continue's rules exist because that is the boundary — instructions are re-supplied per request, and a chat is not a store. We go into why in why agents ignore your instruction files.

Reaching for a skill. Skills package a procedure. A correction is not a procedure, it is a fact about your codebase, and the distinction matters more than it sounds — see why agent skills aren't memory.

Step 1: Turn on rule creation and use it in the same breath as the correction

create_rule_block is a tool the agent calls, and Continue's docs note it works "if enabled" — so confirm it is available in your Agent mode tool list before you rely on it. Continue also offers an "Add Rules" button for creating rules by hand, which is the fallback when you want to write one from scratch rather than from a conversation.

The usage pattern that works is to correct and capture in one move. Instead of "no, use the streaming parser here" followed by moving on, say "no, use the streaming parser here — the batch endpoint times out over ten thousand rows. Create a rule for that." The agent writes a rule into .continue/rules derived from the conversation it just had, which means it has the reason as well as the instruction.

Two things to check on the generated file, because they determine everything in Step 2. Continue's docs say rules "should be .md files with proper YAML frontmatter," and that the folder must be .continue/rules/ — not .continue/rule/, a typo their troubleshooting section calls out specifically. Then read the frontmatter the agent wrote. It will have made a choice about globs, description, and alwaysApply on your behalf, and that choice is a guess.

Continue is not alone in offering this; Cursor has a /create-rule command that does something similar. What Continue documents more clearly is the retrieval side, which is where the interesting decisions are.

Step 2: Pick the retrieval behavior on purpose

Continue's three frontmatter fields interact to produce three distinct behaviors, and the documentation spells them out.

With alwaysApply: true, the rule "is always included." Use this only for constraints that are true regardless of what you are touching. A correction about the reconciliation endpoint is not one of them.

With alwaysApply: false, the rule is "included if globs exist AND match file context, or the agent decides to pull the rule into context based on its description." This is the mode most captured corrections want, and it has two independent triggers. If you know which files the constraint governs, set globs — Continue's docs describe globs as matching "when files are provided as context." If the constraint is about a concept rather than a path, lean on description, and write it as a retrieval query rather than a summary. Continue is explicit that "agents may read this description when alwaysApply is false to determine whether the rule should be pulled into context." A description reading "reconciliation constraints" will not fire when you are working on a nightly settlement job. One reading "constraints on bulk endpoints, reconciliation, settlement, and anything paging over large row counts" will.

Leaving alwaysApply out entirely gives you the default: "included if no globs exist OR globs exist and match." That means a rule with no globs and no alwaysApply is on all the time — which is a reasonable default and a bad accident. If the agent generated a file with no frontmatter, you have created an always-on rule without deciding to.

One ordering detail worth knowing: "rules files are loaded in lexicographical order, so you can prefix them with numbers to control the order in which they are applied," using names like 01-general.md and 02-frontend.md. Since rules are joined into one system message, order is precedence in practice. Captured corrections generally belong late, after your general conventions, so they read as refinements rather than being contradicted by something more general further down.

Step 3: Separate the rules from the facts before the folder fills up

After a few weeks of capturing, read your .continue/rules folder and ask of each file: is this a convention or a fact?

A convention says how work is done here — naming, error handling shape, which test runner. It is stable, it applies broadly, and it is exactly what a system message is for. Keep it. Domain knowledge that is stable but large is a third case, and belongs in a store rather than a prompt, as in giving Claude permanent domain knowledge.

A fact says what happened. "We moved off the streaming parser in July after the memory regression." "The vendor sandbox needs the fixture server, so payments tests use a different command." "We tried two fixes on the flaky integration test; both failed for the same reason." These have properties conventions do not: they accumulate without limit, they get superseded rather than edited, and most of them are relevant to a handful of tasks a quarter.

Facts stored as rules go stale invisibly. Nothing tells you a rule is describing a decision that was reversed in August, and a reversed decision presented as a system message instruction is worse than no rule at all. This is the same failure that makes review-history systems drift, which we looked at in agents that improve from feedback.

Continue's documented mechanisms — rules, with these three retrieval modes — cover conventions well. There is no documented counterpart in them to a store that holds an accumulating, supersedable record of what a team established. That is a scope statement about the rules system, not a criticism of it; a system message is the wrong shape for that job in any tool.

MemoryLake is where the facts half goes: a store outside the repository that holds established decisions, supports supersession instead of silent staleness, and is readable over MCP or an API from whichever agent you are running.

Step 1: Create an API key

Generate a key and make your first request in about thirty seconds. The same key works from Continue, from a teammate's editor, and from CI.

Step 2: Upload your first memories

Drop in the documents, images, and files that already hold your project's decisions — the incident writeup behind the current retry policy, the design review nobody wants to repeat, and the rule files you just identified as facts rather than conventions.

Step 3: Connect your AI & agents

Give Claude, Codex, OpenClaw, and other agents access over MCP or the API. In Continue, that means the established facts are retrieved when relevant instead of living permanently in your system message.

Your rules folder stops growing without bound. Once facts have somewhere else to go, .continue/rules settles at the size of your actual conventions — which for most repositories is small, readable, and reviewable in a pull request.

Descriptions get written for retrieval rather than for filing. When the only thing a description has to do is help the agent decide whether to pull the rule in, you write it differently, and the rules you keep start firing when they should.

Corrections outlive the repository. A rule lives in one checkout. A fact captured outside it is available when the same constraint shows up in the service next door, which is where most of the repeat explaining actually happens.

And the capture habit gets cheap enough to keep. That is the real unlock in create_rule_block: the cost of writing something down drops to four words. Whether it comes back correctly is a separate decision, and you can now make it deliberately.

Always include the reason. "Don't use X" gets overridden. "Don't use X because Y" does not.

Never leave frontmatter to chance. Read what the agent generated. A file with no globs and no alwaysApply is on for every request.

Write descriptions as queries, not labels. The description is the retrieval signal when alwaysApply is false. Include the words you would actually type.

Number your rule files. Lexicographical load order is real precedence. Conventions early, refinements late.

Prefer Markdown files. Continue notes rules were originally defined in YAML but recommends the Markdown form now; keeping to one format makes the folder reviewable.

Re-read the folder monthly. Not to prune conventions, but to catch facts that have quietly become wrong.

create_rule_block solves a real problem that most tools leave to discipline: it removes the friction between noticing a constraint and recording it. Say "create a rule for this" and the correction becomes a file with the reasoning attached, which is more than most hand-written rules manage.

The half that is left to you is retrieval, and Continue gives you the pieces to do it properly — globs for path-scoped constraints, description for concept-scoped ones, alwaysApply for the few things that are unconditional, and lexicographical ordering for precedence. Use them deliberately, especially on files an agent generated, because a rule that never fires and a rule that never stops firing fail in opposite directions and both look like a full rules folder.

Then do the sort that keeps the whole thing healthy. Conventions belong in the system message. Facts belong somewhere that can hold a growing, correctable record and hand back only the part that matters. Getting that boundary right is what keeps a capture habit from turning into a directory nobody reads.