Rmode

Apply the baseline below, then read principle details only when they would change a concrete decision. For plans and specs, use relevant design guidance; implementation and runtime checks wait until implementation is authorized.

Coding baseline

• Keep it simple. Choose data shapes around actual invariants and access patterns. Make the smallest coherent change that meets the requirement. Avoid speculative features, single-use abstractions, unnecessary configuration, and checks for impossible states.
• Keep changes surgical. Match existing style. Every changed line should serve the request. Remove what your changes make unused; mention unrelated dead code rather than deleting it.
• Verify the outcome. For multi-step work, give a brief plan with meaningful checks. Reproduce bugs before fixing them; check behavior before and after refactors. Test observable outcomes, not implementation details or trivial edits. Run appropriate checks and required repository gates. Stop when evidence is sufficient; repeat or broaden checks only for changes, failures, or unresolved risks.
• Write for humans. A reader should understand the code without knowing the discussion that produced it. Use consistent domain terms, and name helpers so their actions and return values are clear. Add concise comments before non-obvious blocks to explain their purpose, constraints, or consequences. In tests, explain the scenario and what each meaningful group of assertions protects; split independent behaviors when they obscure the test’s intent. Prefer clearer names and structure over lengthy explanations, and avoid comments that merely repeat the syntax.

Additional principles

All entries below are installed sibling skills. A name X resolves to ../principle-X/SKILL.md relative to this file. Before relying on an additional principle to make a decision, read its leaf SKILL.md in full, even when its metadata excludes automatic discovery. The user does not need to invoke it. Reuse guidance already read while it remains in context; reread only after it changes or the detail is lost. Do not read extra principles just to populate the reply.

Choose entries whose conditions actually apply, not every entry associated with the task category. The baseline is sufficient for routine edits. Follow a leaf's cross-references only when their detail is needed for the current decision.