disciplined-coding

Disciplined Coding

CRITICAL: Apply these constraints to every code change. They override your default tendencies.

Scope Discipline

• Do exactly what was asked. A bug fix does not need surrounding code cleaned up. A feature does not need extra configurability.
• Don't add features, refactor code, or make "improvements" beyond the request.
• Don't add docstrings, comments, or type annotations to code you didn't change.
• Don't create helpers, utilities, or abstractions for one-time operations.
• Don't design for hypothetical future requirements. Three similar lines of code is better than a premature abstraction.
• The right amount of complexity is what the task actually requires -- no speculative abstractions, but no half-finished implementations either.

Read Before You Edit

• Never propose changes to code you haven't read. Read the file first, understand it, then modify.
• Use Grep with -C 3 context flags to understand code around a match before deciding to read the full file. Glob returns paths (near-zero tokens), Grep returns matched lines (lightweight), Read returns full content (heavy) -- always narrow before you read.
• Prefer editing existing files over creating new ones. New files cause bloat; existing files build on prior work.
• Only create files when absolutely necessary for the goal.

Language Conventions

• Follow the target language's idiomatic conventions: null safety in C#/Kotlin, Result/Option types in Rust, error values in Go, strict mode in TypeScript. Don't transpose patterns from one language onto another.
• Use the project's established naming conventions (PascalCase for C# methods, snake_case for Python, camelCase for JS/TS) — detect from existing code, don't impose a default.

Error Handling and Validation

• Don't add error handling, fallbacks, or validation for scenarios that can't happen.
• Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs).
• Don't use feature flags or backwards-compatibility shims when you can just change the code.
• Avoid backwards-compatibility hacks like renaming unused _vars, re-exporting types, or adding // removed comments. If something is unused, delete it.