| name | code-modification-guidelines |
| description | Use this skill whenever modifying an existing codebase. Ensure all changes are safe, minimal, backward compatible, and consistent with the existing project. |
Code Modification Guidelines
When modifying an existing codebase, follow these rules.
Core Principles
Make the smallest possible change
ONLY modify code that is necessary to accomplish the user's request.
NEVER:
- Modify unrelated code.
- Refactor unrelated modules.
- Rename symbols without necessity.
- Reformat existing code.
- Perform subjective improvements or opportunistic optimizations.
Preserve existing behavior
Unless the user explicitly requests otherwise, preserve the existing behavior.
NEVER:
- Change function signatures.
- Change public APIs.
- Change return values or structures.
- Change synchronous or asynchronous behavior.
- Change error handling semantics.
- Change execution order or side effects.
Treat backward compatibility as the default.
Preserve project conventions
Follow the project's existing conventions.
ALWAYS:
- Use the existing coding style.
- Use the existing architecture.
- Use the existing libraries and patterns.
NEVER introduce a different style or architecture unless explicitly requested.
Make behavior changes explicit
Behavior changes MUST be intentional and visible.
NEVER:
- Silently change business logic.
- Introduce undocumented behavior changes.
- Assume requirements that were not stated.
If a requested change is potentially breaking, clearly explain the impact before implementing it.
Prefer safety over optimization
System stability is more important than code cleanliness.
When in doubt:
- Prefer conservative changes.
- Prefer compatibility.
- Prefer predictable behavior.
Required Workflow
Before modifying code:
- Understand the purpose of the existing code.
- Understand its dependencies.
- Evaluate the scope of the change.
- Consider possible side effects.
During implementation:
- Change only what is necessary.
- Keep unrelated logic untouched.
- Minimize the affected scope.
- Avoid cascading modifications across modules.
After implementation:
- Ensure the change is testable.
- Ensure behavioral changes are observable.
- Consider regression risks.
Allowed Changes
Typical acceptable changes include:
- Fixing confirmed bugs.
- Implementing the user's requested behavior.
- Adding required defensive checks.
- Removing confirmed dead code.
- Adding missing dependencies required for the requested change.
Prohibited Changes
NEVER:
- Rewrite working code without a clear reason.
- Modify unrelated files.
- Introduce unnecessary dependencies.
- Replace existing libraries or frameworks.
- Perform large-scale refactoring.
- Change project-wide coding style.
- Modernize code without being asked.
- Introduce breaking changes without explanation.
- Infer or implement requirements that the user did not specify.
Language-Specific Rules
Respect the semantics of the target language.
Examples:
- JavaScript / TypeScript: Preserve
this binding and asynchronous behavior.
- Python: Preserve existing structure and coding style.
- Java: Preserve package structure and serialization compatibility.
- Go: Preserve the existing error handling pattern.
- Rust: Avoid unnecessary lifetime changes.
- C / C++: Preserve memory semantics.
- Shell: Preserve exit codes and environment behavior.
Summary
When modifying existing code:
- ALWAYS understand before changing.
- ALWAYS minimize the scope of changes.
- ALWAYS preserve existing behavior by default.
- ALWAYS follow the project's conventions.
- NEVER modify unrelated code.
- NEVER introduce unnecessary refactoring.
- NEVER make implicit behavior changes.
- NEVER assume requirements that the user did not specify.
