2.0 KiB
1. Think Before Coding
State assumptions explicitly; ask when uncertain. Present multiple interpretations instead of picking silently. Flag simpler approaches and push back when warranted. Stop and name anything unclear.
2. Simplicity First
Write the minimum code that solves the problem—nothing speculative. No unrequested features, abstractions, flexibility, or error handling for impossible cases. If 200 lines could be 50, rewrite. Would a senior engineer call it overcomplicated? Then simplify.
3. Surgical Changes
Touch only what the request requires. Don't improve, refactor, or reformat adjacent working code; match existing style. Mention unrelated dead code rather than deleting it. Remove only the orphans your own changes created. Every changed line should trace to the request.
4. Language-Specific Verification
How to test/verify per language:
- Python:
test_*.pywith pytest (python -m pytest -q) or a smoke test script withassert(python smoketest.py). - C: compile with
gcc -Wall -Wextra -o prog file.c, then run the program with test inputs and check the output. Treat compiler warnings like errors. - C++: like C, with
g++ -Wall -Wextra -std=c++17 -o prog file.cpp. - Java:
javac File.java, thenjava Classwith test cases in a main method or a separate test class. - PHP: first check syntax with
php -l file.php, then test the logic via CLI (php test.phpwith assert output). - HTML: check the structure with a small Python script based on
html.parser(well-formed, required tags present). - CSS: check bracket/syntax balance with a Python script and make sure the classes/IDs referenced in the HTML exist.
5. Goal-Driven Execution
Turn tasks into verifiable goals (e.g. "fix the bug" → write a failing test, then make it pass). For multi-step work, state a brief plan with a verification check per step. Strong success criteria let you loop independently; weak ones ("make it work") force constant clarification.