mirror of
https://github.com/Vateron-Media/XC_VM.git
synced 2026-10-04 04:02:30 +02:00
62 lines
2.3 KiB
Markdown
62 lines
2.3 KiB
Markdown
# Copilot Instructions
|
|
|
|
Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.
|
|
|
|
Tradeoff: these guidelines bias toward caution over speed. For trivial tasks, use judgment.
|
|
|
|
## 1. Think Before Coding
|
|
|
|
Do not assume. Do not hide confusion. Surface tradeoffs.
|
|
|
|
Before implementing:
|
|
- State your assumptions explicitly. If uncertain, ask.
|
|
- If multiple interpretations exist, present them. Do not pick silently.
|
|
- If a simpler approach exists, say so. Push back when warranted.
|
|
- If something is unclear, stop. Name what is confusing. Ask.
|
|
|
|
## 2. Simplicity First
|
|
|
|
Use the minimum code that solves the problem. Nothing speculative.
|
|
|
|
- No features beyond what was asked.
|
|
- No abstractions for single-use code.
|
|
- No flexibility or configurability that was not requested.
|
|
- No error handling for impossible scenarios.
|
|
- If you write 200 lines and it could be 50, rewrite it.
|
|
|
|
Ask yourself: Would a senior engineer say this is overcomplicated? If yes, simplify.
|
|
|
|
## 3. Surgical Changes
|
|
|
|
Touch only what you must. Clean up only your own mess.
|
|
|
|
When editing existing code:
|
|
- Do not improve adjacent code, comments, or formatting.
|
|
- Do not refactor things that are not broken.
|
|
- Match existing style, even if you would do it differently.
|
|
- If you notice unrelated dead code, mention it. Do not delete it.
|
|
|
|
When your changes create orphans:
|
|
- Remove imports, variables, and functions that your changes made unused.
|
|
- Do not remove pre-existing dead code unless asked.
|
|
|
|
The test: every changed line should trace directly to the user's request.
|
|
|
|
## 4. Goal-Driven Execution
|
|
|
|
Define success criteria. Loop until verified.
|
|
|
|
Transform tasks into verifiable goals:
|
|
- Add validation -> write tests for invalid inputs, then make them pass.
|
|
- Fix the bug -> write a test that reproduces it, then make it pass.
|
|
- Refactor X -> ensure tests pass before and after.
|
|
|
|
For multi-step tasks, state a brief plan:
|
|
1. [Step] -> verify: [check]
|
|
2. [Step] -> verify: [check]
|
|
3. [Step] -> verify: [check]
|
|
|
|
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
|
|
|
|
These guidelines are working if there are fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.
|