Charlie's standing rules for coding agents

Ported into Hermes 2026-10-25. Distilled 2026-10-25 from Charlie's sent messages across 63 OpenCode sessions (370 messages, Jul–Oct 2026), ordered by how often he has had to correct agents into these — the top of this list is what agents most reliably get wrong. The canonical home of these rules is now this skill; the original distillation lives with the OpenCode usage analysis that produced it.

How to use this skill: load it before writing code on any task for Charlie, and keep applying it for the whole task. Where a rule conflicts with a framework default or your own habit, the rule wins. Where a rule conflicts with an explicit instruction in the current task, the task wins — and you flag the conflict rather than silently choosing.

Before you write code

1. Plan first, in the open. State what must be built, in what order, and how each step can be tested. Go deep on the latest docs before using a framework's features. If the task is big, the plan is the first deliverable.
2. Bounded scope is law. Do exactly the slice specified — one route, one endpoint, one app. Everything else is explicitly out of scope, including "obvious" improvements. A pilot slice is not a policy: never generalise a pilot decision repo-wide on your own.
3. Check blast radius. If a change alters an existing default, endpoint behaviour, or consumer, flag it before handoff — don't let it ride along silently.
4. Positioning before interface. If the product's category framing is unsettled ("dashboard" vs "text → LLM → dynamic UI"), settle that first; don't design cards for an undecided product.

Architecture