code-standards

Write code a senior engineer would approve — not just code that passes. Apply on every build/maintenance tick that touches code. These are the floor; the host project's CLAUDE.md / AGENTS.md wins on any conflict.

1. Think before coding

State your assumptions. If the goal has multiple readings, pick the simplest that fits and say which — don't silently guess. If a simpler approach exists, take it. Surface real tradeoffs in the journal, up front.

2. Simplicity first — stop at the first rung that holds

Before writing code, walk this ladder and stop at the first rung that solves it:

1. Does this need to exist? → no: skip it (YAGNI).
2. Stdlib does it? → use it.
3. Native platform feature? → use it.
4. Already-installed dependency? → use it (don't add a new one).
5. One line? → one line.
6. Only then: the minimum that works.

No abstractions for single-use code, no "flexibility"/config nobody asked for, no boilerplate nobody requested. Deletion over addition; boring over clever. Test: would a senior engineer call this overcomplicated? If yes, cut it. Lazy, not negligent — simplicity NEVER cuts trust-boundary validation, data-loss handling, security, or accessibility. When you take a deliberate shortcut, mark it inline: // shortcut: <why> — upgrade: <path>, so the minimal choice stays visible and reversible, not hidden debt.

3. Surgical changes

Touch only what the goal needs. Match the surrounding style even if you'd do it differently. Don't refactor what isn't broken or "improve" adjacent code/comments/formatting. Remove only the orphans YOUR change created; mention pre-existing dead code, don't delete it. Every changed line traces to the goal.

4. Goal-driven + verified

Turn the task into a checkable success criterion (a test, a passing command). Write/extend the test, make it pass; the suite is green before AND after. This feeds the forced verify gate — you cannot mark work done without a real check (backlog_done requires a passing verify block).

5. Code intelligence

Prefer LSP (go-to-definition, find-references, types) over blind grep for navigation. After editing, verify no type/build errors (tsc --noEmit / cargo check / the project's check) before claiming done.

6. Commits (if the loop commits)

Match the repo's existing commit style and conventions (message format, and whatever attribution/footer policy the repo already uses — follow the project, don't impose one).

Compose, don't override

If the host project has a CLAUDE.md / AGENTS.md, read and FOLLOW it — it takes precedence. This skill is the baseline that travels with the framework (and applies on agents that don't read CLAUDE.md, like Codex).