In this article
Continue rules provide project guidance in .continue/rules; model roles and tools remain configuration concerns, and a rule alone does not enforce a command policy.
A project rule tells Continue how work should be approached in a repository. It can describe conventions, generated files or required checks. That is different from selecting a model and from enforcing a tool permission. Keeping these concerns separate makes a local coding setup easier to move between projects and maintain over time.
Put repository guidance in the documented location
The Continue Rules guide identifies .continue/rules for local project instructions. Keep rules with the repository when they describe its conventions. A rule about one application’s migration process should not become a global instruction for every unrelated project on the same workstation.
Start with a narrow factual convention, such as which source file generates an API client. Describe the intended edit location and why. Prefer a useful repository fact over a broad demand that the model always be correct, which supplies no additional context for deciding what to change.
Keep model configuration independent
The current YAML configuration reference describes configuration fields and model roles. A rule asking for a local model does not establish the runtime connection, model identifier or role assignment. Those values must exist in the active configuration.
For a developer using separate chat and completion models, verify each role through its own workflow. Then evaluate the repository rule in the mode where it is expected to apply. A successful chat response does not prove that another feature used the same model or received the same instructions.
Inspect old examples before migrating them
Continue’s current documentation marks earlier JSON and context-provider material as deprecated. The rules deep dive is a better basis for current rule behavior than copying a historical setup file without identifying its generation.
Inventory the old setup by purpose: repository instruction, model connection, retrieval behavior or tool configuration. Move each part into its currently documented mechanism. Renaming a file is not a complete migration if the original example also depended on a context feature that is no longer selected.
Use a deliberate contradictory fixture
Create a disposable repository with a generated client file and its small source definition. Ask for a change that might tempt an assistant to patch the generated output. Inspect whether the rule steers the edit toward the intended source.
Then test a neighboring file where the rule should not add unrelated work. This catches instructions that are too broad. Review both the explanation and the diff: a model can repeat the rule in prose while editing the wrong file. Keep the fixture small enough that a human can see the distinction.
Separate a useful instruction from a guarantee
Rules enter the agent’s context. They do not independently create a filesystem boundary, install dependencies or prove that a required test ran. Enforce important conditions through the appropriate environment or repository checks and inspect their results.
Keep the rule revision, Continue version and effective configuration together when diagnosing a change in behavior. Update stale file paths and remove conflicting instructions. A concise, accurate rule set helps a local model use project knowledge; a growing collection of historical demands can instead make the intended workflow harder to identify.
Related reading
Reproducible inference stacks: preserving a GPU pilot’s result, Coding LLMs on 12GB VRAM: Budget Context and Headroom.