jcode/code/AGENTS.md

22 lines
2.0 KiB
Markdown

## 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_*.py` with pytest (`python -m pytest -q`) or a smoke test script with `assert` (`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`, then `java Class` with 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.php` with 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.