A coding model can produce valid code that still looks foreign in your repository. It might introduce a new abstraction, rename familiar concepts, or handle errors differently from neighboring modules. The practical fix is not a longer prompt full of preferences. Give the agent a small, reliable map of your conventions, then verify its work with the same checks your team uses.
Start with a style audit of one real module
Choose a maintained module that represents the code you want more of. Avoid generated files, abandoned experiments, and unusually complex infrastructure. Inspect its public interfaces, tests, error handling, imports, and dependency boundaries.
Separate mechanical rules from design decisions. A formatter can settle indentation; it cannot decide whether a service should return a domain error. Record both, but make clear which checks are automated and which require judgment. When existing code conflicts, identify the current preferred pattern instead of asking the model to imitate everything.
Write repository instructions the agent actually reads
Put durable guidance in the instruction file supported by your coding tool. Common examples include CLAUDE.md for Claude Code and AGENTS.md for Codex. File discovery, nesting, and precedence differ between tools, so check their current documentation and confirm which instructions are loaded. Do not assume one filename works everywhere.
Keep the root instructions short. Explain the repository layout, essential commands, architectural boundaries, and a few nonnegotiable rules. Add scoped guidance for directories with genuinely different conventions, using the tool's supported mechanism.
- State an observable rule: “Route handlers validate input, call a service, and translate domain errors into responses.”
- Name a boundary: “Database access belongs in repositories, not route handlers.”
- Give a verification command: Include the exact formatting, linting, type-checking, and test commands that work in this repository.
- Explain exceptions: Identify legacy areas that should not become templates for new work.
Pair each important convention with a reference file
Examples make instructions concrete. Point the agent to one representative implementation and its tests for each common task: adding an endpoint, introducing a component, or extending a background job. Prefer file paths and a short explanation over copying entire files into every prompt.
Tell the agent what to notice. “Follow the dependency injection pattern in this service” is more useful than “make it consistent.” Ask it to inspect the referenced files before editing. Keep examples compact, current, and free of credentials or customer data.
Turn a feature request into a bounded editing task
A useful task prompt specifies the behavior, likely files, reference implementation, constraints, and acceptance checks. For example: “Add cancellation support to the export service. Follow the existing import service's error handling. Preserve the public response shape, add cancellation tests, and avoid unrelated refactoring.”
For larger changes, ask for a brief plan before implementation. Review the proposed boundaries, not just the syntax. If the agent needs a new dependency or architecture change, require explicit approval rather than letting a style-matching task expand silently.
Make style adherence testable during review
Run deterministic checks after edits, and ask the agent to report what actually ran. A suggested command is not a passing result. Review the diff for issues automation misses: unnecessary abstractions, inconsistent terminology, swallowed errors, and changes outside the requested scope.
Keep a small set of representative tasks as a repeatable evaluation. When instructions change, rerun those tasks and inspect the resulting diffs. Turn recurring corrections into concise rules or better examples. Remove contradictory guidance instead of accumulating an ever-longer instruction file.
Keep the style map stable when changing models
This workflow supplies context; it does not permanently train the model. Keep instructions and examples versioned with the repository, and verify that each session receives them. If you try different models, hold the task, context, and acceptance checks steady.
SwiftRelay fits that workflow with pay-as-you-go, per-token access through Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs. Sign up for SwiftRelay to use the small gift credit available to new accounts and try a representative repository task. Judge the result by a clean diff and passing checks, not by confident prose.