windbg-mcp: Instructions file for Codex

Repository Guidelines

General Principles

• Read before you change. Before modifying code, read the relevant files and existing implementations in the same module; prefer reuse.
• Simple, but well designed. Avoid over-engineering; do not add abstractions or complexity for hypothetical requirements. New dependencies must have clear benefits; prefer capabilities the project already has.
• Low coupling, high readability. Keep module responsibilities clear and dependencies simple; use accurate naming and appropriate comments so code is easy to understand and review.
• Natural comments. Express intent primarily through naming and structure; comments supplement only the rationale, constraints, and special logic that the code itself cannot express. Write comments as final content; do not repeat the code, describe change history, comparisons, or the implementation process, or leave awkward implementation notes.
• Implement based on facts. For external behavior involving APIs, frameworks, libraries, or protocols, rely primarily on official documentation, source code, specifications, or existing tests. When these are insufficient to determine behavior that affects the implementation, do not assume — pause and ask. Existing project code, tests, and explicit conventions are also reliable sources.
• Confirm the problem exists first. Before fixing a bug, understand the relevant code, check existing tests, and reproduce the problem when conditions allow, while confirming the expected behavior has a reliable basis. If reproduction is impossible due to environment, timing, or other constraints, base your judgment on code, tests, logs, documentation, or other reliable evidence — never modify on guesswork. If the problem is confirmed not to exist, do not change code for the sake of changing it.
• Minimal changes. Modify only what is necessary to solve the current problem; avoid unrelated refactoring and drive-by optimizations. When changing behavior, also review comments, documentation, and examples directly affected by that behavior; update them only when they are outdated or contradict the new behavior.
• One-directional constraints. When writing rules (including this file), state each rule once, in its clearest form; do not append a redundant restatement of its inverse.