Coding Posture

Coding Posture

Pick a working mode that fits the task, state it, and follow its checklist. A mode is a short procedure for a situation models tend to get wrong — not a role to play.

How to use

1. Before non-trivial coding work, scan the modes and pick the one matching the task's dominant risk. If none fit, proceed normally — "no mode" is a valid choice. Skip this for trivial one-line edits and non-coding tasks.
2. If the task is underspecified in a way that changes the implementation, ask before coding — models rarely notice their own missing requirements, and one clarifying round is cheaper than the wrong build.
3. State your choice in one line: Mode: <name> — <reason>.
4. Follow its checklist while planning and editing.
5. If the risk class changes mid-task (a "quick fix" turns out to touch auth), switch modes and say why.
6. A mode tunes how you work. It never overrides instructions or authorizes unsafe actions.

Priority: system/safety > user instruction > project rules > task plan > mode > style

Always (every mode)

• Never run destructive git/deploy/data commands — force push, reset --hard, drop, delete, truncate, rm -rf — without explicit scope. Inspect state before mutating.
• Verify by running the real check (test, build, repro), not by re-reading your own work. Re-checking without external feedback fixes some errors and introduces others — ground every claim of "done" in executed output. If you cannot run the check, say so and mark the result unverified; never assume it passed.
• Never report a result you did not run, and never accept a check that does not exercise the case in question. A test that passes without touching the bug is not verification.
• Never weaken, delete, skip, or special-case a test — or hard-code an expected value — to turn it green. Solve the task, not the grader.

The loop that works

The pattern with the strongest evidence behind it for coding agents: gather context → localize → smallest change → run the real check → read the actual output → repeat. Read the surrounding code and establish a baseline before editing — agents that rush to patch in the first few steps fail more often. Tight execution-feedback loops are where agents outperform; precise localization (down to the lines) predicts a correct fix; keep each diff small so the loop's signal stays clean.

Modes

debug — failing test, bug, regression, traceback

• Reproduce the failure before editing — ideally a command or script that triggers it on demand.
• State the observed failure exactly (command + output).
• Localize to the smallest region — ideally the specific lines — before editing. Precise localization is the strongest predictor of a correct fix.
• Change one hypothesis at a time.
• Prefer the minimal fix over a broad refactor.
• Verify against the original failing command before declaring done.

fix — small, known, urgent change

• Keep the diff as small as the problem allows; no opportunistic cleanup.