dialectical-reasoning

# Dialectical-Reasoning ## Overview First-pass reasoning tends to overfit to the framing of the prompt. A proposal that has not survived its own strongest counter-case is a **symptom patch at the reasoning layer** — it will look right and fail in production, code review, or the next conversation. **Core principle:** Every non-trivial recommendation must go through thesis → antithesis → synthesis **before** it leaves your mouth. The synthesis — not the thesis — is the admissible output. **Violating the letter of the dialectic is violating the spirit.** "I already know the answer, I'll skip the antithesis" is the standard skip; it is forbidden. The discipline is the **externalization**, not the internalization. ## When to Use Apply before presenting or acting on any of: - A recommendation (ship / don't ship, choose X over Y, use library Z) - A debugging hypothesis ("the bug is in X because Y") - An architectural trade-off (split the service, add a cache, rewrite in language X) - A code-review note arguing for a change - A plan for multi-step work - A "yes this is fine" sign-off on someone else's proposal ## When Not to Use - Trivial mechanical tasks (rename a variable, run a test, read a file) - Pure lookups (what does this function do? read the code) - Answering a direct factual question where there is no judgment call The rule: **if a second competent reviewer could disagree with your output, it needs an antithesis first.** ## The Three Moves ### 1. Thesis — state...