A coding model can produce working code that still feels foreign to your repository. The fix is not a longer request to “follow best practices.” Give it concrete examples, explicit constraints, and a repeatable feedback loop. This first lap builds a small style kit you can reuse across tasks without fine-tuning a model.
1. Pick one representative change as your practice lap
Choose a narrow task: add an optional filter to an existing endpoint, extend a validation rule, or add one test case. Avoid starting with a new subsystem, where architecture decisions can obscure style problems.
Before asking for code, write down what successful integration looks like. For an endpoint change, that might mean preserving the response shape, using the existing validation helper, and adding tests beside the current endpoint tests. These become acceptance criteria, not suggestions.
2. Collect three examples worth copying
Select a recent implementation file, its tests, and a neighboring module with similar responsibilities. Prefer code your team currently endorses over whichever file is easiest to find.
- Implementation: Show naming, function size, imports, and error handling.
- Tests: Show fixture setup, assertion style, and test naming.
- Neighboring module: Show where shared logic belongs and which abstractions already exist.
Tell the model why each example matters. “Use this test file as the pattern for setup and assertions” is more useful than attaching several files without explanation. Exclude secrets, production records, and unrelated configuration.
3. Turn observed conventions into a short style brief
Create a version-controlled instruction document with rules you can verify in review. Separate mandatory constraints from preferences, and resolve contradictions before handing it to the assistant.
A useful brief might say: “Preserve public function signatures unless requested. Use the existing validation helper for request input. Return domain errors through the established error mapper. Keep tests beside the implementation. Do not introduce dependencies without approval.”
Add preferences only when examples support them. “Prefer early returns for invalid input” is actionable; “write elegant code” is not. Include the relevant reference paths so the assistant can inspect the underlying patterns rather than treating your summary as the whole repository.
4. Load the brief through your coding tool
Use your assistant’s supported repository-instruction mechanism, and check its documented filename, directory scope, and precedence rules. These differ across tools. For a portable fallback, explicitly ask the assistant to read your style brief and reference files before making changes.
SwiftRelay fits here if you want to use Claude Code, Codex, Gemini CLI, or an OpenAI-compatible SDK through one relay. Sign up for SwiftRelay to try this workflow with its small new-account gift credit. Keep the style kit in your repository so your conventions are not tied to a particular provider.
5. Ask for a convention check before the patch
Start with a planning prompt: “Read the style brief and reference files. List the conventions relevant to this task, identify the files you expect to change, and flag any conflicting guidance. Do not edit yet.”
Review that response for misunderstandings. If the model proposes a new helper despite an existing equivalent, point it to the established implementation. Then request the smallest patch that satisfies the acceptance criteria, without unrelated cleanup.
6. Review the diff against evidence, not confidence
Run your repository’s formatter, linter, type checker, and relevant tests. Ask the assistant to distinguish checks it actually ran from checks it could not run. Passing tests do not establish style compliance, so inspect the diff too.
Look for unnecessary exports, renamed symbols, unfamiliar error paths, and tests that bypass normal fixtures. Give corrective feedback with a reference: “Use the shared error mapper, as the neighboring endpoint does.” Request a focused revision rather than regenerating the entire change.
7. Save recurring corrections and test a fresh task
When the same correction appears repeatedly, add a concise rule and a reference example to the style brief. Do not turn every review comment into a permanent instruction; task-specific requirements belong with the task.
Finally, start a fresh session with a second small change. If the assistant finds the right examples and follows the rules without extra coaching, your style kit is becoming reusable. You are not permanently retraining the model: you are making your project’s expectations explicit, available, and testable.